Gen2.1.8 (ex2.10) (I seem to have found a new board)

[Tommyboi2001]

[Tommyboi2001]

first is slave second is master

[RoboDurden]

Added it to this repo. If you plan to use your board, please provide a high-resolution photo of front and back where we can trace some led pins and maybe mosfet and hall pins just by looking on the photo.

Like https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/blob/main/Schematics_2.3/front-back.jpg

[Tommyboi2001]

[RoboDurden]

Great! I can not read the complete mcu type. Is it a GD32F130 C6 or C8 ? C6 does only have 32 kB flash which might very well not be enough for my coming SimpleFOC firmware. For this Gen2.x firmware it does not make any difference between a 32 kB and a 64kb MCU.

[Tommyboi2001]

I'm pretty sure its c8, but I will confirm when I get home.

[Tommyboi2001]

It is GD32F130 c8

[Tommyboi2001]

Did Some pin tracing

[RoboDurden]

Your CLK pin is wrong:

Try to trace some led pins - good for debugging like config.h:

#define TEST_HALL2LED // led the 3-led panel blink according to the hall sensors

Cheap CC dcdc converters for a 10s liion battery : "LM2596 60V"

https://www.aliexpress.com/item/1005004225291490.html

Or a 12 or 24V battery or some notebook power supply that outputs somewhere from 14V to 21V. Then buy https://www.aliexpress.com/item/1005006015237499.html or https://www.aliexpress.com/item/1005006000681109.html

Unfortunately i do not find 12 day shipping offers for these items on Aliexpress.

Or you watch my latest youtube videos and buy https://www.aliexpress.com/item/1005004966830126.html

https://youtu.be/KYcyNHunJU8

bye.

[Tommyboi2001]

Sorry for the confusing labels, I did know that that was the clock pin. The green yellow and blue traces are the mosfet control

[RoboDurden]

have modfied your pin tracins and added it to the Schematics_2.10 folder. Your 6 mosfet pins seem to be compatible. So if you had a 2A CC power supply, you could already test the motor. I do not see little smd transistors for the led pins! Are they on the led panles ? Adding some led output will make it easier and more safe to test the firmware !!

[pacraf]

So by chance I landed with this layout too. missing info in screen below

[RoboDurden]

Great. B6 and B7 will be USART0 and can be used for remote uarst control. But where is the usual Master-Slave connector on this layout ?

And mostly, you have a led module with 2 led like the one you traced, and a module with 3 led. So i guess that PA12 would control the orange led on that other led-module.

I will make a defines-2_10.h ready for you tomorrow. Here in germany it now is 21:04 and i will go to bed soon. You should please install Keil and F7+F8 yourself. It will need many compilations until all pins work properly. I can not do this for you all the time.

[RoboDurden]

@Tommyboi2001 , what happened to you ??

[RoboDurden]

I see that the little led transistors are on the led module, not the mainboard. Then these pins could probably also be used for serial communication..

[pacraf]

I will reverse it all soon. slave board too, comnnection, too. If you could please make as good as you think it should work, then I will try also Keil. I hate Keil. It was long time ago when I had to write for '51 in Keil at school. It was not my story definetely. Maybe it is time to say hello again... anyway, I am not good at programming. rather copy from internet some good, well described stuff and slighly modify by myself... that's me...

[pacraf]

And some slave details

[pacraf]

Tommorow or next day I will prepare safe power supply and install keil. Anyway it would be great if you could preapre file as far as you can, to limit mistakes area... is there anything I can add to board information?

[RoboDurden]

Onoff button and hold pin will be important. But they are tricky to trace.

So try and error might be faster..

[pacraf]

I think it is like below pic. Is it sharing same layout like any 2.x? or it's different completely? I mean if there would be 90%the same, then I would check again these 10% different, to be sure they are not mixed up, but really different...

[RoboDurden]

Okay i have added the config_2-10.h and also compiled some test binaries: https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/tree/main/HoverBoardGigaDevice/BinariesToTest

The config.h is still set to the 2.10 layout.

As the colors of the hall cable are all balck, the ordering could be reverse :-/ So only test with a 2A cc power supply / step down regulator !! I have set the number battery cells to 6 so the software will not shutoff when the boards are run at 26 Volt. If you go below 26V, the onoff button might no longer work.

