Firmware

[jayjay23]

@Mystamo: Hi, welcome and great that you joined, I actually learned already something as I thought it would only make sense 'independant' motor driver, though I haven't fully understood the aspects of the other.

@Restless:

The MPU6050 code I took was this (the Indian guy): https://harinadha.wordpress.com/2012/05/23/mpu6050lib/

And here are the DMA snippets from the Chinese guy that I already merged into the resulting code (http://letanphuc.net/2014/06/stm32-mpu6050-dma-i2c/).

@electric_vehicle_lover:

So I just took a look at the motor code and decided to approach it more slowly, with first having the goal of working (and understanding the hall input).

The code was mixed between TIM3 and TIM4 while we have to use TIM2, changing this and adding the following clock init for the TIM2:

RCC_APB1PeriphClockCmd( RCC_APB1Periph_TIM2, ENABLE);

made it already work (I actually compared your code to the https://www.mikrocontroller.net/articles/STM32_BLDC_Control_with_HALL_Sensor to see what was missing).

Now the next step is to sort out the sequences for hall and motor commutation, the hall sequence (unfortunately only in decimal) is as follows

(don't be confused with the TIM_ClearITPendingBit() stuff, it's just there as my auto breakpoint is there as at this point the hall data is read):

1, 5, 4, 6, 2, 3

 

If anybody can explain to me why the timer has to be initialized as a counter (or maybe I've overseen something) while it actually works interrupt driven through external signaling, I would appreciate it.

 

31      TIM_ClearITPendingBit (TIM2, TIM_IT_Trigger);
$144 = 1

Breakpoint 1, TIM2_IRQHandler () at src/hall_sensor.c:31
31      TIM_ClearITPendingBit (TIM2, TIM_IT_Trigger);
$145 = 5

Breakpoint 1, TIM2_IRQHandler () at src/hall_sensor.c:31
31      TIM_ClearITPendingBit (TIM2, TIM_IT_Trigger);
$146 = 4

Breakpoint 1, TIM2_IRQHandler () at src/hall_sensor.c:31
31      TIM_ClearITPendingBit (TIM2, TIM_IT_Trigger);
$147 = 6

Breakpoint 1, TIM2_IRQHandler () at src/hall_sensor.c:31
31      TIM_ClearITPendingBit (TIM2, TIM_IT_Trigger);
$148 = 2

Breakpoint 1, TIM2_IRQHandler () at src/hall_sensor.c:31
31      TIM_ClearITPendingBit (TIM2, TIM_IT_Trigger);
$149 = 3

Breakpoint 1, TIM2_IRQHandler () at src/hall_sensor.c:31
31      TIM_ClearITPendingBit (TIM2, TIM_IT_Trigger);
$150 = 1

 

Edited December 8, 2015 by jayjay23

[electric_vehicle_lover]

14 hours ago, jayjay23 said:

So I just took a look at the motor code and decided to approach it more slowly, with first having the goal of working (and understanding the hall input).

If anybody can explain to me why the timer has to be initialized as a counter (or maybe I've overseen something) while it actually works interrupt driven through external signaling, I would appreciate it.

@jayjay23 great!! I don't see a commit of your code. I would like to review it. Please commit.

I don't know if is required the counter. At least I know it is important so the time between each pulse is measured and like that we can calc the motor velocity.

[jayjay23]

@electric_vehicle_lover:

I created a branch (I think in the wrong way) named halltest, so the changes should be there, but it's just a quick and dirty hack to make the sensors come alive,

it needs cleanup for final integration.

Btw, Is there any problem of putting clock inits to the specific HW that we want to initialize. Just without thinking I put the TIM2 clock init in the GPIO file, put it actually belongs to the hall stuff and also has the TIM2 selection from there, so I guess it would be easier if all hall related TIM2 stuff is in the hall files, so we could define the PINs and timers in one single place.

Is there anything that speak against doing so?

[electric_vehicle_lover]

I just connected my new board and with my power supply of 5A. When I turn it on, the motor rotates/shakes a bit and the the power supply shows a quick short circuit - then the controller just beeps continuous. I would say this controller do not have firmware for this motor and thankfully it reads the current, understanding that something is wrong and shutoff itself giving a warning.

So, this controller is from MicroWorks (MW). Microworks sells a pair of motor + controller, for the 10km/h or 30km/h. I think @jayjay23 reported that he bought a 30km/h controller from MW that do not work with his original generic motor. He needed to buy after the pair motor from MW.

I am very curious to understand what are the limitations on generics to be able only to run to a max of 16km/h.

[electric_vehicle_lover]

@jayjay23 Just got your code running I also confirm that I get this sequence for the hall sensors: 1, 5, 4, 6, 2, 3.

Only the LED for power button flashes as supposed but none of the battery LEDs :-(

I also changed the code to have commutate() on systick handler, at 25ms. I can see the power button LED flashing but I don't see signal with oscilloscope, for the commutation - something is missing... 

 

[electric_vehicle_lover]

I figured that PB4 for one LED must be configured. I pushed the code (also includes the correct code for the hall sensors).

We still have problems driving some IO pins for some LEDs and also for driving the motor.

Edited December 10, 2015 by electric_vehicle_lover

[SlowMo]

Has anybody tried this motherboard for a 350w motor that can go up to 25km/h as posted by @Oily?

http://forum.electricunicycle.org/topic/2079-30-knh-on-a-350w-motor/

Edited December 10, 2015 by SlowMo

[jayjay23]

@electric_vehicle_lover:

5 hours ago, electric_vehicle_lover said:

When I turn it on, the motor rotates/shakes a bit

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?

5 hours ago, electric_vehicle_lover said:

I am very curious to understand what are the limitations on generics

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.

 

4 hours ago, electric_vehicle_lover said:

Only the LED for power button flashes as supposed but none of the battery LEDs

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.

[electric_vehicle_lover]

@SlowMo thanks for the information. Looking at the pictures, that controller board is just equal to the ones that say that work for the max of 16km/h.

@jayjay23 and others: I tested only with my unicycle (I do not plan to test with bicycle motor). The connectors are just the same (and the motor phase colors are correct) except the power switch connector that have only 2 pins while my original have 3 pins connector but the middle pin is not used.

About the limitations, it seems rationale. For accelerations on higher speeds (for controlling the EUC) or for braking, the motor needs to handle more power, the board mosfets and finally the battery.
But I think that maybe even motor may have a specific coils wiring that make it more suitable for lower speeds/high torque. Maybe with increasing speed it quickly loses torque.

About the working pins on current code, I just push the code for the table with that information:

/* Connections:
 *
 * Motor PHASE_A: green wire
 * Motor PHASE_B: yellow wire
 * Motor PHASE_B: blue wire
 *
 *
 * PIN                | IN/OUT| Works?|Function
 * ----------------------------------------------------------
 *
 * PA8  (TIM1_CH1)          | out    | ??    | Bridge_A-High (green wire)
 * PA9  (TIM1_CH2)          | out    | ??    | Bridge_B-High
 * PA10 (TIM1_CH3)          | out    | ??    | Bridge_C-High
 * PB13 (TIM1_CH1N)         | out    | ??    | Bridge_A-Low
 * PB14 (TIM1_CH2N)         | out    | ??    | Bridge_B-Low
 * PB15 (TIM1_CH3N)         | out    | ??    | Bridge_C-Low
 *
 * PA2  (TIM2_CH3)         | in    | yes    | Hall_sensor_A
 * PA1  (TIM2_CH2)         | in    | yes    | Hall_sensor_B
 * PA0  (TIM2_CH1)         | in    | yes    | Hall_sensor_C

 * PA6  (ADC12_IN6)         | in    | ??    | BMF_signal-Yellow_A
 * PB0  (ADC12_IN8)         | in    | ??    | BMF_signal-Green_B
 * PB1  (ADC12_IN9)         | in    | ??    | BMF_signal-Blue_C
 *
 * PA7  (ADC12_IN7)        | in    | ??    | Current_signal
 *
 * PB6  (I2C1_SCL)        | in/out| ??    | IMU_MPU6050-SCL
 * PB7  (I2C1_SDA)        | in/out| ??    | IMU_MPU6050-SDA
 *
 * PA15             | out    | ??    | LED_1-battery_indicator (active low)
 * PB4                 | out    | yes    | LED_2-battery_indicator (active low)
 * PB5                 | out    | ??    | LED_3-battery_indicator (active low)
 * PB8                 | out    | ??    | LED_4-battery_indicator (active low)
 * PB9                 | out    | yes    | LED-power_switcher (active low)
 *
 * PB3                 | out    | ??    | Buzzer(??)
 * PA4                 | out    | ??    | PS_signal(calibrate_wheel??)
 *
 */

Edited December 10, 2015 by electric_vehicle_lover

[electric_vehicle_lover]

Just added a page about (using links and info from the forum) upgrades/mods - started with the "famous" 30km/h; 500W motor and bluetooth app:

https://github.com/generic-electric-unicycle/documentation/wiki/Generic-Electric-Unicycle-upgrade-modding

[Mystamo]

On 12/8/2015 at 1:35 PM, esaj said:

Thanks for the schematic! I have a couple of (stupid) questions though, if you don't mind...

How does the high-side gate driving work, I tested the circuit in LTSpice, and got around 45V at the gate, but I'm not sure I understand how it works. Is it some kind of charge pump/voltage multiplier?

What are the 10k resistors (R29-R31) in parallel with the low-side mosfets for? My guess was something like preventing the "open" phase from floating, but could be very wrong

Hey guys,

Been a bit busy the last few days. Great progress so far. I don't have an ST link so I'm ordering one from digikey. I don't usually work with ST components as they are fairly expensive and overly powerful in the automotive industry that I work in.

 

Regarding the circuit. The high side essentially has a charge pump. That capacitor you see in the circuit charges up and blips right into the high side FET when the transistor in parallel with it goes low.

You are correct about the 10k resistor. It acts as a reference to GND when the phase is open circuit.

 

This method of controlling FETS is ancient. Not sure why the Chinese designers have gone with this typology. It's not very intuitive and takes up a lot of board space. It also has more components that can fail (hardware wise or solder joint wise)

All these components can be replaced these days with application specific IC's that can control the FETS with deadband insertion already in place as well as synchronized switching. More simple, less space, but perhaps slightly more expensive. Well worth it in simplifying the design

 

Regards,

 

Mo

[Restless]

@Mystamo you're very welcome to support the Hardware Dev side of this project

 

I think together we could achive something really awesome.

 

As a side note:

Last days i had not that much time ... so i wasn't able to look at the code for the IMU but thanks for uploading.

 

I think ill get my programmer tmrw, cant wait to start real developement.

 

For the max speed setting etc. etc. a leightweight app would be nice later on.

It would be nice if there would be a Standard so you could choose different apps, maybe we could use something like the MaxLink protocoll etc.

 

Or we would make a nice clean and flexible API, something to keep in mind but with very low priority.

 

Kai

[electric_vehicle_lover]

I would love to have an OpenSource board!! With hardware for DIY mods.

About the app, would be great if we could also support chinese protocols like the Xima app. Gotway for example, they sell the motors, batteries and controllers. I wish there is an OpenSource and expansible controller were I could connect an expansion board for specific features.

At the same time, Gotway/Microworks are doing the 30km/h controllers and motors... supporting their systems would impact a lot of users. At the same time, the boards have very few memory for apps and don't have free pins for expansion.

Why not copy their boards but add expansion connector and microcontroller version with more memory, and keep compatibility with their boards/systems??

Anyway, let's have fun :-)

Edited December 10, 2015 by electric_vehicle_lover

[electric_vehicle_lover]

Ok, the LEDs and the buzzer now works correctly. I made a small video showing it (they flash every 1 second):

https://www.youtube.com/watch?v=jtPXkY51SJs

 

I found that the LEDs weren't working because the connector had the +5V wire on the opposite side. This is the second difference I see on the wiring from this controller to this generic EUC. I am starting thinking that this controller is for a different generic.

The buzzer just work if the pin config is this: GPIO_Mode_Out_PP
The LEDs works correctly if is this: GPIO_Mode_Out_OD

So now the GPIO table is this:

/* Connections:
 *
 * Motor PHASE_A: green wire
 * Motor PHASE_B: yellow wire
 * Motor PHASE_B: blue wire
 *
 *
 * PIN                | IN/OUT| Works?|Function
 * ----------------------------------------------------------
 *
 * PA8  (TIM1_CH1)          | out    | ??    | Bridge_A-High (green wire)
 * PA9  (TIM1_CH2)          | out    | ??    | Bridge_B-High
 * PA10 (TIM1_CH3)          | out    | ??    | Bridge_C-High
 * PB13 (TIM1_CH1N)         | out    | ??    | Bridge_A-Low
 * PB14 (TIM1_CH2N)         | out    | ??    | Bridge_B-Low
 * PB15 (TIM1_CH3N)         | out    | ??    | Bridge_C-Low
 *
 * PA2  (TIM2_CH3)         | in    | yes    | Hall_sensor_A
 * PA1  (TIM2_CH2)         | in    | yes    | Hall_sensor_B
 * PA0  (TIM2_CH1)         | in    | yes    | Hall_sensor_C

 * PA6  (ADC12_IN6)         | in    | ??    | BMF_signal-Yellow_A
 * PB0  (ADC12_IN8)         | in    | ??    | BMF_signal-Green_B
 * PB1  (ADC12_IN9)         | in    | ??    | BMF_signal-Blue_C
 *
 * PA7  (ADC12_IN7)        | in    | ??    | Current_signal
 *
 * PB6  (I2C1_SCL)        | in/out| ??    | IMU_MPU6050-SCL
 * PB7  (I2C1_SDA)        | in/out| ??    | IMU_MPU6050-SDA
 *
 * PA15             | out    | yes    | LED_1-battery_indicator (active low: float to disable and GND to turn on)
 * PB4                 | out    | yes    | LED_2-battery_indicator (active low: float to disable and GND to turn on)
 * PB5                 | out    | yes    | LED_3-battery_indicator (active low: float to disable and GND to turn on)
 * PB8                 | out    | yes    | LED_4-battery_indicator (active low: float to disable and GND to turn on)
 * PB9                 | out     | yes    | LED-power_switcher      (active low: float to disable and GND to turn on)
 *
 * PB3                 | out    | yes    | Buzzer           (active high: push pull)
 * PA4                 | out    | ??    | PS_signal           (calibrate_wheel)
 *
 */

Edited December 11, 2015 by electric_vehicle_lover

[electric_vehicle_lover]

I tested with oscilloscope and now the Bridge_A-Low, Bridge_B-Low and BridgeC-Low pins works.

What is not working is the Bridge_x-High pins that require PWM...

The latest code is on github.

For current measure, an idea on how to do it:

- put a know power resistor between phase A and B (green and yellow wires) and enable the switchs. Adjust the power supply and measure on the power supply a current of 1A. Then measure the PA7  (ADC12_IN7) Current_signal pin. Repeat for 3 other different current value and we then should have a curve (may linear??).

Edited December 11, 2015 by electric_vehicle_lover

[Restless]

Hey guys

 

It looks like i was a good kid today I got my STLink V2 from Banggood (5,57$) and it works with the original ST-Link Drivers (yay) hopefully iam able to start working with it today!

And the adapter looks really fancy since its out of aluminium.

 

 

So, back to the topic. @electric_vehicle_lover i got a TG T3, havent checked everything but it looks like these controllers are pretty similar at least for the leds

[electric_vehicle_lover]

@Restless I also use the same compatible STLink V2 - I bought mine from Ebay, shipping from inside EU.

Please find in attachment the script files I use with OpenOCD.

Main screenshots for my config of OpenOCD and flash/debug on Eclipse:

stm32f1x.cfg

stlink-v2.cfg

[Restless]

thanks @electric_vehicle_lover thanks for the configs I'm still trying to get everything working ...

 

A chatroom would be nice, maybe an IRC or something

Edited December 11, 2015 by Restless

[jayjay23]

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!

 

 

 

[electric_vehicle_lover]

QUICK WARNING

I just locked up myself :-( -- I did some code that for some reason shorts phases. The bench powersupply do very well his work and the board is fast resetting. The problem?? with the board in a shortcircuit and fast resetting, I simple can't program it and so I am locked up. Now I will cut the PCB trace that commands the mosfets to avoid the shortcircuit and be able to program again, then solder that PCB trace.
In past, I used a switch. The code always verified that switch before runs - this means I could now turn on the switch and the shortcircuit would stop and I would be able to program again. I will use this way an put the switch on the  PS_signal (the one that is used originally for calibrate the wheel).

[electric_vehicle_lover]

@jayjay23 the 30km/h with bluetooth controller you have, how much flash memory the STM32 have? -- for our current boards, we just have 64kbytes which I think will be a problem for adding this like bluetooth (even if is serial). For example, for firmware upgrade from the app, we would need a bootloader + firmware on the 64 kbytes :-(

[Cranium]

13 minutes ago, electric_vehicle_lover said:

QUICK WARNING

I just locked up myself :-( -- I did some code that for some reason shorts phases. The bench powersupply do very well his work and the board is fast resetting. The problem?? with the board in a shortcircuit and fast resetting, I simple can't program it and so I am locked up. Now I will cut the PCB trace that commands the mosfets to avoid the shortcircuit and be able to program again, then solder that PCB trace.
In past, I used a switch. The code always verified that switch before runs - this means I could now turn on the switch and the shortcircuit would stop and I would be able to program again. I will use this way an put the switch on the  PS_signal (the one that is used originally for calibrate the wheel).

Ahhh....the early signs of the same challenges manufacturers have with releasing firmware updates that won't fry the board.

Couldn't you just ground the gate of the MOSFET to keep it from going high (instead of cutting the trace)?

Edited December 11, 2015 by Cranium

[jayjay23]

13 minutes ago, electric_vehicle_lover said:

I just locked up myself

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 :-)

[Restless]

Hey guys. finally i managed to unlock the board and thats fine so far.

 

Now i tried to compile the actual state but it fails at:

../tools/gcc/bin/arm-none-eabi-ld -v  src/main.o src/bldc.o src/gpio.o src/spl/src/stm32f10x_gpio.o src/spl/src/stm32f10x_i2c.o src/spl/src/stm32f10x_rcc.o src/spl/src/stm32f10x_tim.o src/spl/src/misc.o src/spl/src/stm32f10x_dma.o src/spl/CMSIS/core_cm3.o src/spl/CMSIS/system_stm32f10x.o src/pwm.o src/IMU/imu.o src/IMU/MPU6050/MPU6050.o src/motor.o src/hall_sensor.o src/startup_stm32f10x_md.o -Tsrc/stm32_flash.ld -L../tools/gcc/lib/gcc/arm-none-eabi/current -lgcc -nostartfiles -o src/main.elf
GNU ld (GNU Tools for ARM Embedded Processors) 2.24.0.20150921
../tools/gcc/bin/arm-none-eabi-ld: cannot find -lgcc
Makefile:60: recipe for target 'main.elf' failed
make: *** [main.elf] Error 1

 

Cant really figure that one out

[electric_vehicle_lover]

You may need to run openocd with sudo to be able to access the usb device

.About build, install arm none eabi from linux ubuntu repositories. Also apply the changes to makefile I shared on old messages.