You are here

Flashing custom code for 100/250 bricked the board

7 posts / 0 new
Last post
pe
Offline
Last seen: 2 years 3 months ago
Joined: 2021-10-22 13:03
Posts: 7
Flashing custom code for 100/250 bricked the board

Hi, I tried flashing the compiled github master version for 100/250 and ended up bricking the board. Could someone please point me out how to select the target board in the build environment? Thank you. 

My setup, Macbook M1 with gcc version gcc-arm-none-eabi-10.3-2021.10 compiler

The modifications that I have done in conf_general.h

FW_VERSION_MAJOR changed to 6

FW_VERSION_MINOR changed to 01

 

Then I commented out the line:

//define HW75_300_REV3

And uncommented

Define HW_SOURCE “hw_100_250.c”

Define HW_HEADER “hw_100_250.h"

Was that the right method to achieve that? When I flashed the .bin in the /build folder the VESC would not connect via USB any more to the VESC tool.

What did I do wrong? 

Thanks!

PS: I plan to read on ADC2 a three different voltage levels to switch between throttle maps. This is my motivation to write custom SW.

PS2: I got the board back alive with a STLinkV2

 

kubark42
Offline
Last seen: 9 months 3 weeks ago
Joined: 2020-07-17 18:46
Posts: 54

I tried flashing the compiled github master version

Currently, you should not use `master`, but instead the `dev_fw_5_03` branch. See https://github.com/vedderb/bldc/issues/362 for a description of the plan moving forward.

Was that the right method to achieve that

The command used to generate the official  binaries is at https://github.com/vedderb/bldc/blob/dev_fw_5_03/build_all/rebuild_all#L356

I also have a personal branch you could try which provides a variety of enhancements to the Makefile: https://github.com/kubark42/bldc/tree/unit_test. This is kept up-to-date with `dev_fw_5_03`, but you can also merge it in via git merge and it will work.

The relevant enhancement for targets is that we can type

make <target>

and it will build the target and place it in a `build/<target>` directory, appending the git hash to the *.bin name (and "dirty" as well if there are uncommitted changes). So in your case you would type

make 100_250

and look for it in `build/100_250`.

I have a 100/250 so can confirm it works for that one as well as the VESC6 Mk3 and VESC6 Mk5. Indeed, this pattern builds successfully for all standard targets (by using make all_fw), except for the 40 (which trips up on a bug at https://github.com/vedderb/bldc/blob/dev_fw_5_03/hwconf/hw.h#L452). When I get a chance and if there's interest, I'll expand it to work with the non-standard targets as well.

If you try it out, let me know. A couple of us have been using it on macOS and Windows, but it's always nice to hear about more test coverage, esp. for Linux.

P.S. You can access the Makefile's help by simply typing make without any arguments.

pe
Offline
Last seen: 2 years 3 months ago
Joined: 2021-10-22 13:03
Posts: 7

Thanks, will try tomorrow!

pe
Offline
Last seen: 2 years 3 months ago
Joined: 2021-10-22 13:03
Posts: 7

Hi, I´ve cloned your branch unit_test and did  a "make 100_250" the response was, "no rule to make target 100_250". My workaround is to delete all other boards from the "rebuild_all" script and run it.

kubark42
Offline
Last seen: 9 months 3 weeks ago
Joined: 2020-07-17 18:46
Posts: 54

Glad you figured out a workaround.

If you can paste the error output I can see what's going on. A bunch of us on Discord are using it now and it seems to be performing pretty solidly.

pe
Offline
Last seen: 2 years 3 months ago
Joined: 2021-10-22 13:03
Posts: 7

Thanks, it is now working. The problem was I checked out the wrong branch. Now the next issue is that I can not upload motor/app parameters on my new compiled code. I get the error message "Could not deserialize motor configuration". How do I override that? I have not added any parameter or so in the new firmware, just modified the output structure of the status5 CAN message. I will open a new thread to ask for this.

kubark42
Offline
Last seen: 9 months 3 weeks ago
Joined: 2020-07-17 18:46
Posts: 54

That happens when the firmware and the VESC-Tool don't have identical comms protocols. The way to fix that is to make sure the VESC-Tool is built with the same definitions as the firmware.

If you have a custom version of the firmware, I can build you a VESC-Tool which corresponds. Just ping me on the Discord server and we'll figure out what you need.