LAUNCHXL-CC26X2R1: Timing concern in RTOS-BLE design

Tony Man

Part Number: LAUNCHXL-CC26X2R1
Other Parts Discussed in Thread: ENERGYTRACE

Greeting. Thanks ahead for helping out.

I have migrated and modified the simple peripheral demo project from the LAUNCHXL-CC26X2R1 SDK, the application is working fine regarding the BLE function.

One of my goal in designing the system is to maintain the BLE functionalities while keeping the device sensitive to SPI request.
Currently the problem of the system is the collision between the BLE and SPI processing.
My application failed to maintain a stable communication in both interface simultaneously.

As expected, timing of task and interrupt in the RTOS would be essential in the following system design and investigation.

I have got several question regarding the design objective.

1. Is there any debugging functionalities other than the ROV that helps better in diagnosing the timing performance of the application?

2. Is it feasible to make the controller responsive to local communication events despite the BLE functionalities?
Or technically the BLE management task would be demanding in computation power so having those task separated would make the design easier?

Would be great if you don't mind sharing your thought on the project goal or my question. I am grateful for your attention anyway.

over 1 year ago

0 Jan over 1 year ago

TI__Mastermind 30469 points

Hi,

I have assigned a relevant expert to help with your query.

Best Regards,

Jan

0 Clément over 1 year ago

TI__Guru* 94288 points

Hi,

Thank you for reaching out.

1- You can refer to the debugging guide available in the user's guide: see here.

2- I confirm it is definitely feasible to maintain a Bluetooth LE connection while using a serial communication IP. We have several examples of such:

UART or SPI communication + Bluetooth LE in the host_test example (see in the SDK)
I2S + Bluetooth LE in the audio plugin (see here)
UART + Bluetooth LE in the simple serial socket example (see here)

Make sure to use the serial drivers in callback mode (always avoid blocking mode). You could also design the system to use separate tasks, but this is generally not the approach I recommend as it requires more resources and may not be scalable.

I hope this will help,

Best regards,

0 Tony Man over 1 year ago in reply to Clément

Prodigy 150 points

Thanks for the attention.

1. I am using RTOS7 but i got problem in debugging the CPU. I got a HWI which i cannot assess the exception call stack in ROV view. I did'nt perceive sufficient resource on the debug manual to solve it. Would you mind to provide more guidance on that?

2. Besides, is there any other way in debugging HWI exception other than ROV view currently?

3. Is there any other tools than breakpoints to visualise the cpu performance on RF or application?

4. In the old project i didnt configure the I2C interface as callback mode as instructed. Yet the prolonged application operation did interfere the RF function so I wonder would there be anyother clever way in doing the development work.

Regards

0 Clément over 1 year ago in reply to Tony Man

TI__Guru* 94288 points

Hi,

Tony Man said:
2. Besides, is there any other way in debugging HWI exception other than ROV view currently?

You may still want to review the debugging guide, and especially the section dedicated to "Deciphering CPU exceptions".

Tony Man said:
3. Is there any other tools than breakpoints to visualise the cpu performance on RF or application?

You could use EnergyTrace ++ as instructed here.

Tony Man said:
4. In the old project i didnt configure the I2C interface as callback mode as instructed. Yet the prolonged application operation did interfere the RF function so I wonder would there be anyother clever way in doing the development work.

You could still have the serial communication in a separate task...

I hope this will help,

Best regards,

0 Tony Man over 1 year ago in reply to Clément

Prodigy 150 points

For HWI exception, I struggle to load the excHookFxn via the syscfg interface. I tried to load it in the Core Exception Handlers section but it seems didn't recognise the execHandlerHook(Hwi_ExcContext *ctx) function declare somewhere else.

Besides, from the link register I think somehow the problem is the RTOS queue module. Does the ROV provide related info for Queue?

0 Clément over 1 year ago in reply to Tony Man

TI__Guru* 94288 points

Tony Man said:
Besides, from the link register I think somehow the problem is the RTOS queue module. Does the ROV provide related info for Queue?

Yes, the ROV provides a module for this.

0 Tony Man over 1 year ago in reply to Clément

Prodigy 150 points

Is there any more instruction on the excHandlerHook? And in this case using RTOS7, the ROV do not provide the queue module look. I wonder if the configuration is not correct.

0 Clément over 1 year ago in reply to Tony Man

TI__Guru* 94288 points

Hi,

I am looking into other possibilities to ease the debugging of your issue, please bear with me. I hope I'll have feedback for you by the end of next week.

Thank you for your comprehension.

Best regards,

0 Clément over 1 year ago in reply to Clément

TI__Guru* 94288 points

Hi,

For now, Hwi options are not exposed in the GUI. But you can see them in the generated documentation:<SDK>/docs/tirtos7/SysconfigDoc.html

ROV still works for decoding exceptions. But the call stack work does not.

I hope this will help,

Best regards,

0 Tony Man over 1 year ago in reply to Clément

Prodigy 150 points

Thanks for the attention.

So in the current edition there is no way for reading the call stack? Does the situation happen in RTOS7 only?

+1 Clément over 1 year ago in reply to Tony Man

TI__Guru* 94288 points

Hi,

The issue with reading the call stack is due to the ROV. As a consequence I am afraid the same problem will occur for all the RTOS.

Best regards,

Bluetooth®︎

Bluetooth forum

LAUNCHXL-CC26X2R1: Timing concern in RTOS-BLE design