NO issue, Stock Firmware backup.

[atc1441]

I have a feew boards where the readout is not locked, here is a backup of them.

Its in HEX format.

https://gist.github.com/atc1441/c4cc8af0dc0ed48994210da552985a14

maybe you need it when you want to go back to stock, it works with the dauther boards in this picture: https://www.bilder-upload.eu/upload/58cb89-1561888915.jpg

[p-h-a-i-l]

Really nice, thanks! Always wanted to pull the original firmware somehow.

[btsimonh]

hi atc1441! great find. Just for posterity, What are the board markings for the main board? Did you try to extract from the sensor board?

[p-h-a-i-l]

Should we copy this hexfile into this organization? To keep it close to other hoverboard related stuff?

[atc1441]

Nice that it is helpful,

here is a link to the hoverboard on ebay: http://rover.ebay.com/rover/1/707-53477-19255-0/1?icep_ff3=2&pub=5575152713&toolid=10001&campid=5337805630&customid=&icep_item=223515232365&ipn=psmain&icep_vectorid=229487&kwid=902099&mtid=824&kw=lg

Here is a picture of the HB Main board for Comparison: https://www.bilder-upload.eu/upload/fc168e-1561973785.jpg

here is the HEX File of the sensor Board: https://gist.github.com/atc1441/275d34cdfff8c08ecbeb73e4b8071adf

you can do whatever you want with the files :)

[p-h-a-i-l]

cool! Can you pull the fw of both sensor boards? And I can not rad the markings on the microcontrollers. Are those ST or GD?

[atc1441]

Both are GD see here:

https://www.bilder-upload.eu/upload/6aa78f-1561974518.jpg https://www.bilder-upload.eu/upload/c369fc-1561974527.jpg

unfortunately i dont know which sensor board is which so i cannot provide the other HEX file, i have 6 Sensor boards that lock total same ^^

[p-h-a-i-l]

too bad. Lets hope left and right are identical. I was hoping to flash a complete set if someone wants to restore the whole board and the sensor boards are not compatible

[atc1441]

Yesterday i got 4 new HB if someone is interested in the HEX i can try to read them out. https://www.bilder-upload.eu/upload/3cded8-1561974770.jpg The Black one was Locked.

I could read all 6 Sensor Boards out, but we would still dont know which one is which :D

[btsimonh]

I believe the sensor boards are identical; they certainly sell replacements in singles. Also note I logged the 'calibrate' command from mainboard to sensor board (only one side!!!) - data in is the wiki. Q: anyone know how to easily decompile? Tried the common online one, but it insists (wherever I put the data) that the data is in a non-executable segment, and so will not disassemble.

[atc1441]

I tried the firmware https://github.com/bipropellant/bipropellant-hoverboard-firmware on a Hoverboard with the Firmware of the Sensor board uploaded here but it doesn't seem to work with it, i always get: sensor data not 55 or AA i checked the data the module is sending out with an logic analyzer but unfortunately i deleted the log file and the Hoverboard is already screwed together :D

dont know if setings are wrong, maybe i will log it this evening again to see what is going on at the protocoll of the sensorboards.

[btsimonh]

ok; so are you saying you flashed the sensor board, or just used the sensor board from which you extracted the firmware? I have a small variation of the firmware which allows you to log all CHANGES to the incoming message (I used it to log the message OUTPUT from an original firmware main board.... :) ). Trouble is it's both repos before the major mods; s a little complex to commit :(.

possible: if using platformio, and 'hoverboard' env to build, then you SHOULD have USART2_BAUD_SENSE set to 1, which SHOULD auto-detect the baud rate, but no guarantees this works perfectly.... :). So, it could be an off baud rate.

Do you get a data dump after the message? (if they are going too fast, it may all just be a corrupted mess...). If you want to see the data, you could only message and dump when the data changes by keeping a copy.....

[atc1441]

So, i was using a Mainboard with the Sensor Boards from where i got the firmware.

and only the the Error message, the baudrate: 52177 seems correct because in my logik analyzer it matches the bytes perfectly, one strange think, i was only seeing the Data that goes to the mainboard from the Sensor Boards is that correct?

[btsimonh]

