NXP-MCUBootUtility 2.0.0 - SREC file not recognized

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

NXP-MCUBootUtility 2.0.0 - SREC file not recognized

Jump to solution
1,803 Views
dmarks_ls
Senior Contributor I

I'm trying to use the MCU Boot Utility (version 2.0.0) to flash load my custom board.  I've done this operation successfully in the past, which is why I'm confused as to why the operation is now failing.

I start the utility, and by picking the right settings (IS25LP064A flash, Set StatusReg1[6] for quad, Has Option1, Enable Second Pinmux), I am able to connect to the USB bootloader without issue.  However, I don't even need to do that part to encounter the bug.  In the center green window, I select the SREC file that is generated from my project using arm-none-eabi-objcopy, I select "Motorola S-Records", and I click "Generate Unsigned Bootable Image".  After a couple of seconds, I get this dialog (redacted to remove project name):

utility_cannot_recognize_format_2.png

What the heck, this used to work fine.  (I learned early on, don't try to feed it a raw AXF file, it gets very confused.)  So, I modify my build script to generate an Intel HEX file as well as an SREC file.  I then change the source file to the IHEX file, change the type to "Intel Extended Hex", and click "Generate Unsigned Bootable Image".  A couple of seconds later, this pops up:

utility_cannot_recognize_format.png

Now it's apparently complaining about the intermediate file (HEX --> SREC) it's creating in the working directory.  I take a look, and the working file is pretty darn close to my original SREC file.  Dismissing that dialog, it then unhelpfully tells me:

utility_cannot_recognize_format_3.png

I've programmed my custom board successfully in the past using the utility.  But it's flat out refusing to accept the SREC image I give it, or recognize the SREC image that it creates for itself when given a HEX file.  What gives?  I've attached my SREC and HEX files if you want to see what's happening underneath the hood.  For what it's worth, I can generate a bootable file from the RT1050 Qt Thermostat Demo HEX file just fine, and that's twice the size of my project.  Hopefully you can figure out what's breaking, because right now, this is the only utility I know of that can program an RT1050 over USB, and our customer needs this for a demo in two weeks.  Thanks.

(Tagging jayheng‌)

David R.

0 Kudos
1 Solution
1,651 Views
jay_heng
NXP Employee
NXP Employee

Hi David,

  Thanks for using my tool!

  I just checked your srec file, there were two data blocks in the srec file, one is located in OCRAM (0x20200000 -), another is in SPI Flash (0x60000000 -), Tool cannot support such kind of srec file, only the srec file with one data block can be supported.

pastedImage_1.png

Best Regards,

Jay

View solution in original post

4 Replies
924 Views
et0
Contributor II

Hi Jay and David. I have the same problem. 

I have a totally default system (RT117x, Avnet Maaxboard-RT) and I try to load the example projects such as MaaXBoard-RT-V3--GUI-Demo-Lite

Building in MCUXpresso is OK, and I use the .axf file output. But the MCUBootUtility has a problem with the .srec after it has converted it.

 

I realise it is not the problem of MCUBootUtility, but can you give some advice on how to set up MCUXpresso so that the output can be loaded?  I attach the sample .axf and the sample .srec that is generated.

Thank you

0 Kudos
1,651 Views
jay_heng
NXP Employee
NXP Employee

And i find that the data block in OCRAM are all 0x00s, are they .bss init section data?Why do we need to include such section in final srec file?

1,651 Views
dmarks_ls
Senior Contributor I

Thank you, this was the clue I needed.  My coworker helped me figure out a solution, and the tool is now working.  I'll explain what I did originally that caused the issue, and what the fix was.

In my project, I decided to take full advantage of the memory in my RT1050.  I have an external SDRAM, as well as the internal RAM of the RT1050, which is divided into 128K of DTC (data tightly coupled), 128K of ITC (instruction tightly coupled), and 256K of OC (on-chip, i.e. the remainder of the RAM).  I have a lot of stuff that needs to be heap-allocated (FreeRTOS stuff, plus C++ library stuff), and 128K is definitely not enough for all my data.  Also, I want FreeRTOS managing the heap for thread safety, so I've mapped malloc() and free() onto the FreeRTOS allocation functions.  I'm also using configAPPLICATION_ALLOCATED_HEAP, so I'm statically allocating the FreeRTOS heap (ucHeap) in my code.

I have global data set to BOARD_SDRAM, and to (maybe?) speed things up, I've given over SRAM_OC to the heap (ucHeap).  I did this in the linker file to create a memory section that would be exclusively for the use of the heap:

linker_properties.png

I then put this declaration in my code:

#if defined(configAPPLICATION_ALLOCATED_HEAP) && (1 == configAPPLICATION_ALLOCATED_HEAP)
__attribute__((section(".osHeap")))
uint8_t ucHeap[configTOTAL_HEAP_SIZE];

Via the debugger, everything just works fine.  So when you said that there was a giant chunk of zero-initialized memory at 0x20200000, I knew that had to be it.  I guess that objcopy doesn't know to exclude section ".osHeap" from the SREC/HEX file, even though it's labeled as BSS.  So my coworker figured out that I could just say this instead:

#if defined(configAPPLICATION_ALLOCATED_HEAP) && (1 == configAPPLICATION_ALLOCATED_HEAP)
__attribute__((section(".bss.$SRAM_OC")))
uint8_t ucHeap[configTOTAL_HEAP_SIZE];‍‍‍

Changing the section to ".bss.$SRAM_OC" didn't move ucHeap at all, but it did apparently convince objcopy to ignore it when creating my SREC file, because I can now generate an unsigned image without a problem.  (And now I can delete that unused *(.osHeap) section from the linker file.)

David R.

0 Kudos
1,652 Views
jay_heng
NXP Employee
NXP Employee

Hi David,

  Thanks for using my tool!

  I just checked your srec file, there were two data blocks in the srec file, one is located in OCRAM (0x20200000 -), another is in SPI Flash (0x60000000 -), Tool cannot support such kind of srec file, only the srec file with one data block can be supported.

pastedImage_1.png

Best Regards,

Jay