- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
this product is base on TC397
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.