Not applicable
May 13, 2015
07:11 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May 13, 2015
07:11 AM
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
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
2 Replies
Aug 08, 2019
07:04 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 08, 2019
07:04 AM
Have you solved the problem with FLASH? I have the same problem
Aug 14, 2019
02:16 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 14, 2019
02:16 AM
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.
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.