Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
wangchenyu01
Level 1
Level 1
10 sign-ins 5 replies posted 5 sign-ins

hi 

my sw get into trap and then get into Shutdown.

this issue happen twice :

after i track the register and trap type ,

first time: i found the DSTR.LBE was setted and the deadd is F001D200

first time: i found the DSTR.LBE was setted and the deadd is F001D204

 could you please check which operation will result in this trap?

0 Likes
1 Solution
Nambi
Moderator
Moderator
Moderator
500 replies posted 50 likes received 5 likes given

Hi,

In general, you can refer to the procedure in https://www.infineon.com/dgdl/Infineon-AURIX_CPU_Trap_Recognition_1_KIT_TC397_TFT-Training-v01_00-EN... to decode the trap information.

Here the addresses 0xF001D200 and 0xF001D204 fall in the memory map under "F001 D000H - F001 DFFF Gigabit Ethernet Controller MAC Control (GETH0)". Based on the call stack, you can check the assembly instructions for the load instruction access leading to the issue and if these addresses are involved.

Also, based on "Table 502 Register Overview - GETH (ascending Offset Address)"(AURIXTC3XX_um_part2_v2.0.pdf), these correspond to the registers MAC_MDIO_ADDRESS and MAC_MDIO_DATA. Could you confirm from the call stack if these register accesses lead to the trap?

Best Regards.

View solution in original post

0 Likes
2 Replies
wangchenyu01
Level 1
Level 1
10 sign-ins 5 replies posted 5 sign-ins

this product is base on TC397

0 Likes
Nambi
Moderator
Moderator
Moderator
500 replies posted 50 likes received 5 likes given

Hi,

In general, you can refer to the procedure in https://www.infineon.com/dgdl/Infineon-AURIX_CPU_Trap_Recognition_1_KIT_TC397_TFT-Training-v01_00-EN... to decode the trap information.

Here the addresses 0xF001D200 and 0xF001D204 fall in the memory map under "F001 D000H - F001 DFFF Gigabit Ethernet Controller MAC Control (GETH0)". Based on the call stack, you can check the assembly instructions for the load instruction access leading to the issue and if these addresses are involved.

Also, based on "Table 502 Register Overview - GETH (ascending Offset Address)"(AURIXTC3XX_um_part2_v2.0.pdf), these correspond to the registers MAC_MDIO_ADDRESS and MAC_MDIO_DATA. Could you confirm from the call stack if these register accesses lead to the trap?

Best Regards.

0 Likes