Debugging non-secure code under GNU/Eclipse does not work

[0xd35a2ee]

Hello there,

debugging non-secure code with GNU/Eclipse nad OpenOCD under Linux does not seem to work. Building the code is not an issue, but flashing it on the board fails (simply hangs) with the following error message:

Info : Nuvoton NuMicro: Sector Erase ... (131200 to 131205)
Info : Nuvoton NuMicro: Flash Write ...
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1574). Workaround: increase "set remotetimeout" in GDB

On the other hand, building and debugging secure code works like a charm.

Info : 0x00300000: 0x00000000
Info : 0x00300000: 0xffffffff
Info : 0x00300004: 0xffffffff
Info : 0x00300008: 0xffffffff
Info : 0x0030000c: 0xffffffff
Info : 0x00200800: 0x00000000
Info : 0x00210800: 0x00000000
Info : 0x00200800: 0x00040000
Info : 0x00200804: 0x0000005a
Info : 0x00210804: 0x0000005a
auto erase enabled
Info : Nuvoton NuMicro: Sector Erase ... (0 to 6)
Info : Nuvoton NuMicro: Flash Write ...
Info : Have written 28%
Info : Have written 57%
Info : Have written 85%
Info : Have written 100%
Info : Nuvoton NuMicro: Sector Erase ... (126 to 126)
Info : Nuvoton NuMicro: Flash Write ...
Info : Have written 100%
wrote 16384 bytes Secure/Debug/Secure.hex in 4.195044s (3.814 KiB/s)
NuMicro.cpu: target state: halted
target halted due to debug-request, current mode: Thread

The code that was used for this demonstration is the TrustZone template code, which is generated by GNU/Eclipse automatically after creating a secure and non-secure project respectively. The configurations steps were followed as described in the official GNU/Eclipse user manual. The only difference is that from the secure zone I explicitly set NCSBA = 0x040000 and SCRLOCK = 0x5A and ARLOCK = 0x5A because by default NCSBA = 0x080000 would be written, which does not correspond to the default partitioning #define FMC_SECURE_ROM_SIZE 0x40000. Such a mismatch causes the device to hang in an infinite loop.

[0xd35a2ee]

After some investigation I found that if I lock the secure flash memory region, using for example SCRLOCK = 0x11, I am able to debug non-secure code as expected. However, now debugging secure code is not possible because of the lock. The chip must be totally erased (e.g. using the windows ICP tool) to enable secure debugging again. Erasing the chip through GNU/Eclipse by checking the Erase chip box in the debug configurations does not work.

How can simultaneous debugging of secure and non-secure code be achieved, without the need of additional locks/erasures?

[wschang0]

1. Open M2351_NS Project

2. checking the erase chip box and Non Secure box in the debug configurations

3. Apply settings and enter debug mode, the chip will be totally erased

=========================================================================================== The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.

[wschang0]

The wrong NSCBA setting will cause the infinite loop. It is necessary to avoid wrong TrustZone partition. you should full erase the whole chip to fix it.

From: 0xd35a2ee [mailto:notifications@github.com] Sent: Friday, October 12, 2018 8:02 PM To: OpenNuvoton/M2351BSP Cc: Subscribed Subject: [OpenNuvoton/M2351BSP] Debugging non-secure code under GNU/Eclipse does not work (#2)

Hello there,

debugging non-secure code with GNU/Eclipse does not seem to work. Building the code is not an issue, but flashing it on the board fails (simply hangs) with the following error message:

Info : Nuvoton NuMicro: Sector Erase ... (131200 to 131205)

Info : Nuvoton NuMicro: Flash Write ...

Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1574). Workaround: increase "set remotetimeout" in GDB

On the other hand, building and debugging secure code works like a charm.

Info : 0x00300000: 0x00000000

Info : 0x00300000: 0xffffffff

Info : 0x00300004: 0xffffffff

Info : 0x00300008: 0xffffffff

Info : 0x0030000c: 0xffffffff

Info : 0x00200800: 0x00000000

Info : 0x00210800: 0x00000000

Info : 0x00200800: 0x00040000

Info : 0x00200804: 0x0000005a

Info : 0x00210804: 0x0000005a

auto erase enabled

Info : Nuvoton NuMicro: Sector Erase ... (0 to 6)

Info : Nuvoton NuMicro: Flash Write ...

Info : Have written 28%

Info : Have written 57%

Info : Have written 85%

Info : Have written 100%

Info : Nuvoton NuMicro: Sector Erase ... (126 to 126)

Info : Nuvoton NuMicro: Flash Write ...

