Gen2.1.5 (ex2.4) ([Submission] Another board layout)

[Batman313v]

My Board:

I have another board with another different layout 😅

Layout of Board A (Master):

Layout of Board B (Slave):

Plan:

I saw this submission and will be trying to also document my board using the same process. I just ordered some needle probes for my multimeter as well as a digital microscope for better close up imaging. Those will be here by the end of the week.

Steps:

The Steps I plan to follow:

• Probe the pins of the GD32F130C8T6 to find the routing to the MOSFET drivers.
• Images each IC for documentation
• I also hope to find the pins that controlled the LEDs as well as see if the buzzer pin is different on this board.

I decided to create a new issue because my board is different from the other submission I and figured it would be easier to keep things organized this way. I will update this thread with more info as I go. I am pretty new to imbedded firmware but look forward to learning as much as I can to help get this layout documented as well.

[RoboDurden]

Nice.
I already added your photos as layout 2.4 to this repo
and happily had a closer look to your gate driver chips: https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/blob/main/Schematics_2.4/hoverboard_gen2-4_mosfet_pins.jpg

Maybe these three 8 pin chips are like https://www.infineon.com/dgdl/Infineon-IRS2005S-DataSheet-v02_00-EN.pdf?fileId=5546d462533600a4015364c4246229e1

The 8 pin SO-8 seems to be that dual op-amp for adc amplification: https://hmsemi.com/downfile/HM8631_HM8632_HM8634.PDF (simply search the pdf for C32X

Should be no big deal for you to adapt a new defines_2-4.h file.
A simple sewing needle somehow attached to one probe of a diode-tester multimeter is what i used.

This IM X439 CFC chip might be an IMU sensor ?

[Batman313v]

Update:

I was able to get the routing for the MOSFETs and Drivers and it is as follows:

Key:

• Red for Visible Traces
• Blue for Traces that move between layers

The MOSFETS are Samwin HF FK2A4 SW076R68E7T
The MOSFET Drivers are IDR ID2005 M19AKERG

This is all I was able to do tonight on this board. Is there anything else I should probe to get the defines_2-4.h file working on this board or should I start on Board A tomorrow? I do eventually want to get the LED pins documented as well but that's more of a secondary thing since I can just control lights from the main Arduino sending the commands until then.

I also have another hoverboard (the same kind) that I plan to document where everything is plugged into (including the LEDs since I forgot to do that the first time) during the disassembly of that one.

[RoboDurden]

Fine. I added some images to https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/tree/main/Schematics_2.4

and added a https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/blob/main/HoverBoardGigaDevice/Inc/defines_2-4.h

the mosfet pins are the same as layout 2.0 :-)
If you are lucky most of the other pins as well.

But you should check.

At least the hall inputs and the adc inputs. See https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/blob/main/Schematics_2.4/hoverboard_gen2-4_pins.jpg

Of course the self-hold digital ouput and the on/off button are also important.
The buzeer and the red and green led help to see that the board is working as intended.

In fact it would be good if you try to verify all //TODO lines of defines_2-4.h :-/

Keep on going :-)

[Batman313v]

Update

I have more pins figured out with a few minor changes to the defines_2-4.h file but I have a few questions.

First let me say thank you so much for the help. I am learning so much on this project and really appreciate it.
My knowledge of PCB design is still fairly limited so I don't completely understand where to look to find some of the pins. These are the ones I have left over still:

// Mosfet output
#define MOSFET_OUT_PIN GPIO_PIN_13	//TODO
#define MOSFET_OUT_PORT GPIOC		//TODO

// Timer BLDC short circuit emergency shutoff define
#define TIMER_BLDC_EMERGENCY_SHUTDOWN_PIN GPIO_PIN_12	//TODO
#define TIMER_BLDC_EMERGENCY_SHUTDOWN_PORT GPIOB		//TODO

