Part Number: MCU-PLUS-SDK-AM263X
Other Parts Discussed in Thread: SYSCONFIG
I am developing a project on the AM263x Control Card.
The project is based on the SDLK empty example project:
mcu_plus_sdk_am263x_09_01_00_41\examples\empty\am263x-cc\system_freertos.
I modified the code in each core to execute a:
while(1){ vTaskDelay(100)}
… loop instead of immediately exiting as was done in the SDK.
I also merged in some of the SDK example:
mcspi_loopback_dma_am263x-cc_r5fss0-0_freertos_ti-arm-clang
… onto core r5fss0-0.
I also made a few other small modifications in preparation for merging in other SDK examples.
With this project running with Debug build configuration I get the following symptoms:
- All cores successfully load and halt at main()
- If r5fss0-0 runs the SPI DMA loopback test, it will run indefinably; I modified it to loop forever.
- As soon as I call vTaskStartScheduler() in r5fss0-1 the SPI DMA loopback test executed by r5fss0-0 stops as seen by probing SPI with a logic analyzer. If I halt r5fss0-0, I see it is in the data abort loop.
I want to analyze the registers to find the root cause. However, I am confused by what I see.
From what I see here:
… ,which I assume applies to the Cortex R cores of AM263x, I expect that:
R14 Register: The R14 register is used to find the actual instruction or function call that caused the synchronous abort. The actual address of the instruction that triggered the Exception will be R14 - x, where “x” depends on the type of exception.
However, from the registers view in as seen in my screen capture posted below, I think the register values indicate that the instruction that triggered the abort is in the .vectors segment (at 0x00000001).
Is my analysis flawed?
… or is there a scenario where the instruction triggering the abort is in the .vectors segment?
Can anyone suggest the likely root cause for the abort in how I am building my project from SDK examples by merging code into the empty project, and modifying the project through SysConfig in CCS?