the mainboard->sensor board data is sent less often than in the factory firmware, but sent twice because we don't really know if 0x1xx is a start code or an end code. It only really gets sent when the LED colours change..... so you may not see it often. When you say 'see', you mean on the logic analyser? Post the serial you get from your software serial port? the boards look VERY similar to mine (also GD32 and ~52000 baud). Interestingly, I have another board which is stock firmware. On that, i have a 'sensor board failure', yet can read angles from the 'failed' side using our firmware - need to investigate further.... (these are ~26000 baud, and the other sex connector).

[btsimonh]

p.s.

Nice that it is helpful,

first time firmware has been extracted, i believe.

[atc1441]

mhh lets try it the other way. i just hocked it up again, here is a logik analyzer log from stock firmware on sensorboard and on mainboard https://www.bilder-upload.eu/upload/0e7b4e-1562005368.png

the top is with 52177 baud analyzed. Here the whole file, can be opened with saleae logik 16 MHz, 16 B Samples [1].zip

this is the log output from the custom firmware:

sensor data not 55 or AA
sensor data not 55 or AA
sensor data not 55 or AA
sensor data not 55 or AA
sensor data not 55 or AA
sensor data not 55 or AA
sensor data not 55 or AA
sensor data not 55 or AA
sensor data not 55 or AA
sensor data not 55 or AA
sensor data not 55 or AA
sensor data not 55 or AA
sensor data not 55 or AA

[btsimonh]

hmm.. serial overflow means you are not seeing the dumps... try the below mod; maybe we can get the data that way.... should log only when data changes... and for the first packet. be careful to keep the sensor board still.

    SENSOR_FRAME *f = (SENSOR_FRAME *)s->buffer;

    if ((s->buffer[5] != 0xAA) && (s->buffer[5] != 0x55)){
        static unsigned char buf[2][20];

        if (memcmp(buf[s->side], b->buffer, s->bytecount)) {
                char t[10];
                sprintf(t, "side %d:", s->side);
                consoleLog(t);
                consoleLog("sensor data not 55 or AA\r\n");
                for (int i = 0; i < s->bytecount; i++) {
                    sprintf(t, "%2.2X ", s->buffer[i]);
                    consoleLog(t);
                }
                consoleLog("\r\n");
                memcpy(buf[s->side], b->buffer, sizeof(buf[s->side]));
        }
        copy = 0;
    }

but also strange we're not seeing the log of 'side'? Double check it's the latest firmware....

[atc1441]

i have tested a bit more, but your code does not run for me, it says b not defined. dont know where it should be declared.

i have tested with this version: https://www.pionierland.de/hoverhack/ the bipropellant version and got this output from debug serial:

Sensor RX timeout
side 0:FF 09 70 6C 40 Sensor RX timeout
side 0:69 13 38 6E D0 side 0:25 62 EF Sensor RX timeout
side 0:F0 89 13 
Sensor RX timeout
side 0:78 6E DE A7 AD Sensor RX timeout
side 0:1D 69 11 FF 
Sensor RX timeout
side 0:2E 69 06 E9 
side 1:25 62 FF 22 49 
Sensor RX timeout
side 1:sensor data not 55 or AA
13 78 CE E5 D6 42 CC 
Sensor RX received
Sensor RX timeout
side 1:78 CE AD D4 4A CC 
side 1:CE side 1:Sensor RX timeout
side 1:29 B0 C6 27 D6 4A CC side 1:F5 42 F5 D2 B4 Sensor RX timeout
F8 
Sensor RX timeout
side 1:side 0:11 Sensor RX timeout
side 0:FF D5 A3 AF 97 11 F0 Sensor RX timeout
D4 Sensor RX timeout
side 0:11 70 67 Sensor RX timeout
side 1:49 62 B5 AC D4 E2 

side 1:Sensor RX timeout
side 1:16 
49 E2 Sensor RX timeout
side 1:sensor data not 55 or AA
49 E2 31 2E D7 CA 
side 0:FC C3 1D 29 Sensor RX timeout
side 0:71 Sensor RX timeout
side 0:sensor data not 55 or AA
19 09 13 78 37 33 
side 0:FF 4E EA side 0:6E E3 6E 
side 1:25 D6 
Sensor RX timeout
side 1:38 
Sensor RX timeout
side 1:B0 C6 B9 D6 CA C4 
Sensor RX timeout
side 1:
Sensor RX timeout
side 1:26 69 06 side 1:63 D6 
side 1:E2 11 Sensor RX timeout
29 
side 1:
Sensor RX timeout
side 0:sensor data not 55 or AA
E7 side 1:3D side 1:B7 
side 1:E3 Sensor RX timeout
side 1:sensor data not 55 or AA
91 D4 
Sensor RX timeout
side 1:6E D6 side 0:09 38 75 
Sensor RX timeout
side 0:BF 
FF F9 side 0:
side 0:FF B9 A7 AF Sensor RX timeout
side 1:C3 D6 CA C4 A7 side 1:CF D6 
Sensor RX timeout
side 0:sensor data not 55 or AA
FF 79 A3 AF 95 79 
side 0:77 F8 A2 BD 9D 79 
side 0:95 59 Sensor RX timeout
side 1:sensor data not 55 or AA

