• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 2 answers
  • Subscribers 52 subscribers
  • Views 246 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.

LAUNCHXL-CC26X2R1: Timing concern in RTOS-BLE design

Tony Man
Prodigy 150 points
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.

  • 0
    TI__Mastermind 30369 points

    Hi,

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

    Best Regards,

    Jan

  • 0
    TI__Guru* 94108 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 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 in reply to Tony Man
    TI__Guru* 94108 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 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 in reply to Tony Man
    TI__Guru* 94108 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 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 in reply to Tony Man
    TI__Guru* 94108 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 in reply to Clément
    TI__Guru* 94108 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 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 in reply to Tony Man
    TI__Guru* 94108 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,