Still missing is the buzzer pin. I guess it is the little transistor right to it:

I have defined the led colors according to the slave led module with its 3 leds. Looks like the 2 color led panel of the master has different pins for red and green. I guess you can plugin the 3 led panel into the master as well.

All test binaries are compiled with the TEST_HALL2LED define so the three led should rotate when the motor spins with always two led overlapping.

There are 5 mcu pins that are still free and can do analog input:

// 2.10 available for analog input: A4 A6 A7 B0 B1

So i have kept the 2.0 defines:

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

Check the log data when you run a uart binary. the battery voltage should vary when you increase/decrease the cc power supply. Current should increase when you put a hand on the motor.

There are two dual opamp chips on board:

The left one probably is for two lowside gate currents of the two left phases. They will be important for the SimpleFOC firmware. The other (right) dual opamp should contain the currentDC and maybe the third phase lowside current.

Have fun.

[pacraf]

Great! regarding buzzer, is it possible that base of this transistor of buzzer is pinned to pin 5 uC ? it is called PF0_OSC_IN

[RoboDurden]

PF0 could be the buzzer. have updated and uploaded hoverboard 2.10 master Uart.bin

P.S as i have said, i do not really like to compile binaries when you do not test them yet anyway.

[pacraf]

So the current status is that: -master board is unlocked, loaded with precompiled bin file. -powered securely with cc limit