is there some custom firmware for these sensor boards somewhere ?

[btsimonh]

sorry, typo. not b->buffer, should be s->buffer. Basically, it's making a copy of the buffer, and comparing it to the next in, and only dumping when the buffer is different.

interesting to see the online compilation! But it's not setting auto sensing on baud rate, so data may not being interpreted correctly. (although baud rate seems configured correctly?).

BUT. I've taken a look at the logic analyser trace. Is this interpreting 9 bit serial? If so, then seems you have 14 byte (word) frames!. The frames also DO have AA in them, and apparently in the right place.

So, I see the sequence as: 256 -> 0x100, start word 14 186 -> first angle 14 186 -> duplicate angle 170 -> 0xAA 88 -> accelleration? 88 -> duplicate accelleration? (a gap? - seems to move in data) 139 ->roll angle 1 -> everything from her unknown and exciting! 11 100 100 10

I can't see from the code why it would not happily eat this; it's coded to work for up to 20 bytes (and throw away if more). Maybe the 'gap' is not handled correctly by the serial mode we are in? Maybe compare what the logic analyser thinks the serial is with our config (e.g. stopbits, etc.). Also, look through the code, and see if you can see a problem if it gets more than 10 bytes (mine is 10...).

[atc1441]

In the logik analyzer it was set to 9bit serial and 52177 baud. i can imagine that the data is comming to fast and so it will be confused. because i can see in the log that sometimes data gets trough.

will test the main repo with your typo fixed.

[atc1441]

another question, in normal Hoverboard mode if i start the hoverboard it is not in HB mode, i need to push twice on food pads and then it will be enabled? i never could test that far and so i just want to know it would work if it works

[atc1441]

Ok, got it working, it seems it is a different problem. i have used this repo https://github.com/bipropellant/bipropellant-hoverboard-firmware with platformio and enabled the env_default = hoverboard in platformio.ini there it has IGNORE_GLOBAL_CONFIG defined, but it seems that some configurations are needed to get it working. so i deleted IGNORE_GLOBAL_CONFIG. so i can use it as intended. Double tab on Pads and in the log the enable message is showing, and driving is also possible.

so i can confirm that the hex file from the SensorBoard's i uploaded do work with the custom firmware.

Also i can confirm that both SensorBoard's are the same an can be used on both sides, left or right.

[p-h-a-i-l]

Ok, got it working, it seems it is a different problem. i have used this repo https://github.com/bipropellant/bipropellant-hoverboard-firmware with platformio and enabled the env_default = hoverboard in platformio.ini there it has IGNORE_GLOBAL_CONFIG defined, but it seems that some configurations are needed to get it working. so i deleted IGNORE_GLOBAL_CONFIG. so i can use it as intended.

The defines you need are set by selecting the intended environment in platformio.ini. The IGNORE_GLOBAL_CONFIG makes sure they are not set twice or contradict each other.

so i can confirm that the hex file from the SensorBoard's i uploaded do work with the custom firmware. Also i can confirm that both SensorBoard's are the same an can be used on both sides, left or right.

very cool, thanks!

[atc1441]

unfortunatly sometimes it will shortly stop while driving, like it lost some connection to the sensorboard, dont know right now, hard to test it, no serial log while driving^^ Driving is also quite slow, is this correct and need to be tweak individualy?

The defines you need are set by selecting the intended environment in platformio.ini. The IGNORE_GLOBAL_CONFIG makes sure they are not set twice or contradict each other.

But for example SOFTWARE_SERIAL_RX_PIN isnt set anywhere else in platformio.ini only in config.h

[p-h-a-i-l]

But for example SOFTWARE_SERIAL_RX_PIN isnt set anywhere else in platformio.ini only in config.h

look where #endif // IGNORE_GLOBAL_CONFIG is. if it is not defined, config.h sets a default value.

