How to use the valid user code checksum on LPC55

[andrewjfox]

I've previously used other LPC devices and understand how the valid user code checksum works, but now using the LPC55 (Cortex-M33) device in new project, and doesn't look like it uses the valid user code checksum. The linker map shows it being generated, and startup code has the declaration, but it's not getting put into the vector table. The vector table seems to have another entry for SecureFault_Handler where the checksum is normally placed. And when I inspect the hex file, the 8th entry is location of SecureFault_Handler from linker map.

Does the LPC55xx / Cortex-M33 use the valid user code checksum, and if not is there another similar option to verify the vector table is valid ? 

WEAK extern void __valid_user_code_checksum();
extern void _vStackBase(void);

//*****************************************************************************
//*****************************************************************************
#if defined (__cplusplus)
} // extern "C"
#endif
//*****************************************************************************
// The vector table.
// This relies on the linker script to place at correct location in memory.
//*****************************************************************************



extern void (* const g_pfnVectors[])(void);
extern void * __Vectors __attribute__ ((alias ("g_pfnVectors")));

__attribute__ ((used, section(".isr_vector")))
void (* const g_pfnVectors[])(void) = {
    // Core Level - CM33
    &_vStackTop,                       // The initial stack pointer
    ResetISR,                          // The reset handler
    NMI_Handler,                       // The NMI handler
    HardFault_Handler,                 // The hard fault handler
    MemManage_Handler,                 // The MPU fault handler
    BusFault_Handler,                  // The bus fault handler
    UsageFault_Handler,                // The usage fault handler
    SecureFault_Handler,               // The secure fault handler
    0,                                 // ECRP
    0,                                 // Reserved
    0,                                 // Reserved
    SVC_Handler,                       // SVCall handler
    DebugMon_Handler,                  // Debug monitor handler
    0,                                 // Reserved

[Peter-M2PRO]

The LPC553x does not use the __valid_user_code_checksum as you've discovered. This is not explicitly documented. It follows from the fact that the vector is used, not reserved. The vector table is listed in LPC553x Reference Manual, Rev. 3, 07/2023 Table 13. Interrupt Vector Assignments.

Instead, you can use the Boot ROM (chapter 26). It uses a different image format (Table 119) that is compatible with this part's vector table: It uses the reserved fields for special purposes such as an optional CRC. By default, these are all zero in the binary and the optional features are disbled.

I haven't used this myself, but you should be able to change the "imageType" at address 0x24 from value "0x0: plain image" to "0x2: plain image with CRC". Read the entire chapter for the full implementation.

[andrewjfox]

Thanks, I'll have a closer look, and see if it'll work for me.  It's dissappointing there's no simple response, or even a knowledge base article, from NXP to cover this.

[Pavel_Hernandez]

Hello, I apologize for the late response I reviewed the ARM Cortex M33 documentation but I couldn´t find any related for the checksum. Seems like the user_code_checksum is an implementation by the Linker.

But I notice this on de document page 59 there is a Figure 3-4 Vector table without security and Figure 3-5 Vector table with security. If you notice the SecureFault use the next reserved area. 

I recommend a double check on the ARM documentation.

Best regards,
Pavel

[andrewjfox]

Hi Pavel, I appreciate you're trying to help but it's clear to me that you just don't have resources to answer this.

I know it's not an ARM feature, both from having already checked ARM documentation, and from my previous experience with other LPC parts, specifically LPC1347. This is an NXP special function, and if you can't find any reference on internal NXP knowledge base or by asking other support colleagues, then perhaps not a well documented feature either.  All it needs is list/database within NXP that shows which CPUs have this feature and which don't and why.

I don't want to keep wasting your time or mine on this question however it is NOT resolved so I do not want to accept solution.

For your reference I've included excerpt from the LPC1347 user manual section 21.7 which explains how the checksum works. On the LPC1347, and most other LPC devices, if the checksum is incorrect, the application code won't be executed. The LPC55 must be different because the linker is not placing the checksum in the vector table, and the application is running ok.

[Pavel_Hernandez]

Hello, my apologize I was researching more information, and I found this thread that maybe could help you to add the checksum.

Create CRC32 checksum for LPC55 application in Mcuxpresso IDE - NXP Community (community-nxp-com.tra...

CRC Checksum Generation with ‘SRecord’ Tools for GNU and Eclipse | MCU on Eclipse

Best regards,
Pavel

[andrewjfox]

Very frustrating!  These are both related to checksums on the entire image, and are not related to the vector table checksum. 

The fact that as part of NXP Support you dont know, and can't find any specific information about the LPC55 series and the vector table checksum, which I might remind you is a NXP only special function, is concerning.

This is the problem with outsourcing support to forums. NXP is now free to ignore the issue, not provide a reasonable answer, and I have no recourse but to work it out myself.

This whole excercise has been a waste of my time, and yours

Where is the button for me to click "No solution available", or does NXP not want this type of feedback??

[andrewjfox]

Yes at the moment I'm using the LPC55S28, because we're developing firmware on the eval kit. For production will probably use the LPC5528 (non-secure version) as we're not using the security features of the 'S' variant. 

[Pavel_Hernandez]

Hello, my name is Pavel, and I will be supporting your case, I reviewed your case could you confirm if this is similar that you saw?

Best regards,
Pavel

[andrewjfox]

Hi Pavel, thanks for quick reply.  No this is different to what I'm seeing.  The attached image is from my hex file, and shows the entry at 8th location, which I expect to be the user checksum, but is definitely not. It is 00000223, which is marked in the map file as address of SecureFault_Handler. The SecureFault_Handler is also in the startup file, supplied by SDK. It looks like the linker is not placing the checksum in the vector table, but placing the SecureFault_Handler instead. Is this an option I can change? Is it specific to the LPC55 only ?  The bootloader must not be checking the vector table like for other NXP parts because it would fail.

[Pavel_Hernandez]

Hello, I think is the same issue that I show on the image, let me share this information maybe could help you.

This is not an issue by the GCC, about the checksum issue, the checksum is added by our code in startup file. It doesn't relate to the complier. I have check MCUXpresso SDK demo, it added the checksum in startup and linker file. Please check below figure.

Best regards,
Pavel

[andrewjfox]

I know it's not a GCC or compiler issue, and haven't said that at all

[andrewjfox]

Can you confirm that the example you provided is for the LPC55S28 ?? I am using the standard startup file provided by SDK. What are the consequences if I modify the vector table to include the checksum, as this means removing the SecureFault_Handler.

In my example the checksum is not added to the vector table, however the application still runs ok. This is in direct contradiction with other NXP documentation which states the bootloader checks the vector table and only runs application if the checksum is valid.

[andrewjfox]

This post implies that checksum is required for all NXP parts, however it is clear to me that the LPC55 (maybe others) do not follow this rule

See this post

https://community.nxp.com/t5/LPCXpresso-IDE-FAQs/LPC-Image-Checksums/m-p/471035

"NXP LPC parts use a word in the vector table of the processor to store a checksum that is examined by the bootloader to identify a valid image. For ARM7/ARM9 based parts this checksum word is stored at offset 0x14, for Cortex-M based parts it is stored at offset 0x1C"

[Pavel_Hernandez]

Hello, are you are using the LPC55S28? just for be sure.

I reviewed the information, and the thread is too old, let me get more details about this.

Because if this is true "NXP LPC parts use a word in the vector table of the processor to store a checksum that is examined by the bootloader to identify a valid image." is not happening. 

Note: I will open an internal case to get more details.

Best regards,
Pavel