search

RoboDurden / Hoverboard-Firmware-Hack-Gen2.x

with different defines_2-x.h for different board layouts :-) Compiles with Keil version 6
GNU General Public License v3.0
75 stars 25 forks source link

Unable to control board using TestSpeed program (question) #9

Open Derkades opened 1 year ago

Derkades commented 1 year ago

Hi, first of all thanks for providing precompiled binaries, I can stop spending my time trying to get it to work with PlatformIO!

I have flashed hoverboard 2.0 slave.bin to the slave board. When I flash hoverboard 2.0 master test.bin to the master board, the wheels spin like they should! But when I flash the normal master firmware hoverboard 2.0 master.bin, I can't get the wheels to spin.

I have flashed your TestSpeed Arduino program to an ESP32-S2.

It receives the data from the hoverboard just fine: image (I have added SendSpeed and SendSteer to confirm the values of iSpeed and iSteer were as expected)

Is this perhaps a known pitfall, or do you have any tips to resolve this issue? Thank you

pacraf commented 9 months ago

RoboDurden, loaded your binaries ready to flash 

hoverboard 2.0 single UartBus id0.bin
hoverboard 2.0 single UartBus id1.bin

lolin with example /TestSpeed/TestSpeed.ino

and first observation is that it works. congratulations to you... observation: If boards are configured as above, you have to switch them on separately. there is also need to switch them off separately. some questions... of course..

you prepared also binaries called:

hoverboard 2.0 master UartBus id0.bin
hoverboard 2.0 master UartBus id1.bin

in this example /TestSpeed/TestSpeed.ino

define REMOTE_UARTBUS uncommented

and you communicate only with master, and steering is recalculated inside master and slave is driven accordingly master calculations.... so this is normal master slave? or what is the difference I do not see? (except protocol, so more than one master-slave can be on one bus, right?)

RoboDurden commented 9 months ago

uartBus master is for four wheelers. One master front axis and one master back axis.

I can add a 16 bit register to the protocol to turn on off the 5 led as well as shutoff() the board.

pacraf commented 9 months ago

4 wheelers!!! whoa that is great idea... I think will buy another hooverb. hope it will be 2.0... regarding powering it off via uartbus - it would be good to have this feature I think, but from the other side anyway to power it up you have to use button, so anyway it has to be there... but maybe more for emergency software control, powering down via software would be good feature. will test it of course if you add it.

pacraf commented 9 months ago

today I located locally bargain offer and have another board. 4 wheelers master slave approach ... but nothing can go easy, and it is single board version (with separate sensors boards). processor GD32F103 RC?6 there is no chance to have anything compatible with uartbus idea for this "pre 2.x" system, right? better sell (or wait until mosfet/motors will be needed) it and look for another?

image image

RoboDurden commented 9 months ago

Sorry, I have some other things to do.. The EFeru FOC for this gen1 board is better than the Gen2.x

pacraf commented 9 months ago

Yes, I understand. Will look for another one.

RoboDurden commented 9 months ago

Already one hoverboard is overkill for a lawn mower. Position control will be more complex with four motors.

Better build two lawn mowers to make the world a better place.

RoboDurden commented 9 months ago

Okay i now have a running 2.2 master/slave setup. And i can confirm the choppy behavior on Uart but not UartBus is fine. Do not yet know why.

I have added a wState to the protocol to turn onOff the leds and ShutOff. Still need to update the master/slave communication to forward the wStateSlave..

For now i will not support UartBus with master/slave. Instead i uploaded UartBus single id0,1,2,3

RoboDurden commented 9 months ago

Did some master-slave code cleanup. Now the choppy behavior seems to be gone and master-slave running as smoothly as uartBus. Have uploaded new binaries. Would be nice if you can confirm the non-choppy master-slave.

I guess i will embark on my next journey with my little solar camper tomorrow, and will leave all my hoverboard test setups behind. So no more hardware testing for me the next 1-2 months.