#ifndef SOFTWARE_SERIAL_RX_PIN
  #define SOFTWARE_SERIAL_RX_PIN GPIO_PIN_2
#endif

Keeps the config slim!

[atc1441]

Here is more serail log. added IGNORE_GLOBAL_CONFIG again and now it isnt working anymore, but here the log where its not working:

Power button up at startup
cf_speedCoef 10666, n_commDeacvHi 60, n_commAcvLo 60
side 0:sensor data not 55 or AA
00 00 00 00 AA 58 58 00 00 0B 
angle change > 200 0 -> -556:
Sensor RX received
side 1:sensor data not 55 or AA
00 00 00 00 AA 58 58 00 00 0B 
Sensor RX received
colour 0 0 -> 8 (0)
colour 1 0 -> 8 (1)
side 0:sensor data not 55 or AA
00 CB FD AA 57 57 1E FA 0B 64 
Sensor RX timeout
Sensor RX timeout
Sensor RX received
Sensor RX received
Stepped On
colour 1 8 -> 4 (2)
Stepped Off
SensorOK -> 0 in unprocessed poll
colour 1 4 -> 8 (3)
Sensor RX timeout
Sensor RX timeout
Sensor RX received
Sensor RX received
Stepped On
colour 1 8 -> 4 (4)
Stepped Off
colour 1 4 -> 8 (5)
Stepped On
double tap -> hoverboard mode
disable by rollHigh
colour 1 8 -> 4 (6)
Stepped Off
colour 1 4 -> 8 (7)
Stepped On
double tap -> hoverboard mode
colour 1 8 -> 4 (8)
Stepped Off
colour 1 4 -> 8 (9)
Sensor RX timeout
Sensor RX timeout
Sensor RX received
Sensor RX received
Sensor RX timeout
Sensor RX timeout
Sensor RX received
Sensor RX received

[atc1441]

ok sry, it was realy just the roll this time. if i hold it flat it works.

but still timeout sometimes i thing that are the short stops while driving

this is what i receive when the motor is stoping while driving:

Sensor RX timeout
SensorOK -> 0 in unprocessed poll
disable by hoverboard mode & step off
colour 1 c -> 4 (53)
Sensor RX received
colour 1 4 -> c (54)
enable by hoverboard mode & !rollHigh
Sensor RX timeout

but still dont know why it now works with the communication ^^

[atc1441]

I changed the time out in https://github.com/bipropellant/bipropellant-hoverboard-firmware/blob/master/src/sensorcoms.c#L213 to 300 and didnt got any timeoutmessages so far, but while driving there are still stops of the motors.

still didnt get the speed up. I am nearly falling forwart when leaning because it drives so slow, if i hold it by handy and turning it further it will go very fast but thats not possible by standing on it, can i somehow double the speed that is getting out of the angle? or can i just double the readed angle ? i tried to change the SPEED_COEFFICIENT but that doenst change anything.

[p-h-a-i-l]

Did you try increasing the current limit? The stops of the motors could be EMI problems, see https://github.com/bipropellant/bipropellant-hoverboard-firmware/issues/42. These EMI issues are also very troubling for my build..

[btsimonh]

Yes, serial issues, whether with Software Serial, or with sensor boards, causes me a lot of issues. Mine works well enough to ride, but I do see a lot of 'not 55/AA' and 'angle missmatch'. Since we see serial issues on sensor boards, I'm thinking we must have something wrong. To test the current limit - when set to 15A (ascii serial command 'fcl1500\n'), you should not be able to hold the wheel still when you give it some angle. You can read the setting with 'fcl\n'. If you change it and want to write it permanently to flash, use 'fm1234\n' to cause a flash write.

[atc1441]

Will try it later, do you mean something wrong in the motor driving? because the original boards doenst seem to have such problem. i can remamber than Niklas Fauth told me as i met him that they had the original sourcecode from one Hoverboard? dont know if i missunderstoud that.

[btsimonh]