Info : Have written 100%

wrote 16384 bytes Secure/Debug/Secure.hex in 4.195044s (3.814 KiB/s)

NuMicro.cpu: target state: halted

target halted due to debug-request, current mode: Thread

The code that was used for this demonstration is the TrustZone template code, which is generated by GNU/Eclipse automatically after creating a secure and non-secure project respectively. The configurations steps were followed as described in the official GNU/Eclipse user manual. The only difference is that from the secure zone I explicitly set NCSBA = 0x040000 and SCRLOCK = 0x5A and ARLOCK = 0x5A because by default NCSBA = 0x080000 would be written, which does not correspond to the default partitioning #define FMC_SECURE_ROM_SIZE 0x40000. Such a mismatch causes the device to hang in an infinite loophttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_OpenNuvoton_M2351BSP_blob_master_SampleCode_TrustZone_Template_partition-5FM2351.h-23L99&d=DwMCaQ&c=ue8mO8zgC4VZ4q_aNVKt8G9MC01UFDmisvMR1k-EoDM&r=aH6l7Kw2v9MTu3F0oJ3Ab6AQ_svbvBfhszKwCjHTnIo&m=cfIGlT5B1cOlcqRbE21UxMCJ3CEsiivibZZ734Lj3rI&s=kg0Ys5kMkafs29O-WGB1lU5gfXd7d87bo1bQiMpSGsY&e=.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_OpenNuvoton_M2351BSP_issues_2&d=DwMCaQ&c=ue8mO8zgC4VZ4q_aNVKt8G9MC01UFDmisvMR1k-EoDM&r=aH6l7Kw2v9MTu3F0oJ3Ab6AQ_svbvBfhszKwCjHTnIo&m=cfIGlT5B1cOlcqRbE21UxMCJ3CEsiivibZZ734Lj3rI&s=Y4CWr364MJxG4B8SxES5WW3aELTHFcKi_S1Asph264w&e=, or mute the threadhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ARm7j64vxv-2D7SoS9fr-2Dyd85CsBO1rm47ks5ukISzgaJpZM4XZV2w&d=DwMCaQ&c=ue8mO8zgC4VZ4q_aNVKt8G9MC01UFDmisvMR1k-EoDM&r=aH6l7Kw2v9MTu3F0oJ3Ab6AQ_svbvBfhszKwCjHTnIo&m=cfIGlT5B1cOlcqRbE21UxMCJ3CEsiivibZZ734Lj3rI&s=MSnwy1babvVEg8p2gesrcmTd5zuVbmH5dC08LKt0MVE&e=.

=========================================================================================== The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.

[0xd35a2ee]

Thanks for your answer @wschang0. Follow up after trying what you have described.

1. How should the debugging normally work? Is the concept that the user can (1) simultaneously debug secure and non-secure code by jumping from one zone to the other or (2) is it intended that the user debugs secure and non-secure code separately from one another? You suggested erasing the chip while debugging non-secure code. This leads to me to think that a separate debugging is intended.

2. I tried what you have suggested (marking the chip erase and non-secure boxes in the debug configuration). This sadly does not resolve the problem.

I left the flasher to run for more than 2 minutes and it actually managed to flash the non-secure code in flash memory with very low speed.

Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1576). Workaround: increase "set remotetimeout" in GDB
Error: timed out while waiting for target halted
Error: Error executing NuMicro Flash programming algorithm
wrote 11260 bytes from file /home/user/project/NonsecureWorld/Debug/NonsecureWorld.hex in 101.134171s (0.109 KiB/s)

However, the chip did not seem to be executing the correct code (no LEDs were blinking). I paused the debugger and saw that it executes code from the address 0xeffffffe, which is invalid. Hence I suspect that there is a problem with the memory partitioning and I cannot find it. I attach the linker scripts, compiled hex files and the memory partition header file.

The secure code debug configuration:

The non-secure debug configuration:

secure-linker-script.ld.txt

non-secure-linker-script.ld.txt

partition_M2351.h.txt

SecureWorld.hex.txt

NonsecureWorld.hex.txt

Where is the problem?

[wschang0]

You may try Keil Nuvoton edition first to see what is normal in working with TrustZone. The tool is free and could be download from: https://m2351.nuvoton.com/resource/

