Firmware

[electric_vehicle_lover]

Just now, lizardmech said:

But what speed is PWM switching at when not at full speed?

Depends on the duty-cycle value, motor load, etc. Please see some examples here: https://github.com/generic-electric-unicycle/documentation/wiki/Controllers

[Call-Tech]

Great read, love what you are doing. 

I have a slightly off topic question I'm hoping it's ok to ask here. I work on dozens of 2 wheel self balancing scooters each week and the number one failure is the stm32f103c8t6 core processor on the gyro board. I have tried to extract a bin from a working gyro however the firmware appears to be erased by disabling read out protection. I saw in one of the earlier pages of this post that it looked like someone managed to get a copy of the factory firmware from the stm32f103. I don't need to decrypt the factory firmware, I just need to get it out once and save the bin and then be able to write it to a new stm32f103 too repair dozens of gyro boards I have on hand. I don't know why such a high failure rate not I have confirmed in several boards if I transplant a stm32f103 from a good gyro to a bad one that it fixes the board and have not a recurrence of failure. I have the new stm32f103c8t6 processors, however they don't do me any good without the firmware to install in them. In the photo below you will see place for 4 pin header, that is 3.3v, clk, swdio and ground. I've been using st-link software with st- link v2 China programmer with firmware revision V2J24S4. 

Can anyone tell me if anyone managed to get a copy of the factory firmware from the stm32f103 and how they did it? 

Both one wheel and two wheel boards look like all the same components. Same mosfet, same core processor and same gyro.

Thank you in advance for any help you can offer me and I apologize if I posted in wrong place. This seemed closest in topic.

Sincerely, Fred

Call-Tech, inc. 

[lizardmech]

Just now, Call-Tech said:

Great read, love what you are doing. 

I have a slightly off topic question I'm hoping it's ok to ask here. I work on dozens of 2 wheel self balancing scooters each week and the number one failure is the stm32f103c8t6 core processor on the gyro board. I have tried to extract a bin from a working gyro however the firmware appears to be erased by disabling read out protection. I saw in one of the earlier pages of this post that it looked like someone managed to get a copy of the factory firmware from the stm32f103. I don't need to decrypt the factory firmware, I just need to get it out once and save the bin and then be able to write it to a new stm32f103 too repair dozens of gyro boards I have on hand. I don't know why such a high failure rate not I have confirmed in several boards if I transplant a stm32f103 from a good gyro to a bad one that it fixes the board and have not a recurrence of failure. I have the new stm32f103c8t6 processors, however they don't do me any good without the firmware to install in them. In the photo below you will see place for 4 pin header, that is 3.3v, clk, swdio and ground. I've been using st-link software with st- link v2 China programmer with firmware revision V2J24S4. 

Can anyone tell me if anyone managed to get a copy of the factory firmware from the stm32f103 and how they did it? 

Both one wheel and two wheel boards look like all the same components. Same mosfet, same core processor and same gyro.

Thank you in advance for any help you can offer me and I apologize if I posted in wrong place. This seemed closest in topic.

Sincerely, Fred

Call-Tech, inc. 

 

 

I have seen people selling the roms on 1688.com, or just send a working board to one of the many shenzhen electronic places and ask for a firmware extraction. There's plenty on alibaba with reverse engineer services. You may even be able to find someone local, just search for MCU reverse engineering services.

[electric_vehicle_lover]

@Call-Tech, even if is off topic, it is really relevant to have much information as possible for this kind of systems.

No one managed to get a copy of the factory firmware from the stm32f103!!

I also use the "st- link v2 China programmer" as you called - and it works very well!! it's so important to have such cheap tools!!

Maybe someone could start developing OpenSource firmware for the  2 wheel hoverboard :-) -- I must say that I bought one and sold later, I really believe on the unicycles for transportation but not on the hoverboards however I understand the advantages of 2 wheels hoverboards.

Edited March 21, 2016 by electric_vehicle_lover

[Call-Tech]

On 11/28/2015 at 5:32 PM, electric_vehicle_lover said:

