[RFC] Make Targets.json feild `OUTPUT_EXT` select output format too

[theotherjimmy]

• Type: Bug/Enhancement
• Priority: Minor

The feild OUTPUT_EXT renames the ELF file created by the selected tool-chain from <name>.elf to <name>.<OUTPUT_EXT>. I would expect more structured behavior. See below for my recommendations.

Target

• MCU_NRF52
• MCU_NRF51
• MCU_NRF51_UNIFIED
• TEENSY3_1
• New targets yet to be added

I did some investigation, and I think that all of the post build hooks for the targets in question would not need to be updated to handle my proposed change.

Compiler

The compilers that would support my proposal are:

• GCC_ARM: all versions
• ARM: all versions
• IAR: all versions

Versions

• mbed-cli: 1.0.0 (irrelevant)
• mbed-os: 5.1.0 - master (or longer, I did not check farther back)

Actual behavior

The OUTPUT_EXT field renames the ELF file to whatever is contained within that key.The website build system also uses this key to determine what file to transfer to the user.

Expected behavior

The OUTPUT_EXT field would have 3 allowed values: elf, bin and hex. Each of these would create an appropriate file in the output directory from the ELF file.

• elf does not create an additional file.
• bin creates a binary file from the ELF file with the extension .bin. This option should be the default.
• hex creates an Intel HEX file from the ELF file with the extension .hex.

The website build system would still use the contents of this key to determine what file to transfer to the user.

Reasoning

I have been queried about what this key does several times (in person).Each time I am queried, the question is worded something like "I tried to set the OUTPUT_EXT key in targets.json to hex, but I did not get an Intel HEX file output. What gives?" This Implies to me that writers of targets.json expect the key to change the type of the file in addition to the extension.

Request for comments from

• @maclobdell
• @sg-
• @screamerbg

[sg-]

I think this resolves #3928

[0xc0170]

The OUTPUT_EXT field would have 3 allowed values: elf, bin and hex. Each of these would create an appropriate file in the output directory from the ELF file.

Offline use:
Shouldn't elf file be always generated, then only 2 of those bin/hex would be based on the extension key value?

Online use:
Output file as specified via extension key value

[maclobdell]

NCS36510 post build script currently relies on .bin file input and then processes it to generate the output file. The output file is currently bin format , but they want to switch to hex format. It would be better to start with .hex file, process it, and output .hex file to users. This later flow should result in smaller file size due to large area between flash banks which is present in binary, but shouldn't be in hex.
Currently, enabling the OUTPUT_EXT option, it disables the generation of the .bin file which is needed for the current NCS36510 post build script (add_fib.py). However, once this option is fixed, and a valid hex file is generated, the NCS36510 post build script can be changed to use .hex file that as input and then output a hex file that is passed to the user.

[maclobdell]

One extra clarification to the last statements I just made. This fix is critical if we want to go with hex file support on NCS36510, which enables clean support of the dual flash banks (640K flash total).

[theotherjimmy]

It seems like this is approved, and is higher priority than I had originally anticipated as it could help the NCS36510 porting. PR coming soon.

[0xc0170]

@theotherjimmy What about my comment - online vs offline use : #3973 (comment) ?

[theotherjimmy]

@0xc0170 How are those scenarios different from what I was suggesting? BTW, we have to generate the elf before generating the bin or hex. That's just how all of the tools work.