cancel
Showing results for 
Search instead for 
Did you mean: 

stm32mp15 JTAG on m4 core with yocto5: optee permission failure

Morandg
Associate II

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

1 ACCEPTED SOLUTION

Accepted Solutions
Morandg
Associate II

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

 

View solution in original post

3 REPLIES 3
Olivier GALLIEN
ST Employee

@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
Associate II

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
Associate II

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