pacraf commented 9 months ago

Wish you great camping time. reagrding firmware - I think something went wrong during loading, because my slave board is not responding. the outcome is that it is "powering up" (you can hear noise), but "cannot connect to target" by st link (stflash as well). and when you powerdown master , this slave board stays on (noises can be heard). You had something like this? processor dead? I checked programmer, and it works normally with master board...

pacraf commented 9 months ago

things like battery disconnect do not change situation.

RoboDurden commented 9 months ago

try the auto-flash.bat and multiple power on/off

pacraf commented 9 months ago

tried , slave not resurected. it worked for master (just checked if it works at all, and auto-flash.bat did the job during first powerup) is there anything to try- or replacement of GDxxx ? strange is that it is keeping power-up state. If I properly understand co mpletely dead beard would not keep itself powered up, right?

RoboDurden commented 9 months ago

Find and test the 5v an 3.3v regulators . Or check the 3.3V pin on the flash header.

I do not remember if the 2.0 slave board has the 14V dcdc regulator an onoff header on board.

Try to power it as a single.

Then there is still the nrst pin. See readme..

Good night and good luck.

RoboDurden commented 9 months ago

Sorry i had the wrong tx pin in the TestSpeed.ino in the last update: HoverSetupEsp32(oSerialHover,19200,39,35); // baud, rx, tx - when testing my 2.0 test setup this morning the motor did not spin because it did not receive the tx data :-(

pacraf commented 9 months ago

boards are back alive with NRST method. thanks for tip... just loaded precompiled bin files

hoverboard 2.0 master Uart.bin
hoverboard 2.0 slave.bin

and TestSpeed.ino

and result is that if only master is connected with lolin, then it works, but if master and slave is connected (slave to master) , then it works, but I am not able to poweroff them (by button) . They stuck in some state between (I am also not able to power back - until battery disconnect) I am not sure, but seems that slave is going down, and this state somehow prevents also coming back. unfinished power down. look on short movie https://youtu.be/eTUP6ScQJd4 this is hard to explain...

RoboDurden commented 9 months ago

Maybe my new wState that now gets forwarded to the slave board interferes with the old way of power off .

Will make a stop at my train station for about a week tomorrow. Could maybe build another hardware test setup.

Why don't you install Keil and learn programming?

pacraf commented 9 months ago

today I will try uartbus version with implemented wState. Regarding your question about programming - this is too complicated for me. I barely pogram arduino with simple topics... Keil is installed btw, and i can compile. But with your provided binaries to flash - all what is needed is ready to take... Also online compiler is great tool.

btw two other hooverboards should arrive soon... will see what's inside.

pacraf commented 9 months ago

I am not able to load anything to boards. both of them are not responding to st-flash, also with NRST connected. For a few uploads NRST helped, but now, seems that chip flash memory is failing?

sometimes like below: but 99 percent not responding at all. I tried to power board only with 3.3V (thinking that power supply may be failing) but no connection is there anything left other than exchange GD32f130C6T6 ? 

