EFeru / hoverboard-firmware-hack-FOC

With Field Oriented Control (FOC)
GNU General Public License v3.0
1.17k stars 967 forks source link

More communication tutorials for various hoverboard mainboard types #432

Open HTraff opened 1 year ago

HTraff commented 1 year ago

Variant

None

Control type

None

Control mode

None

What can we do to make the firmware better?

Hi

I have bought 5 used hoverboards all in working condition over the past 6 months. I have been struggling to communicate with the mainboards for a good 3 months. (also factor in learning curve for someone not familiar with this previously)

I got an ST-Link v2 as described in various youtube tutorials, and even got another one when I couldnt get it to communicate to the motherboards. Suspected it might be broken. (have checked pinouts vs labeling as some has reported non-coherent for these cheap st2 clones)

However, last week I got another hoverboard which mainboard I could communicate with as according to the youtube tutorials with 0 issues. I could connect, unlock and flash and now the new firmware seem to work after autocalibration. That said I currently have 3 hoverboards of the older type of which one MB is flashed. (a green MB similar to the github pictures) My other two V1 MBs are blue but no luck with those so far.

I haven't tried flashing the newer version boards yet. Have two hoverboards with that layout currently.

I have tried alot to find information to solve the problems, and I found one interesting topic here: https://github.com/EFeru/hoverboard-firmware-hack-FOC/issues/169 However I can't get it to work, so might not apply for my blue boards.

I have seen posts about GND and SWDIO switching places in some sideboards, and I have tried that also for my mainboards just in case.

Is it a reasonable idea to form some sort of directory with different MB types and attach knowledge on how to solve the communication/flashing hurdle? I suspect there is alot of knowledge on this from individuals that have tried flashing different types of MBs.

Thank you for reading!

Describe suggestions or alternatives you have considered

It's an addition to the overall github topic as described in the previous field.

Candas1 commented 1 year ago

Have you checked this already ?

HTraff commented 1 year ago

I did see it during my trial and error and learning process. There is emphasis on things to check when the connection is established, but herein lies my problems. I can't connect to a majority of my MBs. It might be something obvious but since I have one MB that works exactly as according to the tutorials I suspect differences. I will connection test with the multimeter between the pinouts of the chip to the programming interface. I am very confident in my soldering skills and quality check so that is not the problem.

I suspect there is something more to this than just connecting according to the tutorials. I have only been using stm32cube programmer and the st-link utility tools in windows environment, could that be a disadvantage and reason for connection problems compared to linux prompt?

Candas1 commented 1 year ago

I am using windows as well and never faced an issue. Are you holding the button while unlocking or flashing ? Or have you connected the 3.3v ?

HTraff commented 1 year ago

I did check connection between the header pin interface for my different v1 boards. Turns out the SWCLK according to the documentation in this topic has no direct connection to any of the chip's legs. For the board I did flash there is a connection to one leg. Both the identical boards I can not connect to measure the same. I wonder why this is... The hoverboard program had to go into the chip in the past, and I guess that was done before mounting it. I am not familiar with these manufacturing processes. Maybe the programming pinout internal tracing is faulty.

HTraff commented 1 year ago

Also noticed that the chip that works is named STM32F103, and the ones that wont play yet are GD32F103. If that is any clue. I see that the pinouts look similar when googling.

Candas1 commented 1 year ago

That shouldn't be a problem, it's supported. It would be a problem only if it's a AT32 chip. What error are you getting ? Are you sure the board was functionning ?

HTraff commented 1 year ago

I now manually put a connector to the corresponding pin of the chip that matched the connection on the working MB. ANd voila, I could connect to the board. Unfortunately I destroyed one of the boards when experimenting but one of the two is now programmed. My conclusion is that there is no connection between the header/programming interface and the chip for one of the pins (The SWCLK next to the 3.3v pin). Strange.

Candas1 commented 1 year ago

Oh weird, but this must be very rare. It unlikely it happened on several of your boards.

HTraff commented 1 year ago

I did find out that I hadn't destroyed one of the boards. It was merely metal rests bridging between the very thin legs of the chip from me dragging a multimeter probe across to search for connections. After mechanically clearing the gaps with a thin blade I was able to also program the third v1 board I have. Exactly the same procedure as the other one with a missing connection for the SWCLK. Both of the below boards are now flashed.

HTraff commented 1 year ago

20230901_120956_resized

dexterkorgpa1x commented 1 year ago

Hello! i make this project of hoverboard and controlled at pwm and she is work better and now i want to moddiffy the startup/power off buzzers sound and not found in the code of parrametter to edit. You have any ideea to help me? thank you in advance! image

Th3KillinJok3 commented 2 months ago

@HTraff do you still happen to have the Pinout for this board please?