TLDR; Compiles but not executes and seems to brick ESC.
Solved : use gcc7 toolchain "gcc-arm-none-eabi-7-2018-q2-update", later versions generates issues
---
Hello,
I’m a software developer and I’m trying to setup my development environment for playing with the vesc.
I cloned and build (fedora, system arm-none-eabi toolchain) the bldc project, but not having an stlink available at the time, tried to flash the resulting .hex through vesc tool and bricked my esc.
Now I am unable to connect back to the board through usb, I have a solid blue led but nothing else. However, I can connect to the board through st-link and I can read the flash
My setup: lab bench psu, 12V, stlink v2, v4 maytech board
I am not an embedded software developper, so I may have easily made a mistake like not putting the good memory address when flashing (could not find info about it, so I left 0x080...0 everytime).
I already tried the following :
- make && make upload "bldc"
- make && make upload "bldc_firmware"
- upload bldc or bldc_firmware through stlink-gui
- upload from vesc_tool res directory
- When trying to flash a .hex through stlink-gui, I get a write error
The current status of my board :
st-info --probe
Found 1 stlink programmers
serial: 533f7006503f54542109053f
hla-serial: "\x53\x3f\x70\x06\x50\x3f\x54\x54\x21\x09\x05\x3f"
flash: 1048576 (pagesize: 16384)
sram: 196608
chipid: 0x0413
descr: F4xx
st-flash --reset write vesc_tool/res/bootloaders/40_o_47_o_48_o_410_o_411_o_412_o_DAS_RS.bin 0x08000000
st-flash 1.6.1
2020-08-21T16:22:03 INFO common.c: F4xx: 192 KiB SRAM, 1024 KiB flash in at least 16 KiB pages.
file vesc_tool/res/bootloaders/40_o_47_o_48_o_410_o_411_o_412_o_DAS_RS.bin md5 checksum: 88a07e93e464a7ca958de278ae12a3e, stlink checksum: 0x00054fa0
2020-08-21T16:22:03 INFO common.c: Attempting to write 4272 (0x10b0) bytes to stm32 address: 134217728 (0x8000000)
EraseFlash - Sector:0x0 Size:0x4000 2020-08-21T16:22:03 INFO common.c: Flash page at addr: 0x08000000 erased
2020-08-21T16:22:03 INFO common.c: Finished erasing 1 pages of 16384 (0x4000) bytes
2020-08-21T16:22:03 INFO common.c: Starting Flash write for F2/F4/L4
2020-08-21T16:22:03 INFO flash_loader.c: Successfully loaded flash loader in sram
enabling 32-bit flash writesç
size: 4272
2020-08-21T16:22:04 INFO common.c: Starting verification of write complete
2020-08-21T16:22:04 INFO common.c: Flash written and verified! jolly good!
The current content of my flash (stlink-gui, export memory) : https://drive.google.com/file/d/1Jk0OpTB88HLBtvzVJDA6iyZS-x5nkVF3/view?u...
It feel to me I have tried everything I can think of, and I think I have fried something with my bad first flash.
What can I do ? Any idea ? Can someone help me ?
On the side, I was unable to find documentation about the led, can you help me ?
Not sure if this will help, but might be worth a try. Its not related to your specific error, just what i would do reset an unknown fualty situation.
1)Use st-link utility to perform a full chip erase
2)In the bldc-bootloader project run "make upload"
3)In the bldc project run "make upload" (make sure you have the correct board selected in the hw_conf)
Hello,
I have been able to bring the esc back to life. I have dumped the flash from another working ESC and have wrote it back on the bricked one, so now I know the hardware is working.
However, when I try to upload a new software (as you said, bootloader make upload && bldc make upload), the esc seems to be unable to start, the only activity I can see is the green and red led seems to flicker for a few 100' ms every now and then, but no solid green nor connection possible through vesc tool.
I am on master, is this right or should I use another branch ?
I have set my conf_general.h HW_{SOURCE,HEADER} to "hw_410.{c,h}", is this the only thing to change to compile to this target ? (on vesc tool, this is the version shown)
Thank you.
I've encountered this behaviour with certain versions of the arm toolchain. Compiles successfully but vesc is an unresponsive brick with intermittent flashing. I use the 2018 q2 version for vesc firmware.
And yes that define in conf_general.h should be all you need.
hi,
indeed, this is the issue. I have found (thanks to gitlab issues 67, 131 and 84) that the toolchain could cause issues.
I have tried every toolchain until I was able to find one working, and with fedora it is "gcc-arm-none-eabi-7-2018-q2-update"
Thanks to both of you for your help !
facing same issue. Couple of weeks ago i tried to flash new, blank MCU and had constantly rebooting sequence. So far what I found by using GDB - is that MCU fails to verify firmware validity and reboots ... It is quite hard to me to debug multythread an rtos based firmware - little to no experience....
I'm using: arm-none-eabi-gcc (GNU Arm Embedded Toolchain 9-2020-q2-update) 9.3.1 20200408 (release) / debian
I had a feeling that there is something with compiler :)... Thanks !!!
Thank you. You saved my life. For the record I was using Ubuntu 20.04.1 LTS I tried 9-2020-q2 and 08-2019-q3 with no luck.