> C:\stlink\bin>st-flash --reset write hoverboard.bin 0x8000000
> st-flash 1.7.0
> 2023-10-27T17:56:23 INFO common.c: F1xx Medium-density: 20 KiB SRAM, 32 KiB flash in at least 1 KiB pages.
> file hoverboard.bin md5 checksum: 78fc13f7c1e91616f9c34d44c484b22f, stlink checksum: 0x002172f1
> 2023-10-27T17:56:23 INFO common.c: Attempting to write 22112 (0x5660) bytes to stm32 address: 134217728 (0x8000000)
> 2023-10-27T17:56:24 WARN common.c: Failed to unlock flash!
> 2023-10-27T17:56:24 INFO common.c: Flash page at addr: 0x08000000 erased
> 2023-10-27T17:56:24 INFO common.c: Flash page at addr: 0x08000400 erased
> 2023-10-27T17:56:24 INFO common.c: Flash page at addr: 0x08000800 erased
> 2023-10-27T17:56:24 WARN common.c: Failed to unlock flash!
> 2023-10-27T17:56:24 INFO common.c: Flash page at addr: 0x08000c00 erased
> 2023-10-27T17:56:24 WARN common.c: Failed to unlock flash!
> 2023-10-27T17:56:24 INFO common.c: Flash page at addr: 0x08001000 erased
> 2023-10-27T17:56:24 INFO common.c: Flash page at addr: 0x08001400 erased
> 2023-10-27T17:56:24 INFO common.c: Flash page at addr: 0x08001800 erased
> 2023-10-27T17:56:24 WARN common.c: Failed to unlock flash!
> 2023-10-27T17:56:24 INFO common.c: Flash page at addr: 0x08001c00 erased
> 2023-10-27T17:56:24 INFO common.c: Flash page at addr: 0x08002000 erased
> 2023-10-27T17:56:24 WARN common.c: Failed to unlock flash!
> 2023-10-27T17:56:24 INFO common.c: Flash page at addr: 0x08002400 erased
> 2023-10-27T17:56:24 WARN common.c: Failed to unlock flash!
> 2023-10-27T17:56:24 INFO common.c: Flash page at addr: 0x08002800 erased
> 2023-10-27T17:56:24 WARN common.c: Failed to unlock flash!
> 2023-10-27T17:56:24 INFO common.c: Flash page at addr: 0x08002c00 erased
> 2023-10-27T17:56:24 INFO common.c: Flash page at addr: 0x08003000 erased
> 2023-10-27T17:56:24 INFO common.c: Flash page at addr: 0x08003400 erased
> 2023-10-27T17:56:24 INFO common.c: Flash page at addr: 0x08003800 erased
> 2023-10-27T17:56:24 INFO common.c: Flash page at addr: 0x08003c00 erased
> 2023-10-27T17:56:24 INFO common.c: Flash page at addr: 0x08004000 erased
> 2023-10-27T17:56:24 INFO common.c: Flash page at addr: 0x08004400 erased
> 2023-10-27T17:56:24 INFO common.c: Flash page at addr: 0x08004800 erased
> 2023-10-27T17:56:25 INFO common.c: Flash page at addr: 0x08004c00 erased
> 2023-10-27T17:56:25 INFO common.c: Flash page at addr: 0x08005000 erased
> 2023-10-27T17:56:25 INFO common.c: Flash page at addr: 0x08005400 erased
> 2023-10-27T17:56:25 INFO common.c: Finished erasing 22 pages of 1024 (0x400) bytes
> 2023-10-27T17:56:25 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL
> 2023-10-27T17:56:25 INFO flash_loader.c: Successfully loaded flash loader in sram
> 2023-10-27T17:56:25 INFO flash_loader.c: Clear DFSR
> 2023-10-27T17:56:25 INFO flash_loader.c: Clear CFSR
> 2023-10-27T17:56:25 INFO flash_loader.c: Clear HFSR
> 2023-10-27T17:56:25 INFO common.c: Go to Thumb mode
> 2023-10-27T17:56:25 ERROR flash_loader.c: Flash loader run error
> 2023-10-27T17:56:25 WARN flash_loader.c: Loader state: R2 0x0 R15 0x0
> 2023-10-27T17:56:25 WARN flash_loader.c: MCU state: DHCSR 0x0 DFSR 0x0 CFSR 0x0 HFSR 0x0
> 2023-10-27T17:56:25 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1
> stlink_fwrite_flash() == -1
RoboDurden commented 9 months ago

reboot Windows.

pacraf commented 9 months ago

