Always build both .hex and .bin files

[alzix]

Summary of changes

• This change will cause build-system to produce both .bin and .hex files.
• Files are small and their creation is fast, thus there are no negative impact
  on build time and storage requirements.
• .bin files are required for updating the device
• .hex files are very handy for post build (external to build system) custom
  scripts (e.g. image signing)
• Configuration still allows selecting either .bin or .hex files, this settings is still
  relevant as it specifies what file is flashed to a device for tests or by
  --flash argument.

Impact of changes

None

Migration actions required

Documentation

---

Pull request type

[] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[x] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

---

Test results

[] No Tests required for this change (E.g docs only update)
[x] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

---

Reviewers

@donatieng

---

[ciarmcom]

@alzix, thank you for your changes.
@donatieng @ARMmbed/mbed-os-tools @ARMmbed/mbed-os-maintainers please review.

[0xc0170]

One thing to consider, will need tools team review: how this would work in the online compiler - I recall that was a problem previously - multiple files download , in this case .bin + .hex - or is that handled ?

[alzix]

i'm fine with not modifying online compiler and downloading a single file

[alzix]

there are multiple build artifacts generated during the build. I supposed only a single file is downloaded. This change will add yet another build artifact - so i do not think we need to change online compiler behaviour.

[0xc0170]

It looks to me that this should be compatible with the online compiler as full_path is as it was, we just run additional binary()

[0xc0170]

I'll run CI shortly but this still needs tools review

[mbed-ci]

Test run: SUCCESS

Summary: 6 of 6 test jobs passed
Build number : 1
Build artifacts

[adbridge]

@Patater please review

[0xc0170]

@ARMmbed/mbed-os-tools Please review

[rwalton-arm]

This is probably OK. We are hoping to freeze the legacy tools soon, due to the time and effort it takes to create online releases. If I'm understanding correctly, I don't think affects the online compiler so probably doesn't require an online release. @Patater

[0xc0170]

This is probably OK. We are hoping to freeze the legacy tools soon, due to the time and effort it takes to create online releases. If I'm understanding correctly, I don't think affects the online compiler so probably doesn't require an online release. @Patater

@Patater Please confirm, and we merge this one otherwise will be rejected.

[mbed-ci]

Test run: SUCCESS

Summary: 6 of 6 test jobs passed
Build number : 2
Build artifacts

[lefebvresam]

I use the NUCLEO-F091RC and after updating to mbed 6.2.0 and using the --flash option, the hex will be copied with precedence to the bin.

line 2804 in mbed-cli:

fw_file = fw_fbase + ('.hex' if os.path.exists(fw_fbase+'.hex') else '.bin')

This creates an issue: flashing will not start: the hex stays in the virtual F: folder or I get the message that it is too big.

mbed compile --flash
...
| source\widget_visible_type.o  |    630(-176) |   0(+0) |    0(+0) |
| Subtotals                     | 90340(-1676) | 544(+0) | 9712(+0) |
Total Static RAM memory (data + bss): 10256(+0) bytes
Total Flash memory (text + data): 90884(-1676) bytes

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

Copying the bin manually works perfect:

mbed compile --target nucleo_f091rc --toolchain GCC_ARM && copy .\BUILD\NUCLEO_F091RC\GCC_ARM\project.bin F:\

[lefebvresam]

If I put line 789 of mbed-os\tools\toolchains\mbed_toolchain.py in comment, it works like before:

                self.binary(r, elf, "{}.{}".format(stem, 'bin'))
                # self.binary(r, elf, "{}.{}".format(stem, 'hex'))
            if self.config.has_regions:

| source\widget_visible_type.o  |   630(+0) |   0(+0) |    0(+0) |
| 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\project.bin
        1 file(s) copied.

Is it possible to make it configurable in mbed_app.json?

I tried with:

        "NUCLEO_F091RC": {
                 "target.OUTPUT_EXT": "bin"
        }

But this has clearly no effect.

[0xc0170]

Thanks @lefebvresam for the report. I can confirm this is an issue for the tools. The logic for flashing is https://github.com/ARMmbed/mbed-cli/blob/master/mbed/mbed.py#L2804 . If hex is found first, it is used otherwise binary.

I'll create a revert PR, we shall provide this option with new tools