Aurix TC29x Trap on flash command

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

cross mob
Not applicable
Hello,

we are using the TriBoard for the TC297 B. We are currently using 2 cores (core 0 and core1), running two separate applications there:
- core0 (bootloader application), binary is located at pflash 0, app is programmatically using pflash 2 for additional code, coming via communication
- core1 (special application) binary is located at pflash 1, app programmatically using pflash 3 for additional code, coming via communication

Both have the same code for the low-level flashdriver (only difference is Flash-Startaddress, of course).
When accessing PFlash 2 everything is fine. Can be erased, flashed etc.
When accessing PFlash 3 i constantly get a TRAP 4 TIN 3 (DAE Trap - Store Bus Error) for the Address 0xAF005554 (the command address for talking to the flash).
This access is done from core1. So i tried to let core0 access this pflash3, but there is the same problem.
We do not use any protection measures, and i doublechecked all the other flash registers etc. So it does not look like permission problem.


The strange thing: if i set a breakpoint with my UDE Debugger right at the position where this "problematic" command is made,
and step through all this commanding, everything is fine. Erasing, loadpage, writepage works fine.

So my question is: does anybody know this effect, or has an idea on how to solve such a problem?

Thank you in advance.

BR,

SR
0 Likes
2 Replies
User17571
Level 1
Level 1
Have you solved the problem with FLASH? I have the same problem
0 Likes
MoD
Employee
Employee
50 likes received 500 replies posted 100 solutions authored
A PFlash can be only accessed if there is no command pending (e.g. erasing or programming). If a command is pending then the corresponding BUSY bit of the PFlash will be set and you must wait until hw clears this bit.
Please note that the DAE trap is asynchron, this means when you return from this trap then you will not see the faulting instruction. The problematic instruction can be located earlier in your code.
I am assuming that the PFlash 3 is not ready to accept commands therefore you get the trap. Maybe you check the BUSY bit before execution of command. Make sure t´hat there is no access from other CPU.
0 Likes