Today I closed workshop doors, to avoid going mad. Tommorow will try again. But rebooting was done during today trying. I checked voltages and 5 and 3.3 are ok, but maybe this buck converter makes problem? Rather not I suppose. Anyway, when I just supply 3.3 to board at output pin of 3.3 regulator, I should be able to program uC ? Correct? I tried doing this but it is not responding as well… Maybe tomorrow will take another laptop.

RoboDurden commented 9 months ago

i once also had these multiple errors and after reboot they were gone. It may be risky to power the MCU not from the battery but the st-link dongle 3.3V.. Try all three flash methods:

1: auto-flash = st-flash.exe

  1. Keil F7 + F8
  2. St-Link-Utility (4. STM32 Cube Programmer.)

It is unlikely that you killed both boards at the same time..

pacraf commented 9 months ago

you were right. reboot was not enoug but generally the way. it was indeed unlikly to kill both the same time. regarding powering - I meant not from dongle, but from stable external powersupply. it worked (altough it was not neccesary,finally reinstall of tool helped). btw I have another board, and it is 2.10! I see that it is not finished due to lack of responses from someone. I hope I can help with all missing details, and I hope you will try to run/compile it for this board... kindly asking... I will write it proper thread.

RoboDurden commented 9 months ago

Yes, post in the propper 2.10 thread, then maybe the first user will come back to join you. He already traced the mosfet and hall pins, so you should be able to get the motors spinnings. The rest led, onOff, Hold, voltage and current can be done by try and error. But you will need to compile and flash with Keil F7 + F8 and always chaning some pins in the defines_2-10.h

Derkades commented 4 months ago

I have tried it again today with the latest example code and latest pre-compiled binaries and with some adjustments it works! SEND_MILLIS had to be set to 5 instead of 100 or serial data wouldn't be sent frequently enough and the motors didn't spin. It sends 9 bytes of data, so if my calculations are right with 19200 baud (2.4kb/s) it can theoretically send data every 3ms

RoboDurden commented 4 months ago

There is a 500 milliseconds timeout in

https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x-GD32/blob/0cfd2716866bae62987bb81a4427e7b3fb6dde70/HoverBoardGigaDevice/Src/remoteUart.c#L74

So at least one Transmission from esp32 has to come through every half a second.

I can not explain why you need to send every 5 milli seconds.

Derkades commented 4 months ago

Perhaps communication is very unreliable and >90% of messages are not arriving

AILIFE4798 commented 4 months ago

If you are using hardware serial it's not going to be that bad

AILIFE4798 commented 4 months ago

And it's easy it only reply when it received a message just check how many message is received by esp you know how much is received by hoverboard

RoboDurden commented 4 months ago

No, this only applies to RemoteUartBus, RemoteUart answers every 100 ms (I think) even if it doesn't receive anything from esp32.

Derkades commented 4 months ago

I was using softwareserial on an esp8266, I will use its second hardware serial instead

AILIFE4798 commented 4 months ago

The second hardware serial only have tx and no rx

RoboDurden commented 4 months ago

You can use Serial1 to write and Serial to read. We mostly only use Serial to log data anyway. But you might need to turn off hoverboard when flashing esp8226. Or use uartBus . And set same baud rate for all Serial and hoverboard. 115200 is fine for hardware serial.

Would be a good topic for the wiki @Derkades

AILIFE4798 commented 4 months ago

gpio13,15 is also connected to serial0 so you can still flash the esp

AILIFE4798 commented 4 months ago

theres not a whole lot of gpio on esp8266 better get a esp32 for the same price

Derkades commented 4 months ago

I agree the ESP32 is much better, but I am trying to use up my old collection of ESP8266 boards for projects where I don't need much :)

I should have time this evening to try with hardware serial to the hoverboard, and software serial for debug output. I will use the standard baud rate of 19200 as I am not able to compile this hoverboard firmware myself.

AILIFE4798 commented 4 months ago

if you use my firmware you can change baud without recompile

Freshwater123 commented 3 months ago

Hey @pacraf did you get the mower to work? Also lookin to build one