You are here

[Solved] Bricked VESC when trying to upload a firmware built from source

7 posts / 0 new
Last post
Last seen: 2 years 6 months ago
Joined: 2020-08-18 17:17
Posts: 3
[Solved] Bricked VESC when trying to upload a firmware built from source

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



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) :

    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 ?

    Last seen: 6 months 3 weeks ago
    Joined: 2018-09-05 09:53
    Posts: 17

    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)

    Last seen: 2 years 6 months ago
    Joined: 2020-08-18 17:17
    Posts: 3


    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.

    Last seen: 1 year 6 months ago
    Joined: 2018-04-26 12:18
    Posts: 123

    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.


    Last seen: 2 years 6 months ago
    Joined: 2020-08-18 17:17
    Posts: 3


    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 !

    Last seen: 1 year 8 months ago
    Joined: 2019-05-12 15:53
    Posts: 3

    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 !!!

    Bill Somerville
    Last seen: 6 months 3 weeks ago
    VESC Free
    Joined: 2019-05-09 21:50
    Posts: 3

    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.