Firmware Update via USB-HS

[cdsteinkuehler]

I am attempting to follow the instructions for using a flash image with CRC checksum as described in AN13183.  I can successfully turn my application's axf file into a binary image with the MCUXpresso IDE or the arm-none-eabi-objcopy command line.  The generated bin file boots and runs as expected when programmed onto the LPC55S16-EVK using the blhost.exe utility.

I am having problems, however, with getting a CRC based image to boot.  Using the elftosb-gui utility as directed by the application note, I get a binary file that does not seem to boot (nothing appears on the USB bus and I see no serial output from the debug console).  There are only 8 bytes different between the two binary files:

Offset 0x20: 0x00 0x00 -> 0x34 0xB7

Offset 0x24: 0x00 0x00 -> 0x05 0x40

Offset 0x28: 0x00 0x00 0x00 0x00 -> 0x24 0x16 0xB7 0x3A

According to Table 1, Offset 0x20 is the application length which should be 0 for image type 0.  My bin file is 46900 (0xB734) bytes long.

Offset 0x24 is the image type, which Table 1 indicates should be 0x0005 for a CRC image.  The value 0x4005 is not listed as a valid option.

If I change the image type from 0x4005 to 0x00005 the LPC55S16-EVK boots into the ISP boot-loader, likely because the length and/or CRC value is incorrect.  With the image type set to 0x4005, I get no response from the board unless I force it into ISP mode (press reset with the ISP button pressed).

Please advise how to generate a correct CRC bin image for the LPC55S16.  The json and script files created by elftosb-gui (version 1.0.10) are attached as a reference.

[Alice_Yang]

Reply the workaround in salesforce.

[cdsteinkuehler · Accepted solution]

I have verified the response from the NXP team works as expected.  My application now boots and runs properly when using a *.bin file with CRC checksum generated per AN13183.

The NXP team has come back with something for you to try below. Let me know if this works (or not).

Sorry for the delay, please try the configuration below to see if it fixes your issue.

Please delete the define " configRUN_FREERTOS_SECURE_ONLY" or set it to 0.
In the file "FreeRTOSConfig.h" line 152: 

//#ifndef configRUN_FREERTOS_SECURE_ONLY
// #define configRUN_FREERTOS_SECURE_ONLY 1
//#endif

[Alice_Yang]

Hello cdsteinkuehler,

Have you refer to the "Figure 3. elftosb-gui application UI interface" of AN13183 create CRC bin file?

What about your firmware, please use a simple LDE demo that without printf to console. 

BR

Alice

[cdsteinkuehler]

I finally have time to return to this after getting side-tracked to do some hardware design.

Using the lpc551x_image_crash_mcux application provided with AN13183, I see the expected behavior and the image with a CRC checksum added boots normally.  Pressing SW1 erases a portion of the flash and the MCU then boots into ISP mode.

I repeated the steps used with the lpc551x_image_crash_mcux application using my custom application I get the behavior I saw previously: The bin image without a CRC checksum boots normally, but the image with a CRC checksum does not boot normally (appears to hang in startup) and is not in ISP mode.

One major difference is my application is significantly smaller than the image_crash app.  I tried padding my bin file prior to creating the CRC version but it still fails to boot properly.

Are there any significant differences in how the boot ROM leave the MCU state between the CRC and non-CRC boot paths?  My startup code is pretty much unmodified from the composite_hid_audio_unified_freertos SDK example project I started from.

[cdsteinkuehler]

I figured out how to attach the debugger to the "running" target (eg: without reprogramming the flash).  It appears the target has a forced hard fault.  Restarting and stepping through the code, the fault occurs when the main routine calls vTaskStartScheduler().

Is there a way I can find out what the boot ROM code is doing differently when booting a CRC image vs. a plain binary?