Open HTraff opened 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?
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 ?
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.
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.
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 ?
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.
Oh weird, but this must be very rare. It unlikely it happened on several of your boards.
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.
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!
@HTraff do you still happen to have the Pinout for this board please?
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.