Tool/software:
Before explaining the issue I am experiencing:
- We have a bootloader and application running on the MCU
- We previously used the FEE to pass information between the bootlaoder and application. I have recently switched to persistent RAM across resets to pass information between the bootloader and app (shared RAM memory)
- The shared memory is also used to store application data so it can be restored if a watchdog or software reset occurs. This feature seems to be causing issues (at least that's when the problems started)
- The system is using SAFERTOS in the application only
- I modified the startup sequence to make sure I don't execute _memInit_ for wattchdog and software resets.
- The watchdog is enabled in both the bootloader and application. To prevent the watchdog from resetting the MCU while initializing the application, we perform a SW before jumping to the app. This means that a watchdog reset in the application is shortly followed by a second reset (SW) right before jumping to the application.
- I modified the exception vector in the bootloader so we can execute the SVC handler in the application (the bootloader does not use the exception vector besides the reset handler)
What happens is that the system generates a data fault when starting the SAFERTOS scheduler. And since the watchdog is started at this point, the watchdog resets the system and it keeps looping infinitely.
Here is what I have found through my investigation
- A power cycle seems to temporarily fix the issue. It works for a few reboots, but then starts again and keeps happening after every boot. We are still in development so a J-Link probe is attached to the board (I have not paid attention if we were connected to the target when the issue happened). The issue happens after a multiple connections/disconnections/reprogramming.
- Calling _memInit_ fixes the issue (until the next software/watchdog reset). This is not a suitable solution because we need to preserve the data.
- If I disable the code that access the application data before starting the scheduler, I don't get the data abort anymore. It seems accessing the shared memory causes the issue.
I have found this thread which seems to experience the same issue, but I didn't find anything that fixed my issue.
https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/693755/tms570lc4357-data-abort-after-software--or-watchdog-triggered-reset
I have attached some files that might help. Let me know if you need more information to resolve this issue.
Thank you in advance for your help.
Michal
- /cfs-file/__key/communityserver-discussions-components-files/908/4760.bl_5F00_link.txt bootloader linker file
- /cfs-file/__key/communityserver-discussions-components-files/908/8484.HL_5F00_sys_5F00_startup.c app startup file
- /cfs-file/__key/communityserver-discussions-components-files/908/link.txt app linker file
- /cfs-file/__key/communityserver-discussions-components-files/908/HL_5F00_sys_5F00_intvecs_5F00_bl.asm exception vector (the modified version in the bootloader)
- /cfs-file/__key/communityserver-discussions-components-files/908/Registers-after-abort.txt a copy of the register values after the data abort occurred
- /cfs-file/__key/communityserver-discussions-components-files/908/ram_5F00_before_5F00_abort.txt the contents of the RAM before the abort which shows the contents of the stacks
- /cfs-file/__key/communityserver-discussions-components-files/908/HL_5F00_sys_5F00_core_5F00_bl.asm assembly code with special function to preserve memory at bootup
- /cfs-file/__key/communityserver-discussions-components-files/908/HL_5F00_sys_5F00_startup_5F00_bl.c startup bootlaoder file with modified sequence
