Threadx: What can prevent the threads to start when using signed binaries ?

Question

Hello,

I am experiencing issues when using the Secure Boot on a LPC55S69 JBD100 microcontroller.

I am trying to sign my software to ensure the integrity of the flashed image. For that I am following the AN12283 guide to activate the SecureBoot and sign my binaries.

I can see the main is correctly executed thanks to some logs, however after a millisecond I cannot see any operation performed. The Initialization completes, but the threads never start. And no error is reported through the HardFault handler.

When the secure boot is not active, the elf or unsigned binary images operate correctly, the threads automotically start after the initialization. Only in the signed image it does not.

It does not look like the error is with the signature in itself as the image is loading. So the verifications have passed correctly. So I do not understand how it can impact the threads execution. I have checked the signed binaries, they are identical to the unsigned ones except the image length, image type, image header offset fields, and the signature appended to the binary.

This error also happens with the Threadx demo provided by NXP.

What can cause this error ?

Microcontroller: LPC55S69JBD100 B1

OS: AzureRTOS, with Threadx

Tools:

openssl 3.0.2

elftosb-gui 1.0.12

blhost 2.6.2

Thank you in advance and have a nice day

Answer 1

Hi @Jean LAUNOIS - I don't know a reason why ThreadX wouldn't execute... ThreadX doesn't care how it's loaded. Maybe there is a problem with some security bit settings. I recommend you reach out to NXP for help with this issue.

Answer 2

Hello Jean LAUNOIS, Thanks for reaching out on this forum!

Community SME's on this topic or our team will review your scenario and circle back at the possible earliest time., meanwhile the below pointer may help!

Embedded security components: Memory protection

ThreadX uses memory protection mechanisms to ensure that code and data are not modified unintentionally. If the signed binary attempts to modify protected memory, ThreadX will prevent it from executing.

It is also possible that the issue is with the firmware or software that is being loaded, and not with the secure boot itself. You may want to check the firmware and software to ensure that they are trusted and that they are being loaded correctly.

Please check few of the below suggestions, which i found that may help with your initial query!

• If there are conflicts between thread priorities
• Ensure that the configuration of your signed image is correct
• Try to debug the issue by setting breakpoints in the code that initializes the RTOS and starts the threads. This will allow you to determine where the code execution is stalling and help identify the root cause of the issue.

Please comment in the below section with more info from your side if available, Product/Community SME will soon get back on this.