Gen2.1.9 (ex2.11) - Help identify board layout (GD32F130C8T6)

[miro-ux]

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.

[RoboDurden]

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

[RoboDurden]

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

[RoboDurden]

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..

[RoboDurden]

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.

[RoboDurden]

The half bridge gate drivers are the IRS2002 and seem to be compatible with the firmware:

[RoboDurden]

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 ??

[miro-ux]

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!

[RoboDurden]

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 !

[RoboDurden]

You can also rework the RST pin of these cheap ST-Link-V2 dongles to work for our SWD protocol (not the UART):

[miro-ux]

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?

[RoboDurden]

There mostly is a smd resistor close to that NREST pin that you simply hold a male prototyping cable connector to:

[miro-ux]

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

Video_2023-09-30_150548.mp4

I can now see 2 leds flash when I rotate the motor by hand:

IMG_5409.mp4

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?

[RoboDurden]

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.

[RoboDurden]

Nice bat file ! Thank you !

[RoboDurden]

And please close the motor when sending speed commands. It can not spin freely with the backside bearing missing.

[RoboDurden]

@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.

[RoboDurden]

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..

[miro-ux]

@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! ☹️

[RoboDurden]

Sorry for the confusion. I think i simply had to reboot my Laptop. Windows :-/

[rhodyboland]

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

[RoboDurden]

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!