Hoverboard-Firmware-Hack-Gen2.x
Hoverboard-Firmware-Hack-Gen2.x copied to clipboard
RoboDurden
Gen2.1.9 (ex2.11) - Help identify board layout (GD32F130C8T6)
Hi, I'm a complete noob. đđģ
I can't tell if any of the layouts are the one I have.
I was able to unlock the board and flash it from Keil but now I'm afraid to power it on due to not knowing which layout to config.
The MCU is a GD32F130C8T6
I'm also not sure if I got the master/slave right.
Master:
The Slave looks identical except it has the Switch+Switch LED I think and has no charger port.
MOSFET + MCU view:
Please let me know if you need anything else to help me identify or what should I do if it's a new layout.
Good morning, 10:06 here in Germany :-)
Please help with the three gate driver chips, i can not really read the code:
I have assigned the new layout 2.11 :-)
Do NOT test a new layout without a 2 A cc (constant current) power supply !!
Most layouts share the same 6 mosfet gate driver pin because the GD32F130 only has one advanced timer whose output pins are very limited.
You need to trace the three hall inputs. Very nice double image you made :-)
Also important ist the onOff push button and the HOLD output which keeps the power on when onOff is realeased.
// Self hold defines
// important pin keeps the mosfet open after the on/off button got pushed !
// main.c:306: gpio_bit_write(SELF_HOLD_PORT, SELF_HOLD_PIN, SET);
// and turns off power on Shutdown:
// main.c:513: gpio_bit_write(SELF_HOLD_PORT, SELF_HOLD_PIN, RESET);
#define SELF_HOLD_PIN TODO_PIN
#define SELF_HOLD_PORT TODO_PORT
// Button defines
// on/off (POW) push-button. So also a connection (i guess with some smd resistor in between) to a MCU pin.
// main.c:457: if (gpio_input_bit_get(BUTTON_PORT, BUTTON_PIN))
#define BUTTON_PIN TODO_PIN
#define BUTTON_PORT TODO_PORT
I will add a new defines_2-11.h the next hours.
Welcome :-)
all three hall sensors seem to go underneath the mcu :-(
If you do not want to probe with a multimeter and a needle, we have to find the mcu pins by exclusion. Try to identify the three led panel. I have test code to link them to the hall sensors so they blink when rotating the motor manually:
#define TEST_HALL2LED // led the 3-led panel blink according to the hall sensors
I guess the led pins map to some of
PA14
PA15 = PORTA PIN15
PB3
PB4
PB5
PB8
PB9
or
PF6
PF7
If you have a max 2A CC power supply ( or CC step down dcdc module) you can try and error..
Okay you have to update your downloaded code and uncomment your layout in config.h :
#define LAYOUT_2_0 // https://github.com/flo199213/Hoverboard-Firmware-Hack-Gen2
//#define LAYOUT_2_1 // https://github.com/krisstakos/Hoverboard-Firmware-Hack-Gen2.1
//#define LAYOUT_2_2 // motor is spinning but needs a push to startup :-/
//#define LAYOUT_2_3 // 2023/09/19 motor does not run stable (sound like skipping steps in a stepper motor but it is rotating). mosfets heating up :-(
//#define LAYOUT_2_4 // NOT READY !!! https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/issues/3
//#define LAYOUT_2_11 // NOT READY !!! https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/issues/27
In remoteDummy.c uncomment line 19:
//speed = 0; // uncomment this to turn the motor manually when TEST_HALL2LED
Then turning the motor by hand might already light up some leds.
UART header might also already work. So you can load the arduino TestSpeed.ino to and ESP32 (or orther) and might receive the log struct data.
You will need a permanent on switch instead of an the push button to keep the bord powered until you have traced the two pins i mentioned earlier.
Of course there is the risk that you will break your board. With a 2A cc power supply the risk is acceptable - i think.
The half bridge gate drivers are the IRS2002 and seem to be compatible with the firmware:
There are no photo-diodes / light barriers on the backside AND id do not see a header to plugin two connectos with exteran photo-diodes ??
Hi @RoboDurden! Thanks a lot for your quick response.
I got good news -- bad news:
I flashed the layout following your instructions.
The good news is that i was also able to power it with 2A cc limit (at 12V) and I got a single green light on the LED strip. No magic smoke... đ Turning the motor with halls does nothing to leds though...
Also, I did trace that all the battery status LEDs and they are all here:
I also changed it in the layout:
// LED defines, colors probably mismatch !
#define LED_GREEN GPIO_PIN_15
#define LED_GREEN_PORT GPIOA
#define LED_ORANGE GPIO_PIN_3
#define LED_ORANGE_PORT GPIOB
#define LED_RED GPIO_PIN_4
#define LED_RED_PORT GPIOB
#define UPPER_LED_PIN GPIO_PIN_5
#define UPPER_LED_PORT GPIOB
#define LOWER_LED_PIN GPIO_PIN_6
#define LOWER_LED_PORT GPIOB
The bad news is that I can no longer connect to the target to flash the changes
I get No Target Connected & Error: Flash Download failed - Target DLL has been cancelled.
The ST-Link is connected... it's the board that doesn't work anymore. đ
I tried everything. Restarting, reinstalling St-link USB drive... updated it's firmware... Nothing works!
The green light is still there when i supply 12v and short the switch. Just can't comm with the board.
St-link Utility says to try different options like Connect under reset but nothing works.
Any idea what could it be and how to unbrick it if it's not fried? Thank you!
If you are running Windows, make a batch file in the st-flash-exe folder:
st-flash --connect-under-reset write hoverboard.bin 0x8000000.bat containing the single line
st-flash --connect-under-reset write hoverboard.bin 0x8000000
https://pionierland.de/hoverhack/gen2/ReadyToFlash/st-flash%201.7.0%20Windows%20x86%2064bit.zip
locate your latest hoverboard.bin file in HoverBoardGigaDevice/BinariesToFlash
If this does not work, you need the NREST pin Or simply turn hoverboard off and on again and then click the enter key to start the bat file..
Unplugging the st-link-v2 of course also helps sometimes..
Try tracing the three hall inputs !
You can also rework the RST pin of these cheap ST-Link-V2 dongles to work for our SWD protocol (not the UART):
I see. My cheap clone is a little different so I used this article since it looks exactly the same. Surprisingly it uses exactly the same MCU as the board (GD32F130C8T6):
What I do not get if I should now connect the NRST of the ST-Link to the NRST of the board?
Otherwise it's just not connected to anything right?
There mostly is a smd resistor close to that NREST pin that you simply hold a male prototyping cable connector to:
Thanks for all your help again! I've had no success with connecting the RST wire but it may be due to different issue.
After a lot of trial and error I think the cheap clone may be faulty and bending pushing it up and down in the USB port worked the best.
I wrote this auto-flash.bat which basically spams the st-flash command and helped me speed up the flash process and solving NRST is not connected error:
@echo off
:repeat
REM Remove REM below to add 1 sec delay
REM timeout /t 1 /nobreak > nul
color 08
cls
st-flash --connect-under-reset write hoverboard.bin 0x8000000 || goto :repeat
color 0A
echo:
echo ================================
echo ^| FLASH SUCCESSFUL ^|
echo ================================
echo:
echo Press Ctrl+C to exit or any other key to flash again.
pause > nul
goto :repeat
(It goes into ./HoverBoardGigaDevice/BinariesToFlash/)
That's what it looks like before connecting the ST-Link dongle and right after it's connected it flashes it successfully without the NRST wire
https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/assets/7188826/e4e6881d-ab44-4d0a-bc03-0848d438ed7a
I can now see 2 leds flash when I rotate the motor by hand:
https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/assets/7188826/ca72d5b7-8165-4c95-afe3-77b00d85cd59
I couldn't get the middle hall/led work and I tried every single pin:
#define HALL_A_PIN GPIO_PIN_1 // confirmed
#define HALL_A_PORT GPIOA
#define HALL_B_PIN GPIO_PIN_2 // unknown - ??????
#define HALL_B_PORT GPIOA
#define HALL_C_PIN GPIO_PIN_0 // confirmed
#define HALL_C_PORT GPIOA
There is no issue with the led itself because I can change the Red, green, orange and the led works so it's either the wrong hall pin or something else overwriting it?
How do I test the motor if it works? I've tried with speed=100 in remoteDummy.c and commenting out //#define TEST_HALL2LED but it doesn't spin. It only makes it a little harder to rotate the motor so it is working I think but can't get it to spin.
What should I try next?
It is a bit risky to also connect the 3.3V from st-link to hoverboard. Better only power the board with a 2A CC power supply. Please mount the motor so it can rotate freely. You will rip some crucial cables if the motor gets a full speed command. speed can go from -1000 to +1000. So 100 might not be enough to start the motor. I usually test with 300.
Which led is not working ? And make sure the other two have the correct color naming:
// LED defines, colors probably mismatch !
#define LED_GREEN GPIO_PIN_15
#define LED_GREEN_PORT GPIOA
#define LED_ORANGE GPIO_PIN_14
#define LED_ORANGE_PORT GPIOA
#define LED_RED GPIO_PIN_3
#define LED_RED_PORT GPIOB
#define UPPER_LED_PIN GPIO_PIN_4
#define UPPER_LED_PORT GPIOB
#define LOWER_LED_PIN GPIO_PIN_5
#define LOWER_LED_PORT GPIOB
disable the following lines by adding // before each:
#define DEBUG_LED_PIN LED_RED #define DEBUG_LED_PORT LED_RED_PORT
Then the DEBUG_LedSet macros in defines.h is defined to nothing and some code somewhere in the project will not overwrite the LED_RED behavior:
#ifdef DEBUG_LED_PIN
#define DEBUG_LedSet(bSet){gpio_bit_write(DEBUG_LED_PORT, DEBUG_LED_PIN, bSet);}
#else
#define DEBUG_LedSet(bSet)
#endif
If LED_ORANGE is not working than hit strg+shift+f and search the entire project for LED_ORANGE.
Then you see if the TEST_HALL2LED code gets overwritten which causes the LED_ORANGE not to blink like the other two.
The motor should spin nicely with TEST_HALL2LED being active.
And please close the motor when sending speed commands. It can not spin freely with the backside bearing missing.
@miro-ux your bat file is not behaving like in your nice video :-(
It simply repeats to flash forever. I need to remove the REM and increase the time to 5 seconds to pull the plug of the st-link usb dongle.
That is not really of any use. We need to try flashing very fast until it succeds and then get your nice success message.
Your || goto :repeat does not work for me.
@echo off
:repeat
REM Remove REM below to add 1 sec delay
timeout /t 5 /nobreak > nul
color 08
cls
st-flash --connect-under-reset write firmware.bin 0x8000000 || goto :repeat
color 0A
echo:
echo ================================
echo ^| FLASH SUCCESSFUL ^|
echo ================================
echo:
echo Press Ctrl+C to exit or any other key to flash again.
pause > nul
goto :repeat
Windows 10 here.
Okay, i get flash error -1 :-/
st-flash 1.7.0
2023-10-03T12:01:09 WARN common.c: NRST is not connected
2023-10-03T12:01:09 INFO common.c: F1xx High-density: 64 KiB SRAM, 256 KiB flash in at least 2 KiB pages.
file firmware.bin md5 checksum: cd6e8fd7c3d1d8cf72a50efc990c350, stlink checksum: 0x0035c6bf
2023-10-03T12:01:09 INFO common.c: Attempting to write 33340 (0x823c) bytes to stm32 address: 134217728 (0x8000000)
2023-10-03T12:01:09 INFO common.c: Flash page at addr: 0x08000000 erased
2023-10-03T12:01:09 INFO common.c: Flash page at addr: 0x08000800 erased
2023-10-03T12:01:09 INFO common.c: Flash page at addr: 0x08001000 erased
2023-10-03T12:01:09 INFO common.c: Flash page at addr: 0x08001800 erased
2023-10-03T12:01:09 INFO common.c: Flash page at addr: 0x08002000 erased
2023-10-03T12:01:09 INFO common.c: Flash page at addr: 0x08002800 erased
2023-10-03T12:01:09 INFO common.c: Flash page at addr: 0x08003000 erased
2023-10-03T12:01:09 INFO common.c: Flash page at addr: 0x08003800 erased
2023-10-03T12:01:09 INFO common.c: Flash page at addr: 0x08004000 erased
2023-10-03T12:01:09 INFO common.c: Flash page at addr: 0x08004800 erased
2023-10-03T12:01:09 INFO common.c: Flash page at addr: 0x08005000 erased
2023-10-03T12:01:09 INFO common.c: Flash page at addr: 0x08005800 erased
2023-10-03T12:01:09 INFO common.c: Flash page at addr: 0x08006000 erased
2023-10-03T12:01:09 WARN common.c: Failed to unlock flash!
2023-10-03T12:01:09 INFO common.c: Flash page at addr: 0x08006800 erased
2023-10-03T12:01:09 INFO common.c: Flash page at addr: 0x08007000 erased
2023-10-03T12:01:09 INFO common.c: Flash page at addr: 0x08007800 erased
2023-10-03T12:01:09 INFO common.c: Flash page at addr: 0x08008000 erased
2023-10-03T12:01:09 INFO common.c: Finished erasing 17 pages of 2048 (0x800) bytes
2023-10-03T12:01:09 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL
2023-10-03T12:01:09 INFO flash_loader.c: Successfully loaded flash loader in sram
2023-10-03T12:01:09 INFO flash_loader.c: Clear DFSR
2023-10-03T12:01:09 ERROR flash_loader.c: Write error
2023-10-03T12:01:09 WARN flash_loader.c: Loader state: R2 0x800 R15 0xFFFFFFFE
2023-10-03T12:01:09 WARN flash_loader.c: MCU state: DHCSR 0x3000B DFSR 0x8 CFSR 0x10000 HFSR 0x40000000
2023-10-03T12:01:09 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1
stlink_fwrite_flash() == -1
I currently try to flash a gen1 board with EFeru binary..
@RoboDurden Sorry to hear that. I think it's due to the error. If it doesn't flash successfully it will keep looping. No sure why you're getting ERROR flash_loader.c: Write error and Failed to unlock flash! âšī¸
Sorry for the confusion. I think i simply had to reboot my Laptop. Windows :-/
Hi I have this board also from a razor hovertrax. I worked on this last year and am revisiting now. I have a motor spinning using these defines:
// Self hold defines
#define SELF_HOLD_PIN GPIO_PIN_2
#define SELF_HOLD_PORT GPIOB
// Button defines
#define BUTTON_PIN GPIO_PIN_14
#define BUTTON_PORT GPIOC
shutdown main.c:485 changed to:
if (gpio_input_bit_get(BUTTON_PORT, BUTTON_PIN))
{
while (gpio_input_bit_get(BUTTON_PORT, BUTTON_PIN)) {}
ShutOff();
}
// Hall sensor defines
#define HALL_A_PIN GPIO_PIN_0
#define HALL_A_PORT GPIOA
#define HALL_C_PIN GPIO_PIN_11
#define HALL_C_PORT GPIOB
#define HALL_B_PIN GPIO_PIN_1
#define HALL_B_PORT GPIOA
// Brushless Control DC (BLDC) defines
// Channel G
#define RCU_TIMER_BLDC RCU_TIMER0
#define TIMER_BLDC TIMER0
#define TIMER_BLDC_CHANNEL_G TIMER_CH_2
#define TIMER_BLDC_GH_PIN GPIO_PIN_10
#define TIMER_BLDC_GH_PORT GPIOA
#define TIMER_BLDC_GL_PIN GPIO_PIN_15
#define TIMER_BLDC_GL_PORT GPIOB
// Channel B
#define TIMER_BLDC_CHANNEL_B TIMER_CH_1
#define TIMER_BLDC_BH_PIN GPIO_PIN_9
#define TIMER_BLDC_BH_PORT GPIOA
#define TIMER_BLDC_BL_PIN GPIO_PIN_14
#define TIMER_BLDC_BL_PORT GPIOB
// Channel Y
#define TIMER_BLDC_CHANNEL_Y TIMER_CH_0
#define TIMER_BLDC_YH_PIN GPIO_PIN_8
#define TIMER_BLDC_YH_PORT GPIOA
#define TIMER_BLDC_YL_PIN GPIO_PIN_13
#define TIMER_BLDC_YL_PORT GPIOB
Thanks for your defines.
You have an old source code. I have moved to PB14 nstead of GPIOB and GPIO_PIN_14 quite long ago. So the Uart protocols might no longer be compatible!
Hello. I have this board and have tested the 2.1.9 master dummy bin in BinariesToTest. Nothing happened except the motor brakes when I "turn it on" or hold the power button. I built my own single dummy bin for 2.1.9 by changing LAYOUT to 9 in config.h; I did leave LAYOUT_SUB as 1 as it didn't look to me like that's going to mess anything up. I also did select the correct F130 environment in PlatformIO. The board did have trouble connecting, and I thought it was the NRST issue, but it finally flashed my bin by unplugging STLink and replugging a few times with the power button held. Now with the new bin flashed, it's the same behavior, with maybe a bit more braking/holding resistance. No dummy spinning. I am using a 10A power supply.
Where do I start on this? The motor is known to work. I did try to verify PB0/PB1/PA5 for hall sensor pins on the board, but found no continuity to any of the MCU pins when the board has no power and didn't want to risk shorting pins when it's powered up (not the most precise fingers/dexterity). The board is exactly the same as the one in this issue though.
set the power supply to max 2A !!! With RemoteDummy, the three led should blink according to the motor roation. platformio support is still experimental. You might want to install the Keil IDE.. You could compile with debug information and then set lots of iBug=1 , 2,3,4 in the main() function and check with StmStudio if the code starts executing. https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/wiki/Tips-for-programming,-debugging-and-flashing
With platformio you may be able to debug step by step. Have not tested that yet.
update: flash the autodetect binary and try to connect with uart-dongle or flash the autodetect.ino to esp32/arduino
Thanks for the quick reply. It was much simpler, the defines in your repo still had PB0/PB1/PA5, but for this board it's definitely PA0/PA1/PB11 like @rhodyboland found
How easy is it to find the ADC pins on these boards? I'd like to find the current/voltage ones so the board can have a little more protection if possible
Indeed, the adc defines are missing:
// ADC defines
//#define VBATT TODO_PIN // uncomment this line when you have verified the pin/port
//#define CURRENT_DC TODO_PIN // uncomment this line when you have verified the pin/port
Please run autodetect binary (remoteAutodetect) to find them.
Or simply try PA4,PA6 and PA5, these are the most common pins. Or A0 A1 A2 A3 A4 A5 A6 A7 B0 B1
I'm trying autodetect, and not having luck:
Note Hall pins are already known as A0, A1, B11. It can't find all Hall pins, and thus can't get to finding CURRENT_DC pin. VBATT test also gives nothing:
What can I try? I would like current protection on the board if possible
I guess you are compiling with platformIO ?? Please update to latest code. there was an update that fixed the floating point output in autodetect.
It should look like
PA0: 29.74 V +- 0.00
PA0: 29.73 V +- 0.01
PA0: 29.73 V +- 0.00
platformio support was introduced by another user after i had coded the autodetect. So it has never been tested by me with platformio. The platformIo binaries seem to have different timings, which could explain why hall detection is failing for you.
Please flash the precompiled autodetect binaries with autoflash.bat (windows): https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/tree/main/BinariesToTest
You can always trace the currentDC pin manually:
Or try all the possible adc pins and monitor
float batteryVoltage; // global variable for battery voltage
float currentDC; // global variable for current dc
With StmStudio: https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/wiki/Tips-for-programming,-debugging-and-flashing
Okay, just to save time, can you confirm if you mean these autodetect binaries?
It says they were last committed last year, so not sure if they have the update that fixed the floating point issue you're talking about in autodetect
the floating point issue was only for platformIO compilations. these binaries where compiled with Keil. But i updated them as i improved the code today. Would be nice if you test the new autodetect. Did work for my 2.1.4 test setup. As you only have the master-slave header for serial comminucation, this is the binary for you:
https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/blob/main/BinariesToTest/hoverboard%20autodetect%20GD32F130%20tx%3DPA2%2C%20rx%3DPA3.bin
Always only run autodetect with a 2A constant current power supply. If you have none, use the 1.5 A charger that came with the hoverboard.