Hoverboard-Firmware-Hack-Gen2.x
Hoverboard-Firmware-Hack-Gen2.x copied to clipboard
Gen2.1.18 (ex2.20)
MCU:GD32F130CCCC8T6(128K) Gate driver: fortior FD6287T Voltage:3.3V
serial0 pin is none standard
This is the 1 USD slave board I guess. Maybe It will also run with 5V on master slave.
yes it is $1 board i will trace it later i imagine it be much easier then the 2.8.1 which use all 0402 tiny resistor it took quite a while
Why not autodetect ??
no motor on hand
https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x-GD32/pull/1
on this layout master and slave share the same pcb but because im going to use gen1 this board is useless to me now if anyone want to buy this $1 board them self and modify to master you can install the missing components your self if you needed guide on how to do it you can ask me
Maybe It will also run with 5V on master slave. The 15V might only be needed for the Led modules when the gate driver chip generates it's own gate voltages ...
gate driver is using 15v and the vbat sensing only have 1 resistor in the voltage divider it also will not work
despite there is a coil on the pcb this board is designed for linear 15v regulator it would not be hard to install
@AILIFE4798 , i have added the 2.20 to repo and added a test binary.
Why do you think this board has 128 kB ? I only see the standard C8 mcu
And did you test the uart0 with PA11 and PA12 ??? According to the datasheet, no hardware serial possible on these pins:
So i doubt that people will succeed with attaching an ESP32 to that empty header.
There is no alternateFunction AF that i could assign to these pins in target.h :
#define AF_USART0_TX(pin) (pin==PB6 ? GPIO_AF_0 : GPIO_AF_1) // GD32F130: AF0 = PB6 , AF1 = PA2 or PA9 or PA14
#define AF_USART0_RX(pin) (pin==PB7 ? GPIO_AF_0 : GPIO_AF_1) // GD32F130: AF0 = PB7 , AF1 = PA3 or PA15
#define AF_USART1_TX(pin) (pin==PA8 ? GPIO_AF_4 : GPIO_AF_1) // GD32F130: AF4 = PA8 , AF1 = PA2 or PA14
#define AF_USART1_RX(pin) (pin==PB0 ? GPIO_AF_4 : GPIO_AF_1) // GD32F130: AF4 = PB0 , AF1 = PA3 or PA15
mcu labeled as 64k always have 128k you can use just not tested
i have confirmed the pin i trace is correct but im ot sure if itll work ive not even flashed a firmware on layout2.20 yet
either implement softwareserial or use the i2c pin because these layout2.x imu is always not useable anyways
101 resistor to bottom right is connected to i2c/hardware serial
okay then i set uart0 back to pb6 and pb6 in your defines2-20 and update the test binary:
for some reason this board must be flashed with serial(core reset fail) using swd in bootloader also does not work luckily it is very easy to flash with serial on this board no soldering to mcu pin required
using master dummy hall2led works all voltage regulator heat up allot and motor does not spin
How do you power this slave board ?
Now with motor you could try my autodetect?
Still high power consumption with no motor attached ? Check the six mosfet pins to be the standard ones. Maybe hi or low side needs to be negated.
the board is drawing 100ma in idle at 3.3v and 150ma at 24v i think it is faulty i have acidently connect 5v to the mcu before but it seems to survived i think sth else on the board is burned i installed the missing 7815 regulator to turn it into master but i have bypassed the p channel mosfet for power switch for now the motor pin is standard one
turns out the gyroscope/imu is shorted after removing it(which is def easier said then done without a hot air gun) it draw 30ma and the stlink does not want to coroprate with st link utilities so i have to use pyocd auto detect seems to work but i forgot how to use it by now ive used the mm32 one too much i lost the ability to use this over complicated one
ok kinda got it to the hall detect but motor just vibrate allot and cannot detect hall sensor
but i forgot how to use it by now ive used the mm32 one too much i lost the ability to use this over complicated one
I am still waiting for your YouTube tutorial.
The motor should not vibrate but spin. Not smoothly but happily rotating.
If autodetect only makes motor vibtate, then the six mosfet pins are not correct.
I am making changes too fast it's not worth my time making video now Or I should say not worth my time making a high quality video now Foc support is so close I'm just a functional board away really coz the spin05 one is not foc capable and the spin06 is broken After that I'll have to make a new one You can only appreciate how good/ bad it is by trying your self! It may be only the one who designed it likes it
The motor does spin kinda but the vibration is way more then I remembered from the 2.6.1 board test I'll re trace the motor just in case
I already ran foc test open loop without current sensor and without hall sensor it worked so well at very low speed it is completely smooth it's very impressive
The motor wires is very easy to trace it is definitely the standard ones
it is technically possible to not use the standard pin for the lowside you can use normal io for that by only pwm one side but it will complicate the code so i do not think anyone will do it
32 pin package does not have all 6 standard pins. I also think that only on such boards will there be a problem for autodetect.
With your board I guess you need to check the output of the six mosfet with a dso.
32 pin one can use PA8,PA12,PA10(ch1,2,3) PA9,PA7,PA5(ch1n,2n,3n)
the gate driver i have is lowside inverted idk if your auto detect can support that i think it may be the problem mm32 autodetect can support both
I guess the invert has to be set here: https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x-GD32/blob/main/HoverBoardGigaDevice/Src/setup.c#L274
i think so, but it is set to OC_POLARITY_HIGH and OCN_POLARITY_LOW which is correct for hin normal and lin inverted
https://github.com/AILIFE4798/Hoverboard-Firmware-Hack-Gen2.x-MM32/blob/6e1bc5a735994ebd8eac7504538dc7eaebbd0037/HoverBoardMindMotion/Src/initialize.c#L151