How to make Beyond Studio for NXP generate HEX file output?

[mferrari1]

Depending on whether the makefile indicates a debug version or not, building a project in Beyond Studio for NXP will generate either a ".elf" file or a ".bin" file.  I need a ".hex" file output.

Can anyone please tell me where in the IDE this can be configured?

Thanks,

Matt

[mferrari1 · Accepted solution]

OK, this problem has been solved...

Per the suggestion of LPCXpresso Support above, the original makefile was augmented to include the generation of the desired .hex file.

The changes to the make file are:

1a) Original makefile had the line:

all: $(TARGET)_$(JENNIC_CHIP)$(BIN_SUFFIX).bin

1b) The modified makefile changes this line to:

all: $(TARGET)_$(JENNIC_CHIP)$(BIN_SUFFIX).bin $(TARGET)_$(JENNIC_CHIP)$(BIN_SUFFIX).hex

2a) Original makefile had the code section:

$(TARGET)_$(JENNIC_CHIP)$(BIN_SUFFIX).bin: $(TARGET)_$(JENNIC_CHIP)$(BIN_SUFFIX).elf
    $(info Generating Binary ...)
    $(OBJCOPY) -S -O binary $< $@

2b) The modified makefile adds the additional code as follows:

$(TARGET)_$(JENNIC_CHIP)$(BIN_SUFFIX).hex: $(TARGET)_$(JENNIC_CHIP)$(BIN_SUFFIX).elf
     $(info Generating HEX File ...)
     $(OBJCOPY) -S -O ihex $< $@

The above modifications to the makefile resulted in the generation of the desired .hex file in the "Build" folder.

Additionally, the string "$(TARGET)_$(JENNIC_CHIP)*.hex" was added to the "clean:" line to remove the .hex file when doing a clean (this is not needed for the build however).

THIS IS IMPORTANT:  (and I thought this was very obscure) makefile does not treat all whitespace equally.  I got errors when trying to build if I used 4 "space" characters instead of a "tab".  The makefile requires "tabs", not "spaces" for the indentations in the above code sections.

I hope this will help anyone else trying to modify their makefile to generate .hex files

Matt

[mario_castaneda]

Hi Matt,

The command  $(OBJCOPY) -S -O binary $< $@ command copies all the memory section.

The JN516x chip all of our makefiles generate binary by copying the following sections as can be referred by looking at any Makefile in our application notes :

$(OBJCOPY) -j .version -j .bir -j .flashheader -j .vsr_table -j .vsr_handlers  -j .rodata -j .text -j .data -j .bss -j .heap -j .stack -S -O binary $< $@

LPCXpresso is for JN517x not for JN516x.

The make utility is notoriously picky about the use of Space instead of Tab

Could you please use tab instead of space in the Makefile

Regards,

Mario

[mferrari1]

Hi Mario -

Please excuse my misunderstanding of your last post.

I had mentioned in my previous post the importance of using TAB characters instead of SPACE characters in the makefile, so when you wrote "please use tab instead of space in the Makefile" I thought you had not read my post yet.

You presented the following makefile syntax for generating the ".bin" file:

$(OBJCOPY) -j .version -j .bir -j .flashheader -j .vsr_table -j .vsr_handlers  -j .rodata -j .text -j .data -j .bss -j .heap -j .stack -S -O binary $< $@

I am assuming then that the correct syntax for generating a ".hex" file would simply be:

$(OBJCOPY) -j .version -j .bir -j .flashheader -j .vsr_table -j .vsr_handlers  -j .rodata -j .text -j .data -j .bss -j .heap -j .stack -S -O ihex $< $@

Is this correct?

You also wrote: "The command  $(OBJCOPY) -S -O binary $< $@ command copies all the memory section."

I am inferring from your comments that this command will copy memory sections which should not be included in the ".bin" or ".hex" file.  What are these sections that should not be included?

The original makefile used to generate the ".bin" file I've been using all along was provided in the project I started from (AN1174_154). In this makefile (used with Beyond Studio for NXP) the command lines for the output file are:

$(TARGET)_$(JENNIC_CHIP)$(BIN_SUFFIX).bin: $(TARGET)_$(JENNIC_CHIP)$(BIN_SUFFIX).elf
$(info Generating Binary ...)
$(OBJCOPY) -S -O binary $< $@

So I am confused about why you are indicating that I need all the "-j" command line options.  Isn't this syntax provided by the AN1174_154 project correct?

Please clarify, thanks.

Matt

[mario_castaneda]

Hi Matt,

AN1174_154 copies all the sections, Use the same for generating hex. 

Regards,

Mario

[mferrari1]

Thanks Mario –

Below is an example of the beginning of the Intel Hex file that is generated by my build and that my secondary bootloader will be using to update the JN5169 Flash for updating the firmware.

The “Record Type” field of 02 (shown in red below) specifies that until otherwise indicated, all the addresses for following data should have the provided offset (shown in green below) shifted left 4 bits and added to the “normal” address provided in the “data” records that follow.

