Copying hex instead of bin

ARMmbed / mbed-cli

Arm Mbed Command Line Interface

https://os.mbed.com

Apache License 2.0

334 stars 176 forks source link

Copying hex instead of bin #980

Closed lefebvresam closed 4 years ago

lefebvresam commented 4 years ago

After upgrading to mbed 6.2.0 and using "mbed compile --flash", both .bin and .hex files are generated, but only the hex is copied to F: (NUCLEO F091-RC board). It gives this error:

...
| Subtotals                     | 90340(+0) | 544(+0) | 9712(+0) |
Total Static RAM memory (data + bss): 10256(+0) bytes
Total Flash memory (text + data): 90884(+0) bytes

Image: .\BUILD\NUCLEO_F091RC\GCC_ARM\hmipanel.bin
There is not enough space on the disk.
        0 file(s) copied.
[1595201382.32][COPY][ERR] [ret=1] Command: ['copy', u'BUILD\\NUCLEO_F091RC\\GCC_ARM\\hmipanel.hex', u'F:hmipanel.hex']
[mbed] ERROR: Unable to flash the target board connected to your system.
---

Copying the .bin file manually in F: works. Previously with mbed 5.14 I did not had this issue.

ciarmcom commented 4 years ago

Thank you for raising this detailed GitHub issue. I am now notifying our internal issue triagers. Internal Jira reference: https://jira.arm.com/browse/IOTBTOOL-869

lefebvresam commented 4 years ago

See also my comments on: https://github.com/ARMmbed/mbed-os/pull/13011

My suggestion is to have a cli option to flash bin or hex for compatibility reasons between different boards.

jeromecoutant commented 4 years ago

Note that with the latest ST Link FW version available in https://www.st.com/en/development-tools/stsw-link007.html Hexadecimal drag and drop feature is now supported!

Regards,

ianhattendorf commented 4 years ago

I ran into this issue as well and wasted a good chunk of time figuring out why none of my changes were doing anything after updating from 6.1 on a Nucleo L432KC.

I've updated to the latest STLink FW and everything is fine now, however it would be nice if this was fixed to avoid wasting other peoples time going forward.

jeromecoutant commented 4 years ago

@MarceloSalazar This issue takes long time to understand to every one (including me...) @ARMmbed/mbed-os-tools

ianhattendorf commented 4 years ago

Actually it's still an issue for me. The latest firmware I can find for my device (from https://www.st.com/en/development-tools/stsw-link007.html) is V2.J36.M26 and .hex support was added in V2.J37.M26.

Thanks for taking a look at this.

jeromecoutant commented 4 years ago

Actually it's still an issue for me. The latest firmware I can find for my device (from https://www.st.com/en/development-tools/stsw-link007.html) is V2.J36.M26 and .hex support was added in V2.J37.M26.

ST web page is maybe misleading... If you select "Get Software" pink button, you will get the 2.37.26 version Versions you can select are "previous" versions...

@schstm

ianhattendorf commented 4 years ago

🤦

I should pay more attention, thank you.

teetak01 commented 4 years ago

Maybe --flash should use the OUTPUT_EXT parameter for deciding which image to flash? Afaik the generation of both .bin and .hex images was added some time ago, but the --flash feature probably has some simpler logic for choosing the image.

Just commenting, did not check the code where the parsing is done.

lefebvresam commented 4 years ago

I temporary solved this issue by doing this change:

Change line 789 of mbed-os\tools\toolchains\mbed_toolchain.py
...
                # self.binary(r, elf, "{}.{}".format(stem, 'hex'))
...

By not generating the hex, the bin is used as the second choice for flashing.

jeromecoutant commented 4 years ago

Correction is on going: https://github.com/ARMmbed/mbed-os/pull/13584

0xc0170 commented 4 years ago

PR merged, so should work in the next release. I'll close this one