// ADC defines
#define VBATT_PIN	GPIO_PIN_4			//TODO
#define VBATT_PORT GPIOA				//TODO
#define VBATT_CHANNEL ADC_CHANNEL_4
#define CURRENT_DC_PIN	GPIO_PIN_6		//TODO
#define CURRENT_DC_PORT GPIOA			//TODO
#define CURRENT_DC_CHANNEL ADC_CHANNEL_6

// Self hold defines
#define SELF_HOLD_PIN GPIO_PIN_2		//TODO
#define SELF_HOLD_PORT GPIOB			//TODO

// Charge state defines
#define CHARGE_STATE_PIN GPIO_PIN_0		//TODO
#define CHARGE_STATE_PORT GPIOF			//TODO

I'm gonna do some research on ADCs tonight and see if I can figure out how this works. I tried to probe around a little and I just don't know enough to get any valuable information out of it. Everything I probed just went to vss or vdd pins but no GPIOs.

I think the self hold is a latching circuit? I don't know much about those yet either so I'll be looking into that as well.

I don't even know where to begin for the charge state pins... I thought that was handled in the charger itself.

---

And I had some questions about these ones:

#define UPPER_LED_PIN GPIO_PIN_1	//TODO
#define UPPER_LED_PORT GPIOA		//TODO
#define LOWER_LED_PIN GPIO_PIN_0	//TODO
#define LOWER_LED_PORT GPIOA		//TODO

Are these only for hoverboards that had under glow lighting?

// Debug pin defines
#define DEBUG_PIN GPIO_PIN_4	//TODO
#define DEBUG_PORT GPIOB		//TODO

Is this referring to a debug header? Like this one?

---

I have a lot more photos and better documentation for these boards now and I took apart another one to document where some of the other headers went to. The photos aren't complete yet but I've added the new routes I found today and some labels for the unknown connectors.

Documentation

Here is the documentation I have so far in markdown format:

MCU: https://www.gigadevice.com/product/mcu/arm-cortex-m3/gd32f130c8t6


# A Board
## Buzzer
PB8

# B Board
## MOSFETs
#### Driver A (G)
PA10 -> HIN
PB15 -> LIN

#### Driver B (B)
PA9   -> HIN
PB14 -> LIN

#### Driver C (Y)
PA8   -> HIN
PB13 -> LIN


## BLE Speaker
TODO

## HALL
HALL C (Y) -> PB4
HALL B (B) -> PB5
HALL A (G) -> PB0

## UNPOP 1 (LED 0)
**PINS**
`  0  |  1   |   2  |  3 `
`NULL | NULL | NULL | V+`

**MCU**
0 -> PC13
1 -> PC14
2 -> PC15

## UNPOP 2
LED 0 PINS rotated 90° CC

## LED 1
**PINS**
`  0  |     1     |   2  |  3 `
`NULL | GREEN LED | NULL | V+`

**MCU**
0 -> PF0 (RED)
1 -> PF1 (GREEN)
2 -> PB2 (BLUE)

## TO MASTER
` 0  | 1 | 2 | 3 `
0 -> V+
1 -> PA2
2 -> PA3
3 -> GND

## UNPOP 3
` 0 | 1 `
0 -> V+
1 -> PA7

[RoboDurden]

Good work.

The 8 pin SO-8 seems to be that dual op-amp for adc amplification: https://hmsemi.com/downfile/HM8631_HM8632_HM8634.PDF (simply search the pdf for C32X

OutA and OutB lead to a SMD resistor.
From behind that resistor you should already find the diode tester beeping when scratching with the needle over all MCU pins.

If not you need to probe the nearby and components to learn where the information of OutX is going.

Do you have Keil installed or should I compile for you ?

In Keil you can search the defines to see where they are used in the code to understand what purpose they i have.

I live outdoors again since yesterday. But I should have some minutes to unpack and open my Toughbook ..

[Batman313v]

