TI CC1352R1 (Cortex M4F) BusFaults

Kernel
1

safetylok wrote on Monday, August 12, 2019:

Hi,

FreeRTOS Version 10.0.1

I’ve spent some time with the FreeRTOS M4F Port, trying to get it operational on the TI CC1352R1 device.

I’m stuck at a point in the vPortSVCHandler:

bx r14

After the above branch call the M4F vectors immediatly to a BusFault_ISR condition, with the STKERR (During Exception Stacking Error) bit set in the status registers.

I have followed the general guidance and made sure the interrupt priorities are correct. I don’t have stack or heap problems, and the task blocks residing in RAM look good. I’ve compared this also to a TI CC3220 device, and apart from the differences in addresses, there is nothign that stands out.

So I’m wondering where to from here? Does anyone have any experience with these devices, or is there any other information I can provide to help narrow down the issues?

Thanks

2

aggarg-aws wrote on Monday, August 12, 2019:

Would you please provide the register values (including MSP and PSP) before executing bx r14? Also, read 8 bytes from the memory address contained in PSP. Those bytes (in order) are:

R0, R1, R2, R3, R12, LR, PC, XPSR

The above PC value is the location the code is trying to jump. Use the disassembly window (View --> Disassembly in Code Composer Studio) to locate the source code at this location (it should be one of the FreeRTOS tasks).

Assuming that you are using Code Composer Studio, you can use View --> Registers and View --> Memory Browser to examine register and memory values respectively.

Thanks.

3

safetylok wrote on Monday, August 12, 2019:

Hi,

Overview:

  1. Basic application, no user created tasks
  2. configUSE_TICKLESS_IDLE = 0

Device:
Texas Instuments CC1352R1
FLASH: 0x00000000
RAM : 0x20000000

Memory after pxPortInitialiseStack() - Unknown Task

Address Contents Description
0x200005F8 0xA5A5A5A5 Cell
0x200005F4 0x01000000 XPSR
0x200005F0 0x000011FE PC
0x200005EC 0x0000815B prvTaskExitError / LR
0x200005E8 0xA5A5A5A5 R12
0x200005E4 0xA5A5A5A5 R3
0x200005E0 0xA5A5A5A5 R2
0x200005DC 0xA5A5A5A5 R1
0x200005D8 0x00000000 R0
0x200005D4 0xFFFFFFFD portINITIAL_EXC_RETURN
0x200005B4 0xA5A5A5A5 R11 to R4

Memory after pxPortInitialiseStack() - Timer Task

Address Contents Description
0x20000E68 0xA5A5A5A5 Cell
0x20000E64 0x01000000 XPSR
0x20000E60 0x00006506 PC
0x20000E5C 0x0000815B prvTaskExitError / LR
0x20000E58 0xA5A5A5A5 R12
0x20000E54 0xA5A5A5A5 R3
0x20000E50 0xA5A5A5A5 R2
0x20000E4C 0xA5A5A5A5 R1
0x20000E48 0x00000000 R0
0x20000E44 0xFFFFFFFD portINITIAL_EXC_RETURN
0x20000E24 0xA5A5A5A5 R11 to R4

vPortSVCHandler:

vPortSVCHandler: .asmfunc
	;/* Get the location of the current TCB. */
	ldr	r3, pxCurrentTCBConst
	ldr r1, [r3]
	ldr r0, [r1]
Register Value
R0 0x20000E24 
;/* Pop the core registers. */
	ldmia r0!, {r4-r11, r14}
	msr psp, r0
	isb
	mov r0, #0
	msr	basepri, r0
Register Value
LR 0xFFFFFFFD
xPSR 0x41000000
R0 0x00000000
R1 0x20000E78
R2 0x2000CAE4
R3 0x2000CA84
R4 0xA5A5A5A5
R5 0xA5A5A5A5
R6 0xA5A5A5A5
R7 0xA5A5A5A5
R8 0xA5A5A5A5
R9 0xA5A5A5A5
R10 0xA5A5A5A5
R11 0xA5A5A5A5
R12 0x0000A140
R13 0x20013FE0
R14 0xFFFFFFFD
MSP 0x20013FE0
PSP 0x20000E48
DSP 0x20000E48

From the ARM Manual
When LR = 0xFFFFFFFD Return to Thread mode. Exception return gets state from the process stack. Execution uses PSP after return.

If I am intrepreting this correctly, PSP should not be an 0x2000000 address, but should be pointing to FLASH, somewhere around 0x00000xxxx

This device has a FPU, and I’m wondering if somehow this can affect the return stack.?

Any thoughts?
Thanks.

4

richard_damon wrote on Monday, August 12, 2019:

PSP and DSP are the stack pointers for the different modes of the processor. LR = 0xFFFFFFFD means that the return will pop the saved registers (including save PC) from the PSP stack instead of the DSP stack. In that stack frame will be the address to return to.

5

aggarg-aws wrote on Monday, August 12, 2019:

Thank you for the detailed reply.

Your PSP is correct and points to the location in RAM from where saved registers will be popped upon returning from exception. Looking at the content of memory you shared, the address it should return to is 0x00006506 (which as you mentioned is Timer task). FPU should not be a problem as M4F handles saving and restoring FPU registers. You mentioned that it crashes when you step over the assembly instruction bx r14, right?

At this point, everything seems okay to me. Would you be able to share your project so that I can take a closer look? Are you using a custom hardware or is it a development board?

Thanks.