• after loading board makes start sound.
• led panel reflects rotation (by hand) of motor with overlaping leds.
• board not holding power. have to lock it with shortcable.
• no communication to lolin (loaded TestSpeed.ino as it is , except:

  #define _DEBUG      // debug output to first hardware serial port
  #define DEBUG_RX    // additional hoverboard-rx debug output
  //#define REMOTE_UARTBUS

  I can not see any communication, so I suppose uC will not rorate motor until receives frame witg requested speed etc..

Any suggestion (chaged rx with tx done... )?

I will look if I did not any mistake (again)

[RoboDurden]

first try the master_dummy to verify that the 6 bldc mosfet outputs and the 3 three hall inputs are correct. I assume you directly flashed hoverboard 2.10 master Uart.bin. Then without communication, motors will not spin and you can test the hall sensors via manually spinning the motor. But the ordering might still be wrong. So the dummy should be tested first.

remote serial should be connected to

    #define USART0_TX_PIN   GPIO_PIN_6  // thanks to pacraf
    #define USART0_TX_PORT  GPIOB
    #define USART0_RX_PIN   GPIO_PIN_7
    #define USART0_RX_PORT  GPIOB

    //#define USART0_MASTERSLAVE        // uncomment if this usart is used for master-slave communication
    #define USART0_REMOTE                       // uncomment if this usart is used for optional remote control

If you have a pocket DSO, you can look if PB6 is sending some data. (And if ESP32 pin 37 is sending data.)

If board is not holding power then your pin tracing is wrong:

// Self hold defines
#define SELF_HOLD_PIN GPIO_PIN_12       // thanks to pacraf
#define SELF_HOLD_PORT GPIOB

[pacraf]

for the time being loaded hoverboard 2.10 master Dummy.bin and basically the same status. (except no sound, but you added buzzer to UART file, so it is ok) hand rotated wheel = led rotation motor no sign of life (no noise, no vibration, no significant current draw (60mA) ) for today I have to finish. tomorrow after work will investigate it further. I assume that even if there would be mixed hall signals, there would be some vibration, chopping movement, whatever. there must be more wrong, right? I will also make more reverse on button area, but I am pretty sure I located as on pictures... anyway mistakes happen... Also will check output with not DSO (don't have, but somewhere I have logic analyzer, have to find it)

[RoboDurden]

Yes, with only wrong hall pins or hall order, the motor would stutter or be stuck after a little jump and some current being drawn.

If you had Keil installed, you could compile a 2.0_master_dummy, verify it to work and than only change #define LAYOUT 0 to #define LAYOUT 10

I habe uploaded a hoverboard 2.10 single Dummy.bin now, the buzzer should also work for SINGLE binaries. Maybe the master_dummy combination does not work. Remember that currently i do not have a test setup here in my train staition. I could built another 2.0 but have more urgent things on my todo list.

[pacraf]

I had some time and looked on some details, and in fact there are small test points called like on picture below, so it has to be accurate. (current measure pins as well are marked on board) . there is also BRK signal,whatever it can be (breaking?). Need to look on that more in details too?

later will look on "power on" circuitry. why it do not want to hold power.

[pacraf]

Additionally there is no "switch on" circuitry on slave. Seems that it receives +12V via this quite fat "master slave 3 pin cable" and this is how slave logic is powered. but will look on this too after we sort out master...

[RoboDurden]

yes it is quite common that the slave board does not have a dcdc step down unit but gets the 12V via the mastersalve cable. and thanks for the i_u, i_v, i_w pins. All of them are available adc pins, so this is the low-side phase current - not neccessary for this old 2.x firmware but needed for the coming SimpleFOC firmware.

the 6 mosfet pins are very restricted by hardware. That is why most layouts have this

#define TIMER_BLDC_CHANNEL_G TIMER_CH_2
#define TIMER_BLDC_GH_PIN GPIO_PIN_10       // all bldc pins same as 2.0, thanks to Tommyboi2001
#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

Try to get the uart working to get some serial log output.

I have uploaded a hoverboard 2.10 single UartBus id0 uart1.bin which should use the 3pin master-slave header for remote control. Maybe you get log output from that tx pin. (and can control via the esp32 tx -> hover.rx)

[Tommyboi2001]

@Tommyboi2001 , what happened to you ??

Sorry, I have been busy, looks like you guys are making some progress though

[RoboDurden]

I don't have a 2.10 setup, so it would be great if you could confirm the progress that pacraf is making. It is strange that his motors do not spin even so the hall sensors input seem to be right. With his nice pin tracings, the serial communication should also be no problem. So it might be good to have a second fellow trying the same things.

[Tommyboi2001]

I can't seem to write the file to the board, i can connect and erase but every time i try to flash i get this error: 10:20:35 : Unexpected error 10:20:35 : Error occured during program operation! 10:20:35 : Programming error @: 0x08000000

[Tommyboi2001]

Maybe my st link is malfunctioning? or is there something i am missing?

[RoboDurden]

which binary ? which flash method ? rename the choosen bin file to hoverboard.bin and use auto-flash.bat - if you have windows

[Tommyboi2001]

Im using the st link utility, with the 2.10 master dummy

[RoboDurden]

So i assume that you have disabled the read protection with strg+B. Try auto-flash.bat: https://pionierland.de/hoverhack/gen2/ReadyToFlash/

[Tommyboi2001]

The auto flash worked perfectly, when i get home i will attempt to connect hardware and power with a current limited power supply

[RoboDurden]

Good news :-)

[RoboDurden]

@pacraf , the little transistor you traced could be an overcurrent-trigger:

// Timer BLDC short circuit emergency shutoff define
#define TIMER_BLDC_EMERGENCY_SHUTDOWN_PIN TODO_PIN
#define TIMER_BLDC_EMERGENCY_SHUTDOWN_PORT TODO_PORT

If it is a npn transistor, then E should go to GND and C to some io pin of the mcu (maybe with a little resistor in between) = pulling the io pin to low when overcurrent tiggers the transistor. If it is a pnp transistor, then C should connect to 3.3V and E (via some resistor) to an io pin = pulling the io pin to high on overcurrent.

Pin 7 of the nearby dual-opAmp probably is the output for the currentDC adc input pin:

#define CURRENT_DC_PIN  GPIO_PIN_6  // robo just guessing
#define CURRENT_DC_PORT GPIOA

[pacraf]

I had some time and looked on some details, and in fact there are small test points called like on picture below, so it has to be accurate. (current measure pins as well are marked on board) . there is also BRK signal,whatever it can be (breaking?). Need to look on that more in details too?

later will look on "power on" circuitry. why it do not want to hold power.

Robo - this transistor it connected to BRK = PB12 it is NPN type.

[RoboDurden]

Okay, then PB12 is not HOLD. Could you please correct your previous tracing:

[pacraf]

So I am contradicting myself ;/ . when looking on pinout of these little transistors, it is clear that base of this small G1 is on PB2 so this will be power lock. PB12 is also here connected to this R005 measure resistor, and becasuse it is so small resistance I did not realised it initially. anyway - as below shall be ok to hold. next thing is to look for output on TX pins... will let you know.

[RoboDurden]

Okay have uploaded new binares. Now with PB2 as HOLD pin :-)