After probing around for a few hours I think I figured it out. I followed all the components but I kept getting further and further away from the MCU eventually stopping elsewhere then I noticed these two stray leads that went directly from the MCU to the Op-Amp and sure enough I think OUT A goes to PA0 and OUT B goes to PA1. These are the only two pins that set the tester off. I'm not 100% confident about this as there doesn't seem to be any resistors when going this route. But this is the only path I could find leading to any pins.

I don't have it installed yet, I'll work on that next 👍

[RoboDurden]

That is okay if OUT is directly connected to a ADC input Iof the MCU. That little SMD resistor from OUT to -IN is the feedback resistor of the op amp loop that sets the factor of amplification.

Sorry when my instructions had been misleading and it took you several hours.

Will update the defines_2-4.h today.

But if you plan to install Keil anyway you might want to fork my repo, change the file yourself and make a pull request. I think that is what it is called.
Then I can import your changes with a single click :-)

[Batman313v]

Gotcha that makes sense. It's all good 👍 I learned a lot poking around and researching different circuits. Once I get Keil installed and setup I'll definitely submit a pull request once I get a working file

[RoboDurden]

I fear you still need to figure out which of the two adc pins is battery voltage and which is current_dc :-/
The current is measured at the shunt smd resitor to the right of the mosfets and to the left of the capacitor.
You should be able to measure a low resistance (multimeter) from either +INB or +INA to the left side of that shunt smd resistor. As that shunt resistor is very low you should see the same resistance to GND from one of tose +IN.
The other +IN might have some resistance (1k - 10k ?) to the red positive battery cable.

Still todo:

MOSFET_OUT_PIN

[RoboDurden]

MOSFET_OUT_PIN

seems to be an ordinary LED output ?

Hoverboard-Firmware-Hack-Gen2.x/HoverBoardGigaDevice/Src/led.c

Line 91 in 8fba5e5

gpio_bit_write(MOSFET_OUT_PORT, MOSFET_OUT_PIN, counter_Blue >= setValue_Blue ? RESET : SET);

TIMER_BLDC_EMERGENCY_SHUTDOWN_PIN

Is initialized here but never used somewhere else in code.

Hoverboard-Firmware-Hack-Gen2.x/HoverBoardGigaDevice/Src/setup.c

Line 176 in 8fba5e5

gpio_mode_set(TIMER_BLDC_EMERGENCY_SHUTDOWN_PORT , GPIO_MODE_AF, GPIO_PUPD_NONE, TIMER_BLDC_EMERGENCY_SHUTDOWN_PIN);

SELF_HOLD_PIN

This important pin keeps the mosfet open after the on/off button got pushed !

Hoverboard-Firmware-Hack-Gen2.x/HoverBoardGigaDevice/Src/main.c

Line 306 in 8fba5e5

gpio_bit_write(SELF_HOLD_PORT, SELF_HOLD_PIN, SET);

and turns off power on Shutdown:

Hoverboard-Firmware-Hack-Gen2.x/HoverBoardGigaDevice/Src/main.c

Line 513 in 8fba5e5

gpio_bit_write(SELF_HOLD_PORT, SELF_HOLD_PIN, RESET);

What is that ?P6504 8 pin smd chip on the master bottem right ? I guess it is a step down chip from battery voltage (63 Volt smd capacitor) to about 14 V (25V smd capacitor) to drive the gate voltages of the mosfets.
These 14V then get regulated down to 5V by the 78M05 which then can regulated down to 3.3V by the tiny A1117.

But i am not sure if 14V are needed because we have gate-driver-chips anyway which might generate their gate voltages themselves.
Anyway, the PWR Btn should somhow lead to a pin of that little 8pin chip.
On to this same pin should "somehow" connect the MCU SELF_HOLD_PIN pin.
That is how you can identify it.

With the Gen1 boards there is a big TIP127 transistor that is activated by the on/off button an hold by the Supply_Enable_MCU pin. See the schematics i added to https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/blob/main/Schematics_2.0/hoverboard_gen2-0_uart_pins_gd32F130C8.jpg

BUTTON_PIN