either something wrong in the USART/GPIO setup for USART communications which makes it susceptible to interference (on software serial, I've tried different GPIO speeds & pullups), or something wrong in the way we drive the motors which makes the whole system more noisy. But yours seems MUCH worse than mine.

[atc1441]

Ok i tought about what you wrote, since we are able to debug and read the registers from the stock firmware i try to reverse engeneerd it a bit,

the register for usart2 and 3 are ad followt: 0x40004800: 90 00 00 00 64 00 00 00 66 02 00 00 0c 30 00 00 0

that means the baudrate register is: BaudRateRegister= 0x66 und 0x02 so 0x266 so dec 614 this so 32000000/614 = 52177 Baud are set in the Register.

The control register one is: 0x300C so as follow: Stockfirmware:

re re UE M Wa PC PS Peie      TXeie  TCIE RXNEIE IDLEIE TE RE RWU SBK
0  0  1  1 0  0  0  0         0      0    0      0      1  1  0   0 

Customfirmware:

re re UE M Wa PC PS Peie      TXeie  TCIE RXNEIE IDLEIE TE RE RWU SBK
0  0  1  1 0  0  0  0         1      0    1      0      1  1  0   0 

Only the Interupt is different on stock and custom, in custom it is enabled in stock not. that means they poll it?!

also here are the Port register from stock firmware:

GPIOA
0x40010800: 00 4b 33 b4 bb 4b 88 88 e8 d8 00 00 20 b0 00 00
GPIOC
0x40011000: 00 00 00 bb 4b 44 44 44 00 fa 00 00 00 00 00 00
GPIOB
0x40010c00: bb 43 48 44 44 4b b4 bb 9f f7 00 00 14 00 00 00

didnt locked into other registers right now.

The manual for the register is here: https://www.st.com/content/ccc/resource/technical/document/reference_manual/59/b9/ba/7f/11/af/43/d5/CD00171190.pdf/files/CD00171190.pdf/jcr:content/translations/en.CD00171190.pdf

everything was done via a clone st-linkV2 and openocd with this cmd: openocd.exe -s ..\scripts\ -f interface\stlink-v2.cfg -f target\stm32f1x.cfg and then connected to it via telnet on port 4444

i still get timeouts even with the 100% right baudrate

[atc1441]

Here is the full dump of the registers for the stock and custom firmware: RegisterDumpCustomFirmware.txt RegisterDumpStockFirmware.txt

[btsimonh]

haha, a man of my own heart; if i was not up to my eyes in 'real' work, i would have done this myself (or looked at my original logs....); did not want to suggest you did it because it's a faff.... However, as you are doing it now, pls dump the ADC and tim1/tim8 regsiters :). They will tell us something about the PWM drive.

Also the GPIO regs may be revealing about GPIO speeds, etc, in use.

[atc1441]

As i am working on NRF52 in another project(https://www.youtube.com/watch?v=SQsxk_iKhg8 and https://github.com/fanoush/ds-d6) this is a realy good learning thing so no wasted time :) fanoush is a realy good help, just saying :D

Here is the dump of ADC and timer 1 and 8:

ADC3
0x40013c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x40013c20: 00 00 00 00 ff 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x40013c40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

ADC2
0x40012800: 1e 00 00 00 00 01 00 00 01 90 1e 00 08 12 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x40012820: 00 00 00 00 ff 0f 00 00 00 00 00 00 00 00 10 00 00 00 00 00 2b 00 00 00 00 34 17 00 ad 07 00 00
0x40012840: ea 07 00 00 00 00 00 00 00 00 00 00 12 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

ADC1
0x40012400: 1c 00 00 00 00 01 01 00 01 91 0e 00 41 80 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x40012420: 00 00 00 00 ff 0f 00 00 00 00 00 00 00 00 10 00 00 00 00 00 8a 01 00 00 00 80 17 00 f3 07 00 00
0x40012440: f8 07 00 00 00 00 00 00 00 00 00 00 28 06 12 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Timer1
0x40012c00: c5 00 00 00 21 2a 00 00 00 00 00 00 81 00 00 00 1e 00 00 00 00 00 00 00 68 68 00 00 68 78 00 00
0x40012c20: dd 1d 00 00 85 00 00 00 03 00 00 00 00 02 00 00 01 00 00 00 ff 00 00 00 ff 00 00 00 ff 00 00 00
0x40012c40: fd 01 00 00 20 11 00 00 00 00 00 00 c5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Timer8
0x40013400: c5 00 00 00 21 2a 00 00 00 00 00 00 81 00 00 00 1f 00 00 00 00 00 00 00 68 68 00 00 68 00 00 00
0x40013420: dd 0d 00 00 3a 00 00 00 03 00 00 00 00 02 00 00 01 00 00 00 ff 00 00 00 ff 00 00 00 ff 00 00 00
0x40013440: 00 00 00 00 20 11 00 00 00 00 00 00 d5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

will try to decode it further.