I soldered the pins of SWD to my unicycle board and tried to read the firmware (starting at flash address and ending at 64k) using OpenOCD but I got a lot of undefined instructions so I guess the code is protected - example:

  104:    f000d101             ; <UNDEFINED> instruction: 0xf000d101
     108:    f2aff851     vrshrn.i64    d15, <illegal reg q0.5>, #17
     10c:    e8ba0e09     ldm    sl!, {r0, r3, r9, sl, fp}
     110:    f013000f             ; <UNDEFINED> instruction: 0xf013000f
     114:    bf180f01     svclt    0x00180f01
     118:    f0431afb             ; <UNDEFINED> instruction: 0xf0431afb
     11c:    47180301     ldrmi    r0, [r8, -r1, lsl #6]
     120:    00006640     andeq    r6, r0, r0, asr #12
     124:    00006660     andeq    r6, r0, r0, ror #12
     128:    f04f440a             ; <UNDEFINED> instruction: 0xf04f440a
     12c:    f8100c00             ; <UNDEFINED> instruction: 0xf8100c00
     130:    f0133b01             ; <UNDEFINED> instruction: 0xf0133b01
     134:    bf080407     svclt    0x00080407
     138:    4b01f810     blmi    0x7e180
     13c:    bf08111d     svclt    0x0008111d
     140:    5b01f810     blpl    0x7e188
     144:    d0051e64     andle    r1, r5, r4, ror #28
     148:    6b01f810     blvs    0x7e190
     14c:    f8011e64             ; <UNDEFINED> instruction: 0xf8011e64
     150:    d1f96b01     mvnsle    r6, r1, lsl #22
     154:    0f08f013     svceq    0x0008f013
     158:    f810bf1e             ; <UNDEFINED> instruction: 0xf810bf1e
     15c:    1cad4b01     fstmiaxne    sp!, {d4-d3}    ;@ Deprecated
     160:    d1091b0c     tstle    r9, ip, lsl #22
     164:    bf581e6d     svclt    0x00581e6d
     168:    cb01f801     blgt    0x7e174
     16c:    e005d5fa     strd    sp, [r5], -sl
     170:    6b01f814     blvs    0x7e1c8
     174:    6b01f801     blvs    0x7e180
     178:    d5f91e6d     ldrble    r1, [r9, #3693]!    ; 0xe6d
     17c:    d3d64291     bicsle    r4, r6, #268435465    ; 0x10000009
     180:    00004770     andeq    r4, r0, r0, ror r7
     184:    24002300     strcs    r2, [r0], #-768    ; 0xfffffd00
     188:    26002500     strcs    r2, [r0], -r0, lsl #10
     18c:    bf283a10     svclt    0x00283a10
     190:    d8fbc178     ldmle    fp!, {r3, r4, r5, r6, r8, lr, pc}^
     194:    bf280752     svclt    0x00280752
     198:    bf48c130     svclt    0x0048c130
     19c:    4770600b     ldrbmi    r6, [r0, -fp]!
     1a0:    f005b51f             ; <UNDEFINED> instruction: 0xf005b51f
     1a4:    bd1ffd62     ldclt    13, cr15, [pc, #-392]    ; 0x24
     1a8:    bd10b510     cfldr32lt    mvfx11, [r0, #-64]    ; 0xffffffc0
     1ac:    fa8cf004     blx    0xfe33c1c4
     1b0:    f7ff4611             ; <UNDEFINED> instruction: 0xf7ff4611
     1b4:    f001fff5             ; <UNDEFINED> instruction: 0xf001fff5
     1b8:    f004f8ad             ; <UNDEFINED> instruction: 0xf004f8ad
     1bc:    b403faaa     strlt    pc, [r3], #-2730    ; 0xfffff556
     1c0:    fff2f7ff             ; <UNDEFINED> instruction: 0xfff2f7ff
     1c4:    f004bc03             ; <UNDEFINED> instruction: 0xf004bc03
     1c8:    0000faaf     andeq    pc, r0, pc, lsr #21

firmware_ori-01.bin

firmware_ori-02.bin

I had to go back thru all of this post yo find this. Lol 

It looked to me like the firmware had been read without being erased even thou the it was not able to be edited and viewed properly, it was a firmware extraction. could this firmware be reloaded into another stm32f103 as a bin file? How was the memory accessed without causing the memory to be erased. Maybe I misunderstood the post and this did not come from the factory core processor? 

[electric_vehicle_lover]

The contents of the file is garbage ;-)

[Call-Tech]

Oh btw @electric_vehicle_lover, i don't own a 1 or 2 wheel self balancing scooter. I just fix them. Buy, fix and sell them. Big demand here, got to go where the money is. The most riding, i have done is the hundred miles of testing across my living room carpet. I think i may be too old for these things. I've been repairing electronics for about 40 years. Lol 

3 minutes ago, electric_vehicle_lover said:

The contents of the file is garbage ;-)

That may be true, but you still accessed the memory without erasing it, your a step ahead of me. How did you get in without setting the option byte to read protection disable? (which seems to erase chip)

Edited March 21, 2016 by Call-Tech

[Call-Tech]

1 hour ago, lizardmech said:

I have seen people selling the roms on 1688.com, or just send a working board to one of the many shenzhen electronic places and ask for a firmware extraction. There's plenty on alibaba with reverse engineer services. You may even be able to find someone local, just search for MCU reverse engineering services.

Thank you @lizardmech for the lead, I have a request for quote in now. 

I ran across this page which looked promising thou since I don't have his breakout board, I'm not entirely sure of his connections. I have tried changing boot location to system memory and still using st-link software, but still saw all FF. However I'm unsure at this point wether I may have already erased the chip before getting to that point. 

http://gekogeek.com/embedded/flashing-programs-to-stm32-embedded-bootloader/

[electric_vehicle_lover]

I did finish the code for 10º Space Vector and the motor runs at the max 19km/h. Seems the noise is equal to the 30º so I am not sure there is an advantage - maybe to the balance...

The time at each impulse of hall sensors is 4.56ms, so, should be about 19km/h:

  /*
   * Calc for the max possible time between each hall sensor signal
   * Assuming max of 35 km/h speed of the wheel:
   * 1 rotation / second --> 46 impulses
   * 1 rotation / second --> 1 / 46 = 21.7ms each impulse
   * 1 rotation / second --> 1.12 * 60 * 60 = 4.032 km/h. Note: (1.12m = 14" wheel perimeter)
   * 35km/h --> 35 / 4.032 = 8.7
   * each impulse for 35km/h --> 21.7 / 8.7 = 2.5ms
   *
   * Each impulse need to be divided by 3
   * 2.5 / 3 = 834us
   *
   * Timer increment clock for capture signals can be 10us and so we will have a resolution of 800/10 = 80
   * for the max speed of 35km/h which should be good
   *
   */

The code is here: https://github.com/generic-electric-unicycle/firmware/tree/feature/sine_wave_space_vector-1

[jbwheel]

On samedi 19 mars 2016 at 11:59 AM, EUC Extreme said:

Right. I have tried to raise the voltage and the device will not start up time.
In principle, the use of BMS lipo battery has not been ruled out.
 

Are all the gotway wheels (MCM4, MSuper) not accepting overvoltage ? Do you know what is the highest allowed voltage ?

Pinwheel use LiPo with 450W et 350W motors. I have a OEM version with 450w motor and 18-19km/h max speed instead of 25km/h for T1F+ and also without Bluetooth, maybe mine is using the 350W board ? I opened the battery and it is 16S.

It works fine and has good acceleration, although not very secure at high speed if there is any bump or hole on the road since it is losing a bit of balance if the battery is not fully charged. My MCM4 v1 is not going a lot faster but its power allow very secure driving conditions on all type of ground then you gain more on the average speed of the whole trip.

[EUC Extreme]

I've tried just Msuper. And the addition of a single cell was too much. That's all I've tested.

[electric_vehicle_lover]

I am being reading about PID for motor control current control and speed control (also a bit about FOC but seems it can't be applied to current board).

Since the current control for the motor seems to work, I am now moving to make speed control working. I just found the reading for the speed value from the hall sensors signal period is not linear, in fact is exponential. I think I will try to use a look up table and linearize the values at each step - here is the curve for the hall sensors signal period VS motor speed:

[Tomek]

50 minutes ago, electric_vehicle_lover said:

I just found the reading for the speed value from the hall sensors signal period is not linear, in fact is exponential.

 thought you made a mistake until i did the math. so obvious, and yet so counter intuitive. still can't figure out what time unit is the number of pulses in in your table. seems to be an error there...

edit:

if it's pulse/minute

46 p/m = 46p/60000us

which means the respective pulse periods should be:

60000us/46p = 1304us

60000us/92p = 652us

60000us/138p = 435us

etc.

 

Edited March 29, 2016 by Tomek

[electric_vehicle_lover]

@Tomek thanks for verifying and please find the calc sheet here: https://github.com/generic-electric-unicycle/firmware/blob/feature/speed_control/tools/motor_speed_calc.ods

One note: the motor have 46 magnets but 3 hall sensors and so the pulses are 3x times more.

Can you please verify the calc sheet and say what is wrong?

 

[esaj]

2 hours ago, Tomek said:

 thought you made a mistake until i did the math. so obvious, and yet so counter intuitive. still can't figure out what time unit is the number of pulses in in your table. seems to be an error there...

edit:

if it's pulse/minute

46 p/m = 46p/60000us

which means the respective pulse periods should be:

60000us/46p = 1304us

60000us/92p = 652us

60000us/138p = 435us

etc.

 

Just pointing out a minor unit prefix error there. There are 60 000 ms (milliseconds) in a minute and 60 000 000 µs (microseconds) in a minute. 1304 milliseconds (about 1,3 seconds) per pulse would make sense, as there are 60 seconds per minute, and it's turning at less than one full pulse per second (46 < 60). If it's 3 pulses per magnet (138 pulses per revolution), then that would make it 1304ms / 3 = 434,666... ms pulse period at 1rpm (round per minute)?

 

Edited March 29, 2016 by esaj

[electric_vehicle_lover]

Well, I am making the math like this:

hall sensors period (us) = ((1/(46*3))*1000000)/B4; where B4 is RPseconds and not RPM (my error).

Thank you all for the help :-)

[Tomek]

makes sense. to make sure I get it right, the formula is: hall sensor period (us) = 1000000/(number_of_magnets*number_of_sensors*RPS)

of course you could also just look at readings from one hall sensor, which would make number_of_sensors=1

(sorry, can't check your spreadsheet, no open office on my mac)

[electric_vehicle_lover]

Now I want to make the look up table with x axis values that have more resolution on lower velocity, because  higher changes in speed gives smaller changes on sensors signals. I think that maybe I should make one scale exponential so I can have a linear curve instead of exponential - anyone can comment or say how to make the curve linear?

[Tomek]

why lookup table? it's quite a simple (fast) formula, probably faster than a lookup table

number_of_magnets and number_of_sensors are constants, so in your case hall_sensor_period (µs) = 7246.38/RPS (or the other way RPS = 7346.38/hall_sensor_period (µs))

edit

just to make the story complete, to get the actual speed from the hall sensor period, we know that if wheel;s circumference is ~1.05m, then 1RPS = 1.05m/s = 1.05 * 3.6km/h = 3.78km/h

which means:

speed (km/h) = 7346.38*3.78/hall_sensor_period(µs) = 27769/hall_sensor_period (µs) 

Edited March 29, 2016 by Tomek

[electric_vehicle_lover]

9 hours ago, Tomek said:

why lookup table? it's quite a simple (fast) formula, probably faster than a lookup table

speed (km/h) = 7346.38*3.78/hall_sensor_period(µs) = 27769/hall_sensor_period (µs) 

That would be a linear function, I believe, which means at some point speed would be zero e also negative.

My understanding right now: speed must be measured using the sensors time. High speed means small time for the signal sensors and on the limit, it will be near zero but never zero!! also will not ever be negative. On the other side, low speed means high value for the sensors signal, which means that when the motor is near stopped, the value tend to be infinite.
So, the function should not be linear and I really thing is exponential: 0 < y <  ∞
I enjoy a lot to learn on this project and remember the math I did learn on the school :-)

[esaj]

40 minutes ago, electric_vehicle_lover said:

That would be a linear function, I believe, which means at some point speed would be zero e also negative.

It's not a linear function, if you plot y = 1234 / x, you get a nonlinear graph.

Quote from some math site:

 

One kind of nonlinear function is called inverse variation. In these functions, the dependent variable equals a constant times the inverse of the independent variable.  In symbolic form, this is the equation , where y is the dependent variable, k is the constant, and x is the independent variable.  Compare this with the equation for a function that has direct variation between the variables, such as the proportional function formula of .  The only difference is that the inverse of the input is used for inverse variation functions (another name that makes perfect sense).

 

One example of an inverse function is the speed required to travel between two cities in a given amount of time.

 

Let’s say you need to drive from Boston to Chicago, which is about 1,000 miles. The more time you have, the slower you can go. If you want to get there in 20 hours, you need to go 50 miles per hour, because . But if you can take 40 hours to get there, you only have to average 25 miles per hour, since . The equation for figuring out how fast to drive from the amount of time you have is , or . See—this is the same form as the inverse variation function formula, .

 

Here’s a table that shows several times and speeds that satisfy the equation:

 

Time	Speed (miles per hour)
1	1,000
5	200
10	100
15	66 2/3
16	62 1/2
20	50
40	25

 

Now if we plot those points, we’ll see that the graph is definitely not a straight line.

 

 

[electric_vehicle_lover]

I think the final is this: speed (meters/hour) = 4032 / (138 * hall_sensor_period)

4032 is the meters per hour (4.032km) that one rotation per second for wheel of 14''
138 is the 46 magnets * 3 hall sensors
hall_sensor_period is measured in seconds

Example: 4032 / (138 * 0.000833) = 35075 --> ~35km/h

4032 / (138 * 0.0059) = 35075 --> ~5km/h (the walking speed)

Now the code is working and the potentiometer is setting up the speed (_motor_speed_target is meters / hour).
At very low speeds the motor current is very low if try block the wheel but after 2km/h the current go to correct one that is now setup as 0.8Amps. I think I need to add now the Integral part to make a PI controller to have max current at also very low speeds.

// Called at every 10ms
void motor_manage_speed (void)
{
  float motor_speed;
  float error;
  float kp = 0.1;
  float out = 0;

/*
 * speed (meters/hour) = 4032 / (138 * hall_sensor_period)
 * 4032 is the meters per hour (4.032km) that one rotation per second for wheel of 14''
 * 138 is the 46 magnets * 3 hall sensors
 * hall_sensor_period is measured in seconds
 * Examples:
 * 4032 / (138 * 0.000833) = 35075 --> ~35km/h
 * 4032 / (138 * 0.0059) = 35075 --> ~5km/h (the walking speed)
 *
 * speed (meters/hour) = 4032x10^6 / (138 * hall_sensor_period_us)
 * speed (meters/hour) = 29217391.3 / hall_sensor_period_us
 * speed (meters/hour) = 2921739.13 / hall_sensor_period_10us
 */

  motor_speed = 2921739.13 / ((float) get_hall_sensors_10us ());

  error = (float) (_motor_speed_target - motor_speed); // get the error from the target to current value
  out = error * kp;
  pwm_set_duty_cycle (out); // 0 --> 1000;
}

Edited March 31, 2016 by electric_vehicle_lover

[Tomek]

@electric_vehicle_lover

It's quite a simple formula:

speed (m/h) = speed (m/s) / 3600 = circumference_of_the_wheel (m)/ (number_of_sensors * number_of_magnets * period_between_pulses (s) )

this makes;

speed (m/s) = 3600 * circumference_of_the_wheel (m)/ (number_of_sensors * number_of_magnets * period_between_pulses (s)) 

which in your case (14" wheel) is:

speed (m/s) = 3600 * 1.05 (m)/ (46 * 3 * period(s)) = 3780 / (138 * period_between_pulses (s))

edit

...so I guess you use a different wheel circumference 1.12m? then it seems all good.

(or did I make an error somewhere?)

Edited April 1, 2016 by Tomek

[electric_vehicle_lover]

I am using the information I tested and registered before here: https://github.com/generic-electric-unicycle/documentation/wiki/Motor

I added the integral term now and so I have now a PI controller. When the I term is a bit more high, I can see the motor kind of oscillating.
I am thinking in doing some more testing and adding the full PID. Finally, setup fixed slow speed a bit more than walking speed and try ride the unicycle like that - do you think will be rideable with a fixed speed??

---

https://github.com/generic-electric-unicycle/firmware/blob/feature/speed_control/src/motor.c

// Called at every 1ms
	void motor_manage_speed (void)
	{
	float motor_speed;
	float error;
	float kp = 0.1;
	float p_term = ;
	float ki = 0.005;
	float i_term = ;
	float out = ;
	/*
	* speed (meters/hour) = 4032 / (138 * hall_sensor_period)
	* 4032 is the meters per hour (4.032km) that one rotation per second for wheel of 14''
	* 138 is the 46 magnets * 3 hall sensors
	* hall_sensor_period is measured in seconds
	* Examples:
	* 4032 / (138 * 0.000833) = 35075 --> ~35km/h
	* 4032 / (138 * 0.0059) = 4952 --> ~5km/h (the walking speed)
	*
	* speed (meters/hour) = 4032x10^6 / (138 * hall_sensor_period_us)
	* speed (meters/hour) = 29217391.3 / hall_sensor_period_us
	* speed (meters/hour) = 2921739.13 / hall_sensor_period_10us
	*/
	motor_speed = 2921739.13 / ((float) get_hall_sensors_10us ());
	error = (float) (_motor_speed_target - motor_speed); // get the error from the target to current value
	p_term = error * kp;
	i_term += error * ki;
	// out = p_term;
	out = p_term + i_term;
	pwm_set_duty_cycle (out); // 0 --> 1000;
	}

[Tomek]

9 minutes ago, electric_vehicle_lover said:

do you think will be rideable with a fixed speed??

I think it will be insanely difficult (comparable to standing still on a turned of unicycle - just a bit easier to keep balance because of the wheel's angular momentum conservation when turning, but also more difficult to get on)