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.

Why is my TI-RTOS I2C task crashing?

Guru 18605 points
Other Parts Discussed in Thread: CC2564MODN, TM4C129ENCPDT, SYSBIOS

Good afternoon,

We are developing a bluetooth prototype based on the TM4C129ENCPDT controller and the CC2564MODN module. However, I do not think this is crucial since I think my error is related to RTOS tasks. That's why I post here.

In fact, we had this project working in another TI platform and it worked flawlessly :) But when shifting to TI-RTOS, since these are our first steps, we have faced the following problem which probably will be trivial to solve for experienced users.

The software is based on the TI dual-mode Bluetooth stack (in particular, the SPPLEDemo with TI-RTOS), and we are modifying the demo code to include an external sensor which is polled periodically during 5 seconds or so before establishing the pairing with a remote device. You may think of it as a NFC routine which tells the CC2564MODN which Bluetooth address to connect to :)

For this purpose, we create a task (SensorThread) at the InitializeApplication() function, which performs the reading of an I2C sensor periodically (14ms) to fill the buffer (g_sSensor.data_received = 1). This polling is just executed once.

Task Initialization:

Task_Params_init(&taskParams);

taskParams.stackSize = 512;

taskParams.priority = 1;

taskParams.instance->name = "DataEvent";



g_sSensorTaskHandle = Task_create(SensorThread, &taskParams, NULL);

And the sensorThread code is:

void *SensorThread(void *Param)

{

     while(!g_sSensor.data_received)

     {

        /* Wait for 14 ms; */

        Task_sleep(14);

        PeriodicReading();/* I2C Reading of the sensor */

     }

     ProcessData();

     return(NULL);

}

The periodic readings end successfully, and then the received data is processed at the function ProcessData(). ProcessData() extracts the pairing address and begins the configuration of the Bluetooth settings to perform a Just Works pairing as follows:

  • Open SPP in Server Mode

  • Pairability Mode: pairable

  • Connectability Mode: connectable

  • Discoverability Mode: general

  • Simple Pairing parameters: No Input/Output; MITM: false

Wherever I place the polling code to obtain the MAC address, it crashes just in the next Bluetopia function invocation. I mean, if I place my function after the “Open SPP” part, it crashes just before “Pairability Mode”. If I place this after “Pairability Mode”, up to this part the code parts runs smoothly and it crashes just before “Connectability Mode”. Oh, BTW, when I supress the polling code and I hardcode the MAC address, everything runs perfect. Because of all this, that's why I'm guessing my problem is in the way I run the TI-RTOS task.

I attach the dump I obtain from my “console” view just next, as well as a screenshot with something  I guess can be useful :)

ti.sysbios.family.arm.m3.Hwi: line 1087: E_hardFault: FORCED

ti.sysbios.family.arm.m3.Hwi: line 1164: E_busFault: IMPRECISERR: Delayed Bus Fault, exact addr unknown, address: e000ed38

Exception occurred in background thread at PC = 0x00018892.

Core 0: Exception occurred in ThreadType_Task.

Task name: {unknown-instance-name}, handle: 0x2000a0f0.

Task stack base: 0x250025.

Task stack size: 0x70000.

R0 = 0x00000003 R8 = 0x00040006

R1 = 0x00270007 R9 = 0x2000e8b8

R2 = 0x20009de4 R10 = 0x00000000

R3 = 0x05540010 R11 = 0x00000000

R4 = 0x2000a0f0 R12 = 0x150e0200

R5 = 0x2000e8b8 SP(R13) = 0x20009db8

R6 = 0x00000003 LR(R14) = 0x00014ef3

R7 = 0x00050000 PC(R15) = 0x00018892

PSR = 0x21000000

ICSR = 0x00423803

MMFSR = 0x00

BFSR = 0x04

UFSR = 0x0000

HFSR = 0x40000000

DFSR = 0x0000000b

MMAR = 0xe000ed34

BFAR = 0xe000ed38

AFSR = 0x00000000

Terminating execution...

So! Any hint from anyone which can help me solve this? Do not hesitate indicating me any other info you may need or any other test you want me to perform, or any additional piece of code you want to look at :)

Thanks in advance and have a really nice day!

  • Hi Kazola,

    Please follow the steps in the following BIOS FAQ. This will help you trace backward to see where the crash is coming from:

    processors.wiki.ti.com/.../BIOS_FAQs

    Steve
  • Hi ,

    thanks for your interest :)

    I attach some additional information, any hint you may give us? :)

  • I have a feeling your Task stack is too small (and you are running into an overflow problem).

    Can you try increasing the stack size of your SensorThread task? You should make it A LOT larger, just for the sake of determining if this is the problem, as well as how much stack size you actually need. For example:

    taskParams.stackSize = 8192;

    Note that this may seem like a lot, but the idea is that we want to ensure that you have plenty of stack, and check to see if increasing the stack size solves the issue.

    If it works with this change, you can try to figure out how much stack your task needs.

    You should put a break point at the call to ProcessData(), and then open the ROV tool and check the stack peak at this point.

    Then, hit the "step over" command, which will run teh ProcessData() function and return to the point in the code immediately after that call.

    What does the stack peak in ROV show after stepping over ProcessData()?

    This number should give you an estimate of how much stack size your ProcessData() call uses.

    Steve
  • OMG, we had increased this a little bit but not that far. 

    This has helped us a lot.

    Thanks a lot and have a nice day .

    We buy you a beer whenever you visit Barcelona ;)