- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I am going to write a bootloader project, the project has STM Interrupt function and pflash read and write functions. Before operating Pflash, call IfxCpu_disableInterrupts, after the operation, call IfxCpu_restoreInterrupts; then STM Interrupt cannot enter ISR again, and CPU0 enters the trap (IfxCpu_Trap_contextManagementError) state.
Trap state:
Pflash Code:
Pflash Code run PSPRAM.
Solved! Go to Solution.
- Labels:
-
AURIX
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I found a bug. Because the operation pflsh is in CPU2, CPU0 still has code to execute, and then it enters this trap state, and the Pflash-related operations are moved into CPU0, and this trap is no longer generated.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Are you sure that writeFlash completes before it returns (FLASH0_FSR.BUSY=0)? This type of problem is often due to PFLASH still being busy, which leads to a bus error, which causes a fetch from BTV (pointing to PFLASH), which causes another bus error, etc., etc.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
I sure that eraseFlash and writeFlash completes defore it returns(FLASH0_FSR.BUSY=0).
There is my code.
and i copy them to PSPRAM.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Isn't the writePFLASH function still in PFLASH though? That means that in between programming steps that are writing/erasing PFLASH, the code is still fetching instructions from PFLASH, which will result in a bus error.
Can you move writePFLASH into PSPR too?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi:
I don't understand why the writePflash function is in Pflash, because I copied it to PSPRAM using memcpy.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I may have missed it, but I didn't see in the snippets you've provided that writePFLASH() was in PSPR.
If you step through it in a debugger, are you certain that the program counter is actually in PSPR, and not in PFLASH? Sometimes the linker directives aren't quite right, and although the code is copied to PSPR, it's still being executed from PFLASH.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I found a bug. Because the operation pflsh is in CPU2, CPU0 still has code to execute, and then it enters this trap state, and the Pflash-related operations are moved into CPU0, and this trap is no longer generated.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nice work figuring that out. Developers also often miss the fact that other bus masters (CPUs, DMA, Ethernet, HSM) may be accessing PFLASH in the background.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes,thanks for your reply.