Skip to main content
Morandg
Associate II
August 19, 2024
Solved

stm32mp15 JTAG on m4 core with yocto5: optee permission failure

  • August 19, 2024
  • 3 replies
  • 1326 views

Hi everyone,

I'm working on a custom board based on STM32MP157F-DK2. I am running Yocto 5.0.3 (scarthgap) with trusted boot (not signed).

I could build the Zephyr (3.7.0) rpmsg sample that worked out of the box:

https://docs.zephyrproject.org/latest/samples/subsys/ipc/openamp_rsc_table/README.html

Now the issue is when I tried to debug the m4 core with a JTAG, the board crashes, here is what I see on the Linux console:

 

E/TC:0 tzc_it_handler:79 TZC permission failure
E/TC:0 dump_fail_filter:420 Permission violation on filter 0
E/TC:0 dump_fail_filter:425 Violation @0xdeadbef0, non-secure privileged read, AXI ID 1
E/TC:0 Panic at core/arch/arm/plat-stm32mp1/plat_tzc400.c:84 <tzc_it_handler>
E/TC:0 TEE load address @ 0xde000000
E/TC:0 Call stack:
E/TC:0 0xde002961
E/TC:0 0xde017cd1
E/TC:0 0xde0046d7
E/TC:0 0xde0179f7
E/TC:0 0xde023679
E/TC:0 0xde000348

 

I started JLinkGDBServer with those parameters:

 

JLinkGDBServer -port 2331 -s -device STM32MP15XX_M4 -endian little -speed 4000 -vd -nohalt -noreset

 

I can see however that the debugger has a lot of errors while reading some CPU registers or memory area:

 

Read register 'r0' (4 bytes) from hardware: 0xEFBEADDE
ERROR: Cannot read register 1 (R1) while CPU is running
// ...
Read register 'pc' (4 bytes) from hardware: 0xEFBEADDE
ERROR: Cannot read register 16 (XPSR) while CPU is running
Read register 'xpsr' (4 bytes) from hardware: 0xEFBEADDE
Read 4 bytes @ address 0xDEADBEEE (Data = 0x00002300)
Downloading 664 bytes @ address 0x00000000 - Verified OK
Downloading 16136 bytes @ address 0x00000298 - Verify failed (expected 0x61 read 0xFFFFFFF0 @ 0x00002299)
Downloading 11412 bytes @ address 0x000041A0 - Verify failed (expected 0x30 read 0x00 @ 0x000061A0)
Downloading 8 bytes @ address 0x00006E34 - Verify failed (expected 0xFFFFFF94 read 0xFFFFFFAA @ 0x00006E34)
Downloading 176 bytes @ address 0x00006E3C - Verified OK
Downloading 320 bytes @ address 0x00006EEC - Verified OK
Downloading 1200 bytes @ address 0x0000702C - Verified OK
Downloading 1384 bytes @ address 0x000074DC - Verify failed (expected 0x45 read 0xFFFFFFAA @ 0x000074DC)
Downloading 136 bytes @ address 0x00007A44 - Verify failed (expected 0x00 read 0xFFFFFFAA @ 0x00007A44)
// ...
ERROR: Cannot read register 15 (R15) while CPU is running
Writing register 'pc' = 0x000011D4
Writing register 'xpsr' = 0xDFADBEEF
Starting target CPU...

 

Is there something that I'm missing in optee/ATF to allow JTAG debugging? Any pointers on the fine wiki?

Thanks and all the best!

Guy

Best answer by Morandg

Some update on this issue:

I could debug my zephyr application using a STLINK-V3:

https://www.st.com/en/development-tools/stlink-v3set.html

As documented on the Zephyr documentation, with ``west attach`` I could  debug as usual (set some break points, print the call stack, print variables values, ...)

https://docs.zephyrproject.org/latest/boards/st/stm32mp157c_dk2/doc/stm32mp157_dk2.html#debugging

 

3 replies

Olivier GALLIEN
Technical Moderator
August 23, 2024

@Morandg 

You setup looks quite different from ST standard delivery. 

Scarthgap instead of Mikledore, JLinkGDBServer while CubeIDE only support STLink-OpenOCD.

Could you maybe further detail your setup and past experience with STM32MPU products? 

Thanks 

Olivier 

 

Olivier GALLIEN In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
Morandg
MorandgAuthor
Associate II
August 27, 2024

Thanks @Olivier GALLIEN for your reply!

We use scarthgap because we want to deliver an LTS BSP for our customers. But the core components are the same as yours in mickledore, that means:

* TFA 2.8
* optee 3.19
* u-boot 2022.10
* kernel 6.1

It was working on our custom kirkstone BSP without optee, using JLink and CubeIDE

Morandg
MorandgAuthorBest answer
Associate II
September 2, 2024

Some update on this issue:

I could debug my zephyr application using a STLINK-V3:

https://www.st.com/en/development-tools/stlink-v3set.html

As documented on the Zephyr documentation, with ``west attach`` I could  debug as usual (set some break points, print the call stack, print variables values, ...)

https://docs.zephyrproject.org/latest/boards/st/stm32mp157c_dk2/doc/stm32mp157_dk2.html#debugging