From: 0xd35a2ee [mailto:notifications@github.com] Sent: Tuesday, October 16, 2018 4:40 PM To: OpenNuvoton/M2351BSP Cc: MS20 WSChang0; Mention Subject: Re: [OpenNuvoton/M2351BSP] Debugging non-secure code under GNU/Eclipse does not work (#2)

Thanks for your answer @wschang0https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_wschang0&d=DwMFaQ&c=ue8mO8zgC4VZ4q_aNVKt8G9MC01UFDmisvMR1k-EoDM&r=aH6l7Kw2v9MTu3F0oJ3Ab6AQ_svbvBfhszKwCjHTnIo&m=MCVWj-oDZTeaZ0EpVzBQRrj0U5_AwfPl1xVOzbb21IQ&s=EvANf5XiCynnbu32noM4i99mDOQ0-fRFcs27SNPF0Qk&e=. Follow up after trying what you have described.

1. How should the debugging normally work? Is the concept that the user can (1) simultaneously debug secure and non-secure code by jumping from one zone to the other or (2) is it intended that the user debugs secure and non-secure code separately from one another? You suggested erasing the chip while debugging non-secure code. This leads to me to think that a separate debugging is intended.

2. I tried what you have suggested (marking the chip erase and non-secure boxes in the debug configuration). This sadly does not resolve the problem.

I left the flasher to run for more than 2 minutes and it actually managed to flash the non-secure code in flash memory with very low speed.

Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1576). Workaround: increase "set remotetimeout" in GDB

Error: timed out while waiting for target halted

Error: Error executing NuMicro Flash programming algorithm

wrote 11260 bytes from file /home/user/project/NonsecureWorld/Debug/NonsecureWorld.hex in 101.134171s (0.109 KiB/s)

However, the chip did not seem to be executing the correct code (no LEDs were blinking). I paused the debugger and saw that it executes code from the address 0xeffffffe, which is invalid. Hence I suspect that there is a problem with the memory partitioning and I cannot find it. I attach the linker scripts, compiled hex files and the memory partition header file.

The secure code debug configuration: [Image removed by sender. secure-world-debug-config]https://urldefense.proofpoint.com/v2/url?u=https-3A__user-2Dimages.githubusercontent.com_43346167_47003219-2D0efe1200-2Dd12f-2D11e8-2D9cb8-2De50a07850fb1.png&d=DwMFaQ&c=ue8mO8zgC4VZ4q_aNVKt8G9MC01UFDmisvMR1k-EoDM&r=aH6l7Kw2v9MTu3F0oJ3Ab6AQ_svbvBfhszKwCjHTnIo&m=MCVWj-oDZTeaZ0EpVzBQRrj0U5_AwfPl1xVOzbb21IQ&s=F6MGvqHR-ZW8oY6svtQ4OpmxjbaaOpKp8StGUBt4-hs&e=

The non-secure debug configuration: [Image removed by sender. nonsecure-world-debug-config]https://urldefense.proofpoint.com/v2/url?u=https-3A__user-2Dimages.githubusercontent.com_43346167_47003218-2D0efe1200-2Dd12f-2D11e8-2D9e8c-2Ded122811d5f4.png&d=DwMFaQ&c=ue8mO8zgC4VZ4q_aNVKt8G9MC01UFDmisvMR1k-EoDM&r=aH6l7Kw2v9MTu3F0oJ3Ab6AQ_svbvBfhszKwCjHTnIo&m=MCVWj-oDZTeaZ0EpVzBQRrj0U5_AwfPl1xVOzbb21IQ&s=LuFQR3qRuyfwUrA-9Y3FqiKxwCEm21r6tkVBj1YLo7s&e=

secure-linker-script.ld.txthttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_OpenNuvoton_M2351BSP_files_2482131_secure-2Dlinker-2Dscript.ld.txt&d=DwMFaQ&c=ue8mO8zgC4VZ4q_aNVKt8G9MC01UFDmisvMR1k-EoDM&r=aH6l7Kw2v9MTu3F0oJ3Ab6AQ_svbvBfhszKwCjHTnIo&m=MCVWj-oDZTeaZ0EpVzBQRrj0U5_AwfPl1xVOzbb21IQ&s=bxgKTiYjnU9suPbHrhgjMj-wucWMxK8xgglQtc_EHgc&e=

non-secure-linker-script.ld.txthttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_OpenNuvoton_M2351BSP_files_2482136_non-2Dsecure-2Dlinker-2Dscript.ld.txt&d=DwMFaQ&c=ue8mO8zgC4VZ4q_aNVKt8G9MC01UFDmisvMR1k-EoDM&r=aH6l7Kw2v9MTu3F0oJ3Ab6AQ_svbvBfhszKwCjHTnIo&m=MCVWj-oDZTeaZ0EpVzBQRrj0U5_AwfPl1xVOzbb21IQ&s=IDlJhKgUnBtNKBunM_kk_chy2GxJvXiTUBatKfiKVi8&e=

