blhost reliable-update command not working

[Samson88]

Hello,

I am trying to implement reliable update on the FRDM-K32L3A6 board.  I have two applications that flash a red LED:

• blinky_slow.bin  (flashes LED slowly)
• blinky_fast.bin   (flashes LED rapidly)

Each of these apps has the Bootloader Configuration Area at address 0x3C0 configured so that ROM bootloader will do a CRC check (see attached pic).  If I load the apps individually at start of flash 0x0000, the ROM bootloader CRC check passes and the image boots.  Works great for both!

But if I load blinky_slow.bin into lower half of flash at address 0x00000, then I load blinky_fast.bin into upper half of flash at address 0x80000, and issue this command:

blhost -p COM5 reliable-udpate 0x7FF00

I expect this command to swap the upper and lower flash regions such that after reset the backup image in upper flash (blinky_fast.bin) will run.  But I get this error:

Response status = 10603 (0x296b) kStatus_ReliableUpdateBackupApplicationInvalid

It seems like the ROM bootloader is checking the CRC of the backup image (blinky_fast.bin) and it fails. 

But how can this be?  The CRC for blinky_fast.bin passes if I load it into 0x00000.  Can "BackupApplicationInvalid" mean something else besides CRC check fail?

Thanks in advance,

Sam

[Samson88]

Here are the commands I'm using:

C:\nxp\MCUX_Provi_v7\bin\tools\openssl\1.1.1o\win32>blhost -p COM5 flash-erase-all-unsecure
Ping responded in 1 attempt(s)
Inject command 'flash-erase-all-unsecure'
Successful generic response to command 'flash-erase-all-unsecure'
Response status = 0 (0x0) Success.

C:\nxp\MCUX_Provi_v7\bin\tools\openssl\1.1.1o\win32>blhost -p COM5 write-memory 0x0000 blinky_slow.bin
Ping responded in 1 attempt(s)
Inject command 'write-memory'
Preparing to send 12024 (0x2ef8) bytes to the target.
Successful generic response to command 'write-memory'
(1/1)100% Completed!
Successful generic response to command 'write-memory'
Response status = 0 (0x0) Success.
Wrote 12024 of 12024 bytes.

C:\nxp\MCUX_Provi_v7\bin\tools\openssl\1.1.1o\win32>blhost -p COM5 write-memory 0x80000 blinky_fast.bin
Ping responded in 1 attempt(s)
Inject command 'write-memory'
Preparing to send 12024 (0x2ef8) bytes to the target.
Successful generic response to command 'write-memory'
(1/1)100% Completed!
Successful generic response to command 'write-memory'
Response status = 0 (0x0) Success.
Wrote 12024 of 12024 bytes.

C:\nxp\MCUX_Provi_v7\bin\tools\openssl\1.1.1o\win32>blhost -p COM5 reliable-update 0x7FF00
Ping responded in 1 attempt(s)
Inject command 'reliable-update'
Response status = 10603 (0x296b) kStatus_ReliableUpdateBackupApplicationInvalid

[Pavel_Hernandez]

Hello, I reviewed the reference manual to check if that command is supported, unfortunately, the Reliable Update is not supported.

Page 642.

Best regards,
Pavel

[Samson88 · Accepted solution]

Hello Pavel

Thank you for this information.  It's helpful.  But actually, I had flash security disabled, so the reliable update command was available.  So that was not the cause of the problem.

I found the solution though!  I discovered that the ROM bootloader behaves a little differently upon reset than it does when doing a reliable update. 

To be specific, I had the CRC start address on the Bootloader Configuration Area (BCA) set to 0x400.  In other words, I was telling the bootloader to start the CRC check just after the BCA.  When you do a reset, this is allowed.  But when doing a reliable update, it is NOT allowed.  Reliable update requires that the CRC check start at the very beginning of the application (in my case 0x0000).  

So in the BCA, I changed the CRC start address to 0x0000 and increased the CRC byte count to be the size of the whole image (from 0x2AF8 to 2EF8) and this solved it.  The reliable-update command now works. 

NOTE:  From  MCU Bootloader v2.5.0 Reference Manual, Rev. 1, Chapter 12 (Reliable Update), page 154 :

the bootloader continues to validate the integrity of the backup
application by checking: the following
1. Is crcStartAddress is equal to the start address of the vector table of the application.
2. Is crcByteCount (considered as the size of backup application) is less than or equal to
the maximum allowed backup application size.
3. Is the calculated CRC checksum is equal to the checksum provided in backup
application, given that the above conditions are met.