CC1354P10: BLE initialization error

Nick Braun

Part Number: CC1354P10
Other Parts Discussed in Thread: CC2654P10, , CC2652R, CC1354R10, CC2674R10

Tool/software:

hello everyone
I am trying to create my project for CC2654P10 using FreeRTOS and the GCC compiler.
I am using the "simple_peripheral" project for "LP_EM_CC1354P10_1" as a base.
I use the files generated for the project (ti_driver_config, ti_device_config, etc.). In general, everything works fine, i.e. I create tasks that work.
But I can't initialize BLE. I see that the execution reaches the osal_run_system function (from the ble5stack_flash folder), inside which the first function is called. Apparently, this is LL_ProcessEvent.

    HAL_ENTER_CRITICAL_SECTION(intState);
    events = tasksEvents[idx];
    tasksEvents[idx] = 0;  // Clear the Events for this task.
    HAL_EXIT_CRITICAL_SECTION(intState);

    activeTaskID = idx;
    events = (tasksArr[idx])( idx, events );
    activeTaskID = TASK_NO_TASK;

    HAL_ENTER_CRITICAL_SECTION(intState);
    tasksEvents[idx] |= events;  // Add back unprocessed events to the current task.
    HAL_EXIT_CRITICAL_SECTION(intState);

Since this is a closed stack, I can't keep track of exactly what is being executed. But somewhere inside this function, an error occurs, and the execution of the entire project ends with a faultISR error.
I'm not sure if the error occurs in the same place. But definitely somewhere in the process of performing this function. I can't figure out what the reason might be, since the project with "simple_peripheral" and ti rtos is working more or less correctly. I tried to find additional information in the CPU_SCS registers when I got into faultISR. For example, I see 0x100 in the CFSR register and 0x40000000 in the HFSR register, but I'm not sure if this contains useful information.

Is there a mistake in setting up FreeRTOS? Perhaps the stack size is insufficient? But how to prove it? I tried increasing the heap size in the FreeRTOS configuration file, but it didn't help. I tried to increase the stack size for the RF task, but it didn't help either.
Maybe it's about configuring the RF task? But in the ti rtos example, this does not lead to a critical error.
Maybe in css studio you can track where I'm leaving from in a critical interruption? The usual call stack in debugging does not show such information.

thanks for any help.

4 months ago

0 Clément 4 months ago

TI__Guru** 101430 points

Hi,

Thank you for reaching out.

Please note the BLE5Stack is not tested with GCC compiler on the CC1354 / CC2674 devices. We recommend using TIClang instead of GCC for the following reasons.

TIClang is based on open source LLVM'
TIClang supports GCC language extensions
Most of the CLI options are the same between the two compiler
Only incompatibility: TI Linker. Linker scripts are very similar to GCC, but not identical. Simple migration guide: https://software-dl.ti.com/ccs/esd/documents/sdto_cgt_linker_migration_gcc_to_tiarmclang.html

Best regards,

0 Nick Braun 4 months ago in reply to Clément

Prodigy 90 points

Hi,

Thanks for your reply.
I'm afraid I don't have the option to switch to another compiler yet.
But maybe there are some suggestions about my situation? For example, if we talk about the concept of cc2652 or another similar chip?

0 Clément 4 months ago in reply to Nick Braun

TI__Guru** 101430 points

Hi,

Nick Braun said:
For example, if we talk about the concept of cc2652 or another similar chip?

SDK 6.30 offers support for FreeRTOS+GCC for the BLE5Stack on the CC2652R (cf. multi_role example)

Nick Braun said:
Perhaps the stack size is insufficient? But how to prove it? I

You can use the ROV to review the heap and stacks sizes. ROV usage is documented in the Debugging Guide. https://software-dl.ti.com/simplelink/esd/simplelink_cc13xx_cc26xx_sdk/7.41.00.17/exports/docs/ble5stack/ble_user_guide/html/ble-stack-5.x-guide/debugging-index.html#ti-rtos-object-viewer

I hope this will help,

Best regards,

0 Nick Braun 4 months ago in reply to Clément

Prodigy 90 points

I investigated the problem more closely and found out that the error was in the llUserCfg_t structure.

Since I did not have the EM_CC1354P10_1_LP define installed, 12 bytes (or three additional fields) were missing inside the structure.

Because of this, when executing this line

llUserConfig.rfMode = &RF_modeBle;

in the setBleUserConfig function, it was written with an incorrect offset, and subsequently when calling the RF_open function, an incorrect argument RF_Mode* pRfMode was passed

Which subsequently had disastrous consequences. It's not clear why the SDK example works without this default.

0 Clément 4 months ago in reply to Nick Braun

TI__Guru** 101430 points

Hi,

This is a good catch, thank you for sharing!

Best regards,

0 Nick Braun 4 months ago in reply to Clément

Prodigy 90 points

I'm having trouble integrating Freertos anyway.

in the icall_POSIX.c file (ble5stack_flash/icall/src) there is an ICall_newTask function that generates something and returns a pointer to something to the variable syncEvent

I think it's event group from FreeRTOS but after work BLE stack i use some function, like Util_enqueueMsg from file util.c (ble5stack_flash/common/cc26xx). And inside this function have like this

#ifdef FREERTOS

typedef struct {
    uint8_t * pData;
}queueMSG;

uint8_t Util_enqueueMsg(mqd_t msgQueue,
                        Event_Handle event,
                        uint8_t *pMsg)
{
  ConsoleWrite("%s()\r\n", __func__);
    queueMSG myMsg;

    myMsg.pData = pMsg;
    mq_send(msgQueue, (char*)&myMsg, sizeof(queueMSG), 1);

    // Wake up the application thread event handler.
    if (event)
    {
    
        uint32_t msg_ptr = UTIL_QUEUE_EVENT_ID;
        mq_send(event, (char*)&msg_ptr, sizeof(msg_ptr), 1);
        
    }

    return TRUE;

}
#else
// Other
#endif

if condition use func mq_send and queue type (it's syncEvent variable) but we init his like event group.

How best condition fix this?

0 Clément 4 months ago in reply to Nick Braun

TI__Guru** 101430 points

Hi,

Nick Braun said:
How best condition fix this?

I am afraid I don't totally understand your question.

Per your previous message, you have ran into a few issues due to missing compiler pre-define symbols. I highly recommend you ensure all the pre-define symbols in the unmodified project got properly added to your compiler configuration.

I hope this will help,

Best regards,

0 Nick Braun 4 months ago in reply to Clément

Prodigy 90 points

Hi,

please explain what is the difference between folders "ble5stack" and "ble5stack_flash" to use in the project?

0 Clément 4 months ago in reply to Nick Braun

TI__Guru** 101430 points

Hi,

Some devices in the CC13xx/CC26xx have a part of the ble5stack in ROM. The ble5stack is meant to be used on devices with a part of the ble5stack in ROM. The ble5stack_flash is meant to be used on devices without ble5stack in ROM.

The CC2674R10 or CC1354R10 devices don't have the ble5stack in ROM, so the ble5stack_flash should be used.

As the questions coming now are not related to the initial topic, I'll close this thread. Please feel free to open new threads to receive support on your new inquiries - this ensure the right experts are looped in each time. Thank you for your comprehension.

Best regards,

0 Nick Braun 4 months ago

Prodigy 90 points

Yes, I think the discussion can be closed, since I have solved my problem. I will not write messages off-topic. I'll just say that in my case, all the problems were in the wrong method of synchronization between iCall between the BLE stack and the code from the example for using FreeRTOS.

Anyway, thanks for the help!

Sub-1 GHz

Sub-1 GHz forum

CC1354P10: BLE initialization error