• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 52 subscribers
  • Views 2114 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

BSC_Initalize hangs on CC256x with FreeRTOS

Jitesh Shah
Prodigy 60 points
Other Parts Discussed in Thread: CC2564

Hi,

I am using STM32F4 Discovery board (STM32F407VG processor). I am trying the SPPLEDemo for FreeRTOS on this board. I made all the right connections between the Discovery board and the CC2564 evaluation module. The NoOS version works fine and gives me the expected output on UART.

OpenStack().
Bluetooth Stack ID: 1
LOW ENERGY Support initialized.
Device Chipset: 4.1
BTPS Version : 4.0.2.1
Project Type : 6
FW Version : 7.26
App Name : SPPLEDemo
App Version : 0.5
LOCAL BD_ADDR: 0x78A5046A2D72
GAP_LE_Advertising_Enable success.

I switched over to the FreeRTOS project and made the changes suggested by this document "Enable STM32 Discovery Eval" for the FreeRTOS version (Changing HSE clock to 8000000, Changing processor, changing UART config, using non-DMA UART file). I loaded the project on the discovery board and it does not work. The execution goes to HardFault handler from inside BSC_Initialize(). I cannot look inside the BSC_Initialize() function because its code is not open. 

Has someone gotten this project to work before? How do I go about debugging this?

BFAR register is: 0xA12000EC

CFSR register is: 0x00008200

I above combo points to some stack error. Already tried doubling the stack size to no avail.

Thanks,

Jitesh 

  • 0
    TI__Guru* 85400 points
    Hi Jitesh,

    Have you made the suggested changes to the "Bluetopia/hcitrans/HCITRCFG.h" file?

    Regards,
    Gigi Joseph.
  • 0 in reply to Joseph Gigi
    Prodigy 60 points

    Hi Joseph,

    Yes I have. This is how my UART configuration looks like after the changes:

    #define HCITR_UART               3

#define HCITR_TXD_PORT           D
#define HCITR_TXD_PIN            8

#define HCITR_RXD_PORT           D
#define HCITR_RXD_PIN            9

#define HCITR_RTS_PORT           B //D
#define HCITR_RTS_PIN            14 //12

#define HCITR_CTS_PORT           D
#define HCITR_CTS_PIN            11

#define HCITR_RESET_PORT         E
#define HCITR_RESET_PIN          14

    Note that I changed the RTS port. B14 was the correct one, whereas the document suggested D12. SUPPORT_TRANSPORT_SUSPEND is enabled and all other macros disabled (SOFTWARE_RTS_CTS and CTR_IrqHandler)

    Thanks,

    Jitesh

  • 0 in reply to Jitesh Shah
    Prodigy 60 points

    Still stuck here.

    More information:

    HardFault happens in the following function: xPortPendSVHandler()

    Stack trace

    looks like this ->

    HardFault_Handler()

    PendSV_Handler()

    vPortYield()

    prvProcessTimerOrBlockTask()

    Code around the crash:

    __asm void xPortPendSVHandler( void )
{
	extern uxCriticalNesting;
	extern pxCurrentTCB;
	extern vTaskSwitchContext;

	PRESERVE8

	mrs r0, psp

	ldr	r3, =pxCurrentTCB		/* Get the location of the current TCB. */
	ldr	r2, [r3]

	stmdb r0!, {r4-r11}			/* Save the remaining registers. */
	str r0, [r2]				/* Save the new top of stack into the first member of the TCB. */

	stmdb sp!, {r3, r14}
	mov r0, #configMAX_SYSCALL_INTERRUPT_PRIORITY
	msr basepri, r0
	bl vTaskSwitchContext
	mov r0, #0
	msr basepri, r0
	ldmia sp!, {r3, r14}

	ldr r1, [r3]
	ldr r0, [r1]  <-- This is the crash instruction
    /* The first item in pxCurrentTCB is the task top of stack. */ 
    ldmia r0!, {r4-r11} /* Pop the registers and the critical nesting count. */ 
    msr psp, r0 
    bx r14 
    nop 
    }

    R3 -> 0x20000220 (looks valid)

    R1 -> 0x00000001 (This is strange. Fetch from this address should fail)

    I am stuck here. Help appreciated. 

    Jitesh

  • 0 in reply to Jitesh Shah
    TI__Guru* 85400 points
    Hi Jitesh,

    Can you verify proper device power up - processors.wiki.ti.com/.../CC256x_Testing_Guide ?
    Do you see the HCI_RTS getting low?

    Regards,
    Gigi Joseph.
  • 0 in reply to Joseph Gigi
    Prodigy 60 points

    Only thing I had to do was update FreeRTOS to the latest stable drop and that got rid of the crash. Fortunately, the new FreeRTOS was mostly a drop-in replacement. 

    I can run the demo fine now.

    Jitesh

  • 0 in reply to Jitesh Shah
    Prodigy 160 points

    Hello, which version have you used for update? I have here STM32F4DISCOVERY board, but FreeRTOS version 8.2.3 lands in prvTaskExitError() instead of causing a hard fault with version 7.5.2.

    Regards,

    Linas