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.

RTOS/CC2650: BIOS_Start() exception before task execution

Part Number: CC2650

Tool/software: TI-RTOS

We are running TI-RTOS 2_18_00_03 and tiDrivers 2_16_01_13 with bios 6_45_02_31 on a custom board with a CC2650 and BLE 2_02_00_31 using IAR 7.80.3.

Our application has been stable until recent changes/additions.  Now we execute BIOS_Start() and it never gets to the task.

We step it through the bios, and after about 270 instructions it goes through Task_StartCore, then Task_supportProxy_start, then TaskSupport_glue, and with TaskSupport_swap it corrupts the Stack Pointer and is trapped in the exception handler.

The task stacks are fine --- they never executed.  The heap appears to be fine. It never changes as it steps through, surprisingly --- so we assume we are missing something there. The CStack area looks fine until the SP gets corrupted along with all the registers.

Can you give us some hints about where to look next.  Project Options number of tasks?  number of entities?  We are pushing the envelope on total memory consumed, between our app and the BLE stack.

  • Hello Happy Dawg,

    Were you able to isolate the change that results in this condition? Many times these problems end up being incorrect pin and/or driver configurations.

    I would also recommend reviewing the "Deciphering CPU Exceptions" section in the BLE SW Dev Guide (SWRU393), there are some tips on how to trap and analyze these exceptions.

    Best wishes
  • We tried re-downloading the full software kit... TI RTos, xdc, simplelink... no improvement.  The exception continued.  We tried previous source versions of our app, no change.

    We then examined the supporting files for the TI sample programs.... and found one common file that had been edited about the time of the start of the problem.

    It was the linker file  src/common/cc26xx/iar/cc26xx_app.icf.  We examined it using KDiff3, and found no difference between that edited file and the original downloaded file, other than the CStack allocation.

    We copied over the original file, edited it to the same CStack size as before, then ran the application.

    The problems disappeared --- the app runs fine again.

    KDiff3 revealed no visible difference that should have made a difference to the compiler.  However, I have seen editors add hidden characters that a compiler could not digest... perhaps this is one of those situations.

    So I'll mark this resolved.