Jump to content

jayjay23

Full Members
  • Content count

    126
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by jayjay23

  1. jayjay23

    Firmware

    I've bought a generic EUC and found the speed limit to be a bit annoying, still being aware there will be any kind of hardware limitation (battery (voltage drop), motor heat, controller heat). As a software developer being a little into hardware as a hobby I thought it would be great to have the firmware at hand and do any kind of adaptation possible (reading more of this forum also some security aspects like cut off could be tuned). So I questioned myself whether it may be possible to do it just by owning the hardware as I don't expect to find anybody at all and somebody finally willing to share the code. When opening it for installing a bicycle computer I had a look at the controller and it uses a STM32 (F103C8T6) controller for which I could find the manual with all information like pinout etc. Searching for whether the flash can be written 'and' read I found that it's possible as long as there has been no explicit read lock set by the manufacturer. As I hope that this is not the case I diged further and found that the interfaces this STM32 should have for programming is some serial interface and a JTAG (being on the same PINs and automatically switched). The spec. for the chip clearly states which PINs these are and if somebody every looked into the world of firmwares (e.g. OpenWRT) for wireless routers, it seems standard that some of the programming/debugging interfaces are just left on the board, so it's the same case for my controller board: Fortunately I still don't own a JTAG adapter, but now one is ordered. I also found an interesting paper from blackhat conference showing available tools, JTAG finding and some more (https://www.blackhat.com/presentations/bh-europe-04/bh-eu-04-dehaas/bh-eu-04-dehaas.pdf) So this is were I'm currently, quite at the beginning, but I would like to know if anybody has some input or ideas to contribute. This could fast also be a dead end road but let's see, if the image can be read (I will first try with openOCD) it should be possible to disassemble and decompile, maybe it will be hard to recompile it, but maybe some things can be adjusted by just working on the raw image. If there is some progress I will add it here. EDIT (16.09.2015): Replaced image showing debug connector to show now used SWD (Serial Wire Debug) pin out (STM32 also has JTAG but on my board layout two of the JTAG pins are used for the power LEDs, so they are redefined as GPIO, while SWD works fine).
  2. jayjay23

    Firmware

    Regarding the MPU it goes like this, the lib just read the register map (RM-MPU-6000A.pdf) starting from ACCE_XOUT_H, 14 bytes, this is all these values: ACCEL_XOUT_H ACCEL_XOUT_L ACCEL_YOUT_H ACCEL_YOUT_L ACCEL_ZOUT_H ACCEL_ZOUT_L TEMP_OUT_H TEMP_OUT_L GYRO_XOUT_H GYRO_XOUT_L GYRO_YOUT_H GYRO_YOUT_L GYRO_ZOUT_H GYRO_ZOUT_L So you get a 14 byte array as above. s16 mpuData[8]; MPU6050_GetRawAccelGyro(mpuData); // HINT we define here the board orientation (may subject to change/configure) int16_t upDownAccel = mpuData[0]; int16_t frontBackAccel = mpuData[1]; int16_t leftRightAccel = mpuData[2]; int16_t frontBackGyro = mpuData[4]; // just a guess int16_t leftRightGyro = mpuData[5]; This is the none DMA example. In init you set the scale of the values, the int16 is -16k to +16k and the scale defines what's the rang in physical units. So if you set the accel scale to 16G (MPU6050_ACCEL_FS_16) this means -16k is -16G (or half, not sure right now). So to get a physical unit G value you just need to divide properly. So the scale also defines the sensitivity, you could decide to go for a smaller scale to have more sensible values, meaning each integer step is a smaller - so more precise - physical step. The same applies for the gyro, physical unit is rad/s. From this point I just used some basic trigonometry (while I'm not 100% sure, whether I choose the correct observer point of view, as I don't know what the filters expect, but I guess they can work with any value, it's how we feed the result in the PID loop and it's our own decision how the filter/PID output is converter to rotation): // PI/2 - acos([frontBackAccel|leftRightAccel]/16383,5) float fwBkAccelAngle = PI/2.0 - acos(frontBackAccel/16383.5); float leftRightAccelAngle = PI/2.0 - acos(leftRightAccel/16383.5); // calculate gyro rate in rad/s float fwBkGyroRadS = frontBackGyro/5000; uint16_t loopTime = utilDelayCnt; *fwBkAngle = callFilter(fwBkOldAngle, fwBkAccelAngle, fwBkGyroRadS, loopTime); fwBkOldAngle = *fwBkAngle; Here the constant dividers (16k and 5k) are just plain wrong, they need to be carefully adjusted according to the scale choosen, bu this was actually the point were I left of due to float instability. I wanted to try that code tonight, but for some reason my programming adapter didn't wanted to connect. Anyway I hope above explanation makes looking through the spec shorter.
  3. jayjay23

    Firmware

    @electric_vehicle_lover: This findings is really great, actually I thought that current control should be possible. Even I'm not really finished I put up back the wheel stuff to my desk and will try the math stuff next days, so far I was busy with this stuff (eib bus components for our house) and also had some time shortage due to child care special situation which hopefully clears next weeks: This week is so warm here in germany that I started to go by wheel again (I didn't wanted to try on ice, thoug vee has a really cool spikes mod :-))
  4. jayjay23

    Firmware

    I read through that and it's a good explanation of what has to be done, I didn't digged into any code as the stuff needed is already at our hands and I would say to look at something new only if it just doesn't work in general. ok!! That's really great news as I took the thumbs version after reading some pages for exactly our chip that it should only work with that, so I was not focused on trying another variant or reading about it. As soon as my situation stabilized a bit more I will check if that did the thing.
  5. jayjay23

    Firmware

    @electric_vehicle_lover: Hi follow all your progress and that's really cool, actually I needed to clean up my workplace during christmas and have restored it only partially for soldering some stuff for our house which I'm currently still busy with. So sorry for my current break, but I need to solder some more items. The latest state regarding IMU is unfortunately that there seems to be a instability when using float, the code seems to run a bit, but then stops and I could not figure out before christmas what it was. I'm also unsure about how to deal with the timing issues and debugging, my current debugging facilities are a bit limited with the aspect of real time, all debugging with the SWD slows stuff down and so can have any kind of side effect. So I already had the idea of using all the leds for showing various states of the code to not have something interrupting the real time behavior. If there are any other ideas I would appreciate it. I'm a bit far away from such a solution, but a serial transmission would also already help a lot as it does not involve break point handling (as all my current methods via SWD). If there are any other ideas for this they are very welcome.
  6. jayjay23

    Firmware

    @lizardmech: Simple DIY projects I've seen that already work, only use the angle as input and a motor control value (not further egulated) as output, if angle is not achieved the output is adjusted accordingly. More advanced algorithms, that should result in more stability under different environmental parameters use a speed (rpm) and/or torque (voltage/ampere) feedback that is also PID regulated. In which case there is a back channel, but with common parameters, so from design point of view these parameters if normalized could be passed through a well defined interface and if a motor driver does not support it you could in worst case rely again on just a undefined motor control value and a simple algorithm with just one PID loop.
  7. jayjay23

    Firmware

    For later this is fine, search for HC-05, this is a ready all in one bt module for just a few euros and all you need to do is connect power and serial Rx/Tx. This is what I've seen in another bluetooth wheel (china).
  8. jayjay23

    Firmware

    I'm just checking this: http://electronics.stackexchange.com/questions/149387/how-do-i-print-debug-messages-to-gdb-console-with-stm32-discovery-board-using-gd In the hope I can get a faster debug output that also doesn't interrupt program flow, as stopping with a breakpoint while I2C transfer is at some 'waiting for the MPU' state, and that state arrives during breakpoint (of course the MPU is not halted :-)) the state may go away and will never be reached again as the flow is broken. With above code I already can transfer characters from the running chip to OpenOCD (but it's also horrible slow, at least the flow is not broken).
  9. jayjay23

    Firmware

    Ok, found it (here: https://www.mikrocontroller.net/topic/304369) We have libgcc included since the very beginning and I recently added libm (for math stuff, like trigonometric functions), those libs should be taken from /thumb directory, it just didn't caused problems yet as we seem to not use anything from libgcc.
  10. jayjay23

    Firmware

    I read somewhere that there is a chain and WWDG is just the last one, so I actually put in my head 'something is not working' (generally), without care actually about the WWDG specifics.
  11. jayjay23

    Firmware

    The F103 does not support a hardware FPU, so I already added -mfloat-abi=soft -msoft-float a while ago, it seems just there is some pice of the puzzle still missing. Well I meant that with just the duty cycle it would be possible to ride (maybe 5-10), the current feedback should be read in and passed to a PID regulation also, to achieve some constant torque. Without that, the main PID may have more difficulties to regulate just on the known speed (RPMs) and can not react so fast on voltage sags, or voltage drain, hills or other slow down / accel forces from outside? WIthout somebody on the wheel, the motor can probably spin up to 50-60km/h (just a small guess), but the tourqe at this speed will not allow riding.
  12. jayjay23

    Firmware

    Ok, cool, I think with that we can already soon build a firmware that is a bit rideable! Which kind of problem? I stripped my problem down to passing a float as an parameter and doing nothing more, the code when executed ends up in some exception handler, WWDG_IRQHandler(), I read about various options to the linker, but maybe we are linking against the wrong libs, I also added libm.a and changed LD command to gcc as it does some magic here to avoid undefined symbols from the system libraries.
  13. jayjay23

    Firmware

    Glue compiles now at least, but need to figure out why soft float stuff is not working.
  14. jayjay23

    Firmware

    Ok, after implementing a proper delay function (added a util.c for that) the MPU6050 raw data can be read and looks quite reasonable already! I continued a little bit with the glue from raw to filter but need some more work on here.
  15. jayjay23

    Firmware

    @electric_vehicle_lover: Wow, that's really great. Could you already make progress in the current measuring then or does it run just by duty cycle and hall sensors? Did you use a second board then, if the other is damaged or could you repair it already?
  16. jayjay23

    Firmware

    The motor interface is just the hall sensors, so if the operate at the same voltage than generic (which is likely) the other parameters are the order of the hall sensors and the number of coils per rotation, so maybe you can just figure that out and we make a define for both sets of parameters and could already support two motor types!
  17. jayjay23

    Firmware

    Short update in MPU code, last weekend I tried to get that running and I believe it's connecting (getting one ID byte from the I2C), but the raw data can't be read, so still need to dive into this. (I tried with polling mode first, to keep it simple, if that works and makes sense in the context of the program flow, we can switch to DMA) I changed the systick back to 10ms and implemented a delay function (needs rework though), what should be our goal for the systick, now it's 10ms, it was 1ms?
  18. jayjay23

    Firmware

    Ok, just found another interesting point on above mentioned page: "Note that another way to force control with SWD, is to keep the RESET button pressed during the whole session. SWD, and uploading will work in this mode – while the µC is kept in reset." If this holds true it may be easier to conduct on our boards, but I don't know if the reset PIN was connected or not. The reset PIN seems to be pull up on our board, but it should be possible to cut the line on the board and pull down instead.
  19. jayjay23

    Firmware

    Regarding the serious boot problems the solution should be as follows (http://jeelabs.org/book/1546c/): It seems if you boot from SRAM instead of Flash the SWD interface works for doing what you want, e.g. reflash with another firmware file. The ST docu says to pull Boot0 high (which means unsoldering that pin on our boards) and Boot1 low, then reset the board. The Link above says the inverse PIN powering, so you maybe try both.
  20. jayjay23

    Firmware

    No, but this should not make any difference, right?
  21. jayjay23

    Firmware

    The chain should be as follows, please verify all the path' and variables are in place: TCPREFIX = ../../gcc/gcc-arm-none-eabi/ LFLAGS = -Tsrc/stm32_flash.ld -L$(TCPREFIX)lib/gcc/arm-none-eabi/current -lgcc -nostartfiles The key is the -L flag, if I verify what's there I get: l ../../gcc/gcc-arm-none-eabi/lib/gcc/arm-none-eabi/current/libgcc.a -rw-r--r-- 1 1607588 Jun 9 2015 ../../gcc/gcc-arm-none-eabi/lib/gcc/arm-none-eabi/current/libgcc.a So if I look in your -L flag, I can't see the lib directory, can you tell me what tool chain you are using and what the directory structure looks like, I just took the official launchpad release and oriented the makefile on that structure: -L../tools/gcc/lib/gcc/arm-none-eabi/current edit: Ok, the dir actually looks ok, maybe it's just the complete path that is not pointing to the final required directory
  22. jayjay23

    Firmware

    This is more or less the same situation than if the firmware disables the debug interface, so you may also try to set the correct boot and reset PINs so that the firmware just don't start but the debug interface is already up (if you want I can help looking that up). This way a lot of other stuff can be reverted! the MW 30km/h has the same STM32 than we are working with now, but I don't know whether it has firmware upgrade. Is a simple flashloader difficult to implement? I mean it needs the bluetooth (serial RX/TX in the simple case that the bt stack is on the bt breakout), well I would revisit that later, I'm not an expert in footprint, but I can ask colleagues about it as it is their concern every day :-)
  23. jayjay23

    TG F-5 500W motor upgrade

    In case you are interested, I wrote this up a few weeks ago: http://www.myewheel.org/index.php5/Controller_replacement_30km/h
  24. jayjay23

    Firmware

    Hi guys, great to see all the progress and involvement, a few coments on the recent posts, from my side: OpenOCD config: The config I use is on tools/openocd.cfg, but it's set to be used with openocd-usb.cfg, which matches my JTag adapter, so as I see most of you use the ST-Link which requires another config I'm open for extension here, most of you also seem to use a GUI with separate settings, so currently there is no conflict with my console stuff, but if anybody want's to use the console with a different config for a different debug adapter, please let me know and we extend the setup to support both. @electric_vehicle_lover: Great that you checked some more code, about the current measurement, I thought exactly the same, just consume a constant power somehow, measure the ampere and read back the voltage. The same thing can be even more easier done for the voltage. Regarding the higher speed and the power, I think it's like this, the torque is reduced the higher the speed is, due to higher back-EMF, so there is less torque, less power available on higher speeds, so there is a natural limit, but this limit is driver and situation dependent, as the simple question is just, how much power(torque) reserve you need to not fall over, I think the power to keep balanced is independent from speed, it's just that e.g. bump impacts require more power on higher speeds. When we are able to implement a 0-100% avail power consumption bar (like @Tilmann suggested) this would be great to let people know if the are constantly near the boarder (which when crossed they fall) or there a margin that is good. Regarding configuration of the wheel I think something very easy we could do right away, even with our boards is to do the same thing than chinese people have done. I've analysed another controler with bluetooth a few weeks ago (due to some power consumption problem) and I looked closely at the used bluetooth breakout and it seems to be a quite cheap (6€) HC-05 which translates all the bluetooth stuff into serial RX/TX, which we could connect to the free pins 21/22, which is UART3 RX/TX, so this thing could be really easy to add as a first try, and we could implement the protocol that @esaj (et al) already reverse engineered and that he also created a open source (?) app for already!
  25. jayjay23

    Firmware

    @electric_vehicle_lover: Strange, you mean the motor from your generic EUC? Or a bicycle motor? My generic motor was actually working, but very difficult to keep the board standing on the table and holding it by hand balanced. If the hall sensors are ok, maybe the phases are changed on your motor? Now after driving more and more km's, I believe this will be just all about available power. At the higher speeds the power is reduced, if you drive with great care and no bumps you can go faster as the required power for balancing problems and bump accounting will be less, so I guess that's it, you can go faster but with reduced stability. I have the left most of the four battery LEDs plugged in, and it was 'working' but the code was changed back from OD to PP, which makes the LED not go off completly, I hav not corrected this now, but we can just do it. I have not looked into the LEDs when looking for hall sensors.
×