this the on/off (POW) button. So also a connection (i guess with some smd resistor in between) to MCU pin.

Hoverboard-Firmware-Hack-Gen2.x/HoverBoardGigaDevice/Src/main.c

Line 457 in 8fba5e5

if (gpio_input_bit_get(BUTTON_PORT, BUTTON_PIN))

CHARGE_STATE_PIN

This seems to be a digital input that hast to be high in order to enable the motors:

Hoverboard-Firmware-Hack-Gen2.x/HoverBoardGigaDevice/Src/main.c

Line 381 in 8fba5e5

chargeStateLowActive = gpio_input_bit_get(CHARGE_STATE_PORT, CHARGE_STATE_PIN);

If we can not find it it should be okay to simply comment this line because chargeStateLowActive in initialised as set = true

DEBUG_PIN

seems to be never used in code.
Ctrl+Shift+F = Find In Files in Visual Code.
Ctrl+F (Look in Current Project) in Keil IDE

I have updated the defines_2-4.h

[Batman313v]

Update

I did a little studying up on latch circuits and while I can't seem to find a datasheet for this IC I hope I understand the circuit enough to figure this out.

SELF_HOLD_PIN

I'm guessing this is PA6. The Header on the right in order from top to bottom is 12V GND SW. I'm guessing SW stands for Switch and is probably used in another variant of this board or for QC testing which I think would reinforce my hope as setting PA6 should accomplish the same thing as a switch.

BUTTON_PIN

PA5

TODO

I still need to find the CHARGE_STATE_PIN as this would be nice to have as a backup incase the battery voltage gets to low.

Notes

If the MOSFET_OUT_PIN seems to be for an LED output it is probably for some boards that have other external LEDs like the ones with it on the front and back. My boards don't have those so I don't think I need to worry about it.

I'm also not going to worry about the TIMER_BLDC_EMERGENCY_SHUTDOWN_PIN as I wouldn't even know what this is referring to. Possibly some older models with a timer IC to prevent overheating? As you pointed out it isn't used again so I don't think I'm gonna worry about this one either. This also goes for the DEBUG_PIN as I can just use UART and the LEDs for some basic debugging.

I finally got Keil installed on my machine, I thought I was having driver issues for the longest time but turns out my ST-Link was bad. I ordered a new one and it should be here soon.

[RoboDurden]

Nice to hear from you again :-)
If you add battery plus (36V), battery minus (gnd) and DC out (the step down regulated voltage, probably something like 14V) to you circuit, we could figure out what that little chip likely is doing.
And you could check if pressing the onoff button will temporary activate the 14V , 5V , 3.3V voltage regulators chain.

I will compile a firmware for you later this day.

[RoboDurden]

So here the first test binaries: HoverBoardGigaDevice/BinariesToTest/

Please check the new defines_2-4.h before flashing.

Here some ideas in yellow for better understanding of the step down regulator:

[Batman313v]

Gotcha 👍 I'll go chase more of those traces today and try hooking up a battery. The overlap at the bottom is because they put the traces on top of each other on opposite sides of the board, I'll redraw that later today so it makes more since

[cjoe-51]

Hi, I have hoverboard with exactly same PCB but another processor. There is MM32SPIN 05PF inside. Is this processor equivalent to GD32F130C8T6 or will the necessary firmware be different?
Feel free to delete my message if it does not fit here.
On the other hand let me know if I shell post picture of the board (which seems to be totally same as that one above).

[I-hate-2FA]

you should look in mm32 repo

[RoboDurden]

As your board will be 2.4.5 , yes please start a new issue and post photos from the front side with cables bent outside so as much as possible is visible of the Mainboard.

You can install the pinFinder firmware of AiLife to verify the pins and then switch to his sinusoidal firmware.
Or go with the pin definitions of 2.1.5 and modify MM32 EFeru FOC port Trontin has published recently...
It looks like your board has dual opamp Chip for two phase currents, which are needed for FOC.