partition_M2351.h.txthttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_OpenNuvoton_M2351BSP_files_2482144_partition-5FM2351.h.txt&d=DwMFaQ&c=ue8mO8zgC4VZ4q_aNVKt8G9MC01UFDmisvMR1k-EoDM&r=aH6l7Kw2v9MTu3F0oJ3Ab6AQ_svbvBfhszKwCjHTnIo&m=MCVWj-oDZTeaZ0EpVzBQRrj0U5_AwfPl1xVOzbb21IQ&s=ufu3q-6FfVdgZfV_MzChiABG_kL7-ymo46UGYHCMP7A&e=

SecureWorld.hex.txthttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_OpenNuvoton_M2351BSP_files_2482149_SecureWorld.hex.txt&d=DwMFaQ&c=ue8mO8zgC4VZ4q_aNVKt8G9MC01UFDmisvMR1k-EoDM&r=aH6l7Kw2v9MTu3F0oJ3Ab6AQ_svbvBfhszKwCjHTnIo&m=MCVWj-oDZTeaZ0EpVzBQRrj0U5_AwfPl1xVOzbb21IQ&s=PQIrifyIVDtp6n0eVqgdIKEPS9xhbXYe-XzlaPhTcgM&e=

NonsecureWorld.hex.txthttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_OpenNuvoton_M2351BSP_files_2482151_NonsecureWorld.hex.txt&d=DwMFaQ&c=ue8mO8zgC4VZ4q_aNVKt8G9MC01UFDmisvMR1k-EoDM&r=aH6l7Kw2v9MTu3F0oJ3Ab6AQ_svbvBfhszKwCjHTnIo&m=MCVWj-oDZTeaZ0EpVzBQRrj0U5_AwfPl1xVOzbb21IQ&s=wArlK4jTfNsvAU-KE0Y_XFI_mw08pXryYVnANmhL4GA&e=

Where is the problem?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_OpenNuvoton_M2351BSP_issues_2-23issuecomment-2D430152014&d=DwMFaQ&c=ue8mO8zgC4VZ4q_aNVKt8G9MC01UFDmisvMR1k-EoDM&r=aH6l7Kw2v9MTu3F0oJ3Ab6AQ_svbvBfhszKwCjHTnIo&m=MCVWj-oDZTeaZ0EpVzBQRrj0U5_AwfPl1xVOzbb21IQ&s=mCWng6gXAffaK9WJ7CigaR3RrtFerzWpEX08UrdrKiU&e=, or mute the threadhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ARm7jzIvAZB7-5FE2neE304BQYEU03r2n4ks5ulZt7gaJpZM4XZV2w&d=DwMFaQ&c=ue8mO8zgC4VZ4q_aNVKt8G9MC01UFDmisvMR1k-EoDM&r=aH6l7Kw2v9MTu3F0oJ3Ab6AQ_svbvBfhszKwCjHTnIo&m=MCVWj-oDZTeaZ0EpVzBQRrj0U5_AwfPl1xVOzbb21IQ&s=gqtgA8jK7WPHqNq6aICYpju7T93tuivdpWsNhUQenbU&e=.

=========================================================================================== The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.

[0xd35a2ee]

Since the main problem was neglected and I found a solution on my own, I will post it here with the hope that it will be helpful for others:

TL;DR. Deselect the non-secure option in the debug configurations of the non-secure codebase.

A more detailed explanation: Step 0. Reinstall the Nuvoton version of GNU/Eclipse. In my case this was needed because the global settings were polluted after numerous different attempts to resolve the issue.

Step 1. Create a new secure project. Make sure you give the correct flash/SRAM size, which will be used in partition_M2351.h. Be default this is 32KB SRAM and 256KB flash.

Step 2. Build the secure project and create a new debug profile. Besides everything which is explained in the official GNU/Eclipse manual from Nuvoton, the following settings will work with the default configurations:

Step 3. Create a new non-secure project. Make sure you give the correct flash/SRAM size, which you have already specified in partition_M2351.h that is part of the secure codebase. By default the non-secure world will be using 64KB SRAM and 256KB flash. Leave the library path empty.

Step 4. For the non-secure project add the path to the secure library (this is normally SecureProjectName/Debug/Library) from the Project Settings > C/C++ > Build > GNU Linker Libraries. After that build the non-secure project.

Step 5. Create a new debug configuration for the non-secure project. The configurations should be as on the picture below. Do not check the non-secure checkbox because this creates problems as described in the above comments.