1. So the 1st line says “add 0x70000 to the following addresses”

2. Then the 2nd line says “put the data(0x0f03000b) at address 0x0007fffc”

3. The 3rd line says “now, for the following addresses, add 0x80000 to the provided address”

4. So the 4th line and the following lines write data to addresses 0x80000, 0x80010, 0x80020, etc…

:0200000270008C

:04FFFC000F03000BE4

:0200000280007C

:10000000123456781122334455667788080100006F

:1000100000000000000000000000000000000000E0

:1000200000014F2000094A6C0013012D014013FC10

The first two lines of the Hex File indicate writing the value of 0x0f03000b to address 0x7fffc. My guess is that this has something to do with the reset vector, is that correct?

As you know, Flash writes can only change “1” bits to “0” bits, so any Sector in which data is to be written must be erased in entirety before writing data to Flash addresses in that Sector.

So if my secondary boot loader needs to write 0x0f03000b to address 0x7fffc (as indicated by the Hex File), then I would need to first erase the entire sector from 0x78000 to 0x7ffff,and then write a 16-byte Pageword to 0x7fff0,but JN-AN-1003 indicates that this address range is in the “Reserved” area from 0x00002000 – 0x0007ffff, so I’m not sure I can even erase and write there…

I’m hoping that this value of 0x0f03000b at address 0x7fffc will remain constant from build to build and once the target has been programmed via the normal (NXP based) method the first time, I can just remove these first two lines from the subsequent Hex Files that will be used by my secondary bootloader, and just reprogram the JN5169 flash for the sectors starting at 0x80000.

So my question for you is just this: What are these 4 bytes at addresses 0x7fffc–0x7ffff, and can they change from build to build or will they remain constant from build to build?

For the builds I have looked at, the value has remained unchanged, but not knowing what these bytes are, I cannot know if that will always be the case…

Thanks Mario,

Matt

[mferrari1]

Hi Mario

Did you see the solution I had already posted?

Is what I posted correct, or does it need changes?

Thanks,

Matt

Sent from my Verizon, Samsung Galaxy smartphone

[mario_castaneda]

Hi Matt,

What is the specific reason that you need the hex file for the JN516X devices?

Regards,

Mario

[mferrari1]

Hi Mario –

Please see this link:

https://dzone.com/articles/mcuxpresso-ide-s-record-intel-hex-and-binary-files

It appears that the NXP IDE MCUxpresso provides the ability to generate the output file in .hex format.

Hopefully there is some way to get a .hex file output from BeyondStudio for NXP as well.

Thanks,

Matt

[ErichStyger]

the original article is here:

MCUXpresso IDE: S-Record, Intel Hex and Binary Files | MCU on Eclipse 

that site hosts other articles around the IDE and SDK too :-).

Erich

[mferrari1]

Hi Mario –

We use a standardized interface for updating code in all of our end products.

This interface takes a .hex file as an input, then passes it over the interface in blocks to the target device.

The target device likewise uses the same interface methodology by which it receives the blocks of date and updates the code image in the Flash on the target device.

In order to utilize our standard interface, I need to be able to present it with the code image in a .hex file format.

If BeyondStudio for NXP has a provision for generating the output in a .hex file format, that would be great.

If not, perhaps there is the opportunity to add in some command line syntax to generate a .hex file explicitly?

Thanks,

Matt

[lpcxpresso_supp]

I'm not familiar with Beyond Studio but being an Eclipse-based IDE, it should allow adding post-build steps. To do this, you'll have to go to project's properties, Settings section under C/C++ build and then switch to Build Steps. Simply add the appropriate objcopy command that generates the hex file (e.g. <prefix>objcopy -v -O ihex "input.elf" "output.hex"). Moreover, please make sure to select the right build configuration in the Settings page.

Greetings,
MCUXpresso IDE Support

[mferrari1]

Thank you for your reply to my question.

I went to the window you described, but see no opportunity to “switch to Build Steps. See screenshot below:

BeyondStudio for NXP is the NXP provided IDE for developing with the JN5169. It is Eclipse based, but is customized, so some aspects of it may be different.

I thought the IDE might have a built-in option for generating a “.hex” file output, but adding the post-build directive as you described seems like it should do the trick.

So I need to identify where in this NXP IDE I can specify those steps and also, need to verify the correct syntax.

My project name is WCB_B_Coordinator, so then the syntax to add would be exactly:

objcopy -v -O ihex “WCB_B_Coordinator.elf” “WCB_B_Coordinator.hex”

Is this correct? Or is 

a field which I am supposed to modify?

Thanks in advance for your help with identifying where to add this command line and also to confirm that my interpretation of the syntax is correct.

Matt

[lpcxpresso_supp]

Not sure what's with the missing Build Steps page but the objcopy command looks fine. You might need to add the appropriate prefix, depending on the cross tools from Beyond Studio. Moreover, if you have a manually written makefile, you can add the "post build" command in your makefile.

Greetings,
MCUXpresso IDE Support