Fashing problem on LPC55S69-EVK

[raz3l]

Hi there,

I am running some examples from the SDK_2.5.1_LPCXpresso55S69_GCCARMEmbedded for the LPC55S69-EVK related to Trustzone (Secure Faults example). For each example I created my own Makefile with only the strictly necessary source files (.c, .h, .ld, .S) – which I accomplish by exploring the CMAKE build mechanism (dependencies, compiler flags, etc) provided for each example. I am able to compile the Trustzone-based examples without running to any issue, and I already tested them on the board by flashing through a J-link probe and a GDB session (as recommended on the User Guide).

My next step was to create a makefile-based project on MCUXpressoIDE (File->New->New Project->C/C++Project or New C/C++ Project – I tried both the alternatives), since I wanted to use the debugger interface provided by the tool. For both secure and non-secure applications I was able once again to build them correctly using my makefile (no issues to link the secure gateway library generated during the build of the secure app).

After this process, I run into a issue while trying to initiate a debug session (I am using the on-board debugger). I simply flash the NS app using the LinkServer and once I try to debug the secure app (which I already loaded with the non-secure symbols) I run to an error while the probe is trying to flash:

“Target error from Commit Flash write: Em(12). Target rejected debug access at location 0x1000A000
GDB stub (crt_emu_cm_redlink) terminating – GDB protocol problem: Pipe has been closed by GDB.”

I should add the steps that I took to start the debug session where:

1) Force the LPC555S69 into ISP mode and use GUI Flash Tool to do a Mass Erase".

      Confirmation message: "Operation Complete"

2) Program NS project, by reconnecting first the board debug port.

      Confirmation message: "Operation Complete"

      Console: "Finished writing Flash successfully"

3) Kill active debug session by pressing "Clean up debug" button

4) Edit the secure debugger script and add the command "add-symbol-file <location>TZ_Secure_Faults_NS.elf 0x00010000

5) Debug the secure app and run into the aforementioned error

This is the full debug output:

https://codeshare.io/axEgPd 

I should mentioned that the memory on project settings was the layout of the example provided in the SDK which is intended for the toolchain MCUXpresso IDE (SDK_2.5.1_LPCXpresso55S69_MCUXpressoIDE):

Do you have any idea what step or mistake can I be doing? You can find the resources for the projects attached. 

Makefile (secure): https://codeshare.io/5eLVyr

Makefile (non-secure): https://codeshare.io/adlwrR

Linker Script (secure): https://codeshare.io/anMzWj

Linker Script (non-secure): https://codeshare.io/G8opjd

[raz3l]

Hi soledad‌ and brendonslade‌, thank you for the tips! On the last week or so I have been using MCUXpresso IDE V11, which solve my problems and significantly increased the stability on my development environment! Thanks!

[soledad]

Hi, 

Could you please try using MCUXpresso SDK 2.6 version? 

Older version of MCUXpresso IDE and/or SDK will have different and inferior performance when used with Trustzone examples and are therefore not recommended.

Please check the following document. 

https://community.nxp.com/community/mcuxpresso/mcuxpresso-ide/blog/2019/06/12/using-lpc55s69-sdk-tru...

Have a great day,
Sol

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[brendonslade]

Also be sure to update to MCUXpresso IDE V11. There were several improvements added to this IDE release, including special handling of linked secure/non-secure projects. If you are constructing your own make files and GDB setup this could get more difficult ...

We also just created a new class about secure/non-secure debug; materials are here:

https://community.nxp.com/docs/DOC-343688

I cant see the hands-on lab there so have attached it here.