[Tommyboi2001]

with hoverboard single dummy 2.10 the power now works, and i am getting attempted motor movement in the form of vibrations

[Tommyboi2001]

switched the green and yellow phase wires and it is running perfectly

[pacraf]

HELL YEAH!!!

I confirm -> yellow switch with green and runs great! some readouts (with 31V power supply) loaded hoverboard single UartBus id0 uart0.bin

with TestSpeed sketch configured as:

#define ESP32
#define _DEBUG      // debug output to first hardware serial port
#define DEBUG_RX    // additional hoverboard-rx debug output
#define REMOTE_UARTBUS

CD AB -> iSlave: 0  iOdom: 248      iSpeed: -0.72       iAmp: 0.80      iVolt: 44.22
 :-))))))))))
iSpeed: -129    iSlave: 0   iOdom: 248      iSpeed: -0.72       iAmp: 0.80      iVolt: 44.22

 CD AB -> iSlave: 0 iOdom: 276      iSpeed: -0.71       iAmp: 3.82      iVolt: 44.25
 :-))))))))))
iSpeed: -111    iSlave: 0   iOdom: 276      iSpeed: -0.71       iAmp: 3.82      iVolt: 44.25

 CD AB -> iSlave: 0 iOdom: 290      iSpeed: -0.72       iAmp: 1.81      iVolt: 44.27
 :-))))))))))
iSpeed: -96 iSlave: 0   iOdom: 290      iSpeed: -0.72       iAmp: 1.81      iVolt: 44.27

 CD AB -> iSlave: 0 iOdom: 304      iSpeed: -0.71       iAmp: 1.41      iVolt: 44.28
 :-))))))))))
iSpeed: -81 iSlave: 0   iOdom: 304      iSpeed: -0.71       iAmp: 1.41      iVolt: 44.28

 CD AB -> iSlave: 0 iOdom: 318      iSpeed: -0.72       iAmp: 0.60      iVolt: 44.30
 :-))))))))))
iSpeed: -66 iSlave: 0   iOdom: 318      iSpeed: -0.72       iAmp: 0.60      iVolt: 44.30

 CD AB -> iSlave: 0 iOdom: 332      iSpeed: -0.71       iAmp: 0.60      iVolt: 44.31
 :-))))))))))
iSpeed: -51 iSlave: 0   iOdom: 332      iSpeed: -0.71       iAmp: 0.60      iVolt: 44.31

[pacraf]

So Robo-san, what next? (except switching phase Yellow with Green, and voltage factor change) ?

to be precise power supply difference is 31,5 vs 44,3 with current hard to say exactly, but I see that it draws max 0,2A when this TestSpeed.ino drives board...

[RoboDurden]

i swapped the yellow and green hall sensor to

// Hall sensor defines
#define HALL_A_PIN GPIO_PIN_10      // thanks to Tommyboi2001. robo: A and C might be reversed
#define HALL_A_PORT GPIOB
#define HALL_B_PIN GPIO_PIN_1
#define HALL_B_PORT GPIOA
#define HALL_C_PIN GPIO_PIN_0   // robo: A and C might be reversed, no colors on hall cables..
#define HALL_C_PORT GPIOA

That might have the same effect as swopping the yellow and green phase cables. The 6 phase mosfet pins should not be swapped as they are fixed in the mcu hardware for bldc control..

And i have added

#define ADC_BATTERY_VOLT 0.0171862875 // V_Batt to V_BattMeasure = factor 30: ( (ADC-Data/4095) *3,3V *30 ) to the defines_2-10.h that should apply * 31.5 / 44.3

But you should have increased and decreased the voltage of your power supply to make sure that the adc pin is the correct one.

Same goes for the currentDC adc pin, i simply guessed it ! Hold a hand on the motor and check that the current log data increases.

If you see :-)))))))))) in the log output, you do no longer need #define DEBUG_RX

Have uploaded new binaries.

[pacraf]

loaded config the same as above (uartbus id0)

• voltage works OK - checked for different voltage levels motor rotates - but something happened, it is not smoothly rotating, I don't know how to describe it. chopping, tendency to stuck on lower speed, and then draws current to limit 1A . need movie on that? before it was really good rolling, smoothly.

[pacraf]

just to be sure it's not anything "lolin related" - dummy firmware behaves the same.