LAUNCHXL-CC1352P: Not able to achieve multitasking at 10ms of periodicity.

Hi Jayesh,

1. Which version of the SimpleLink F2 SDK are you using?

2. Can you set the priority of task B or C to a different value? It's not recommended to have two tasks with the same priority.

(BTW in your table you're missing the BLE stack task, this one has priority 5 and should always be the highest priority task.)

3. Can you try to confirm where your issue is? The data is flowing over the air and then over a serial bus. Can you confirm whether the packets are still going over the air (e.g. the issue is happening over the serial interface)? Or confirm all the return statuses from your serial API calls, which would point towards the issue being the packets going over the air.

Cheers,

Marie H

Hi Marie,

Thank you for your reply. Please find my answers to your queries below,

1. Which version of the SimpleLink F2 SDK are you using?

-  We are using simplelink_cc13x2_26x2_sdk_4_10_00_78 version

2. Can you set the priority of task B or C to a different value? It's not recommended to have two tasks with the same priority.

(BTW in your table you're missing the BLE stack task, this one has priority 5 and should always be the highest priority task.)

- Yes, we experimented with that too,

 Task_A , Priority:4  Task_B, Priority:2  and Task_C, Priority:3 (For this combination, all peripherals are connecting but not following the 10ms periodicity)

 Task_A , Priority:3  Task_B, Priority:2  and Task_C, Priority:4 (For this combination, data is stopping on serial device after connecting 4th peripheral)

Note: Yes, we have the BLE stack task. We are not changing the priority of the BLE stack task . It has a priority 5.

3. Can you try to confirm where your issue is? The data is flowing over the air and then over a serial bus. Can you confirm whether the packets are still going over the air (e.g. the issue is happening over the serial interface)? Or confirm all the return statuses from your serial API calls, which would point towards the issue being the packets going over the air.

- Yes, we are facing issue at serial side and transmitter is still sending packets over the air .We have also checked the ROV (RTOS Object View) in the receiver code. Please have a look,

One more thing I need to tell you that, If we followed the above mentioned priorities in the given table and change periodicity from 10ms to 20ms then it is working fine. All 4 peripherals are connecting and we are getting serial data at 20ms periodicity.

Our main concern is that if we want a particular periodicity, such as 10ms or 20ms, then it will only follow if Task_C is given higher priority than other tasks. (excluding BLE Stack Task , it has highest priority 5).

Basically, we need solutions for 10ms periodicity. Please let me know if you need any additional details

Thanks!

Hi Jayesh,

If you suspect the issue is with the serial bus I would try the following:

1) Increase the baud rate on your serial bus. Since the issue is happening as you increase the data flow, it may be your bus is congested.

2) Use a logic analyser to look at the serial pins.

3) Check the return status of every API call for the driver you are using.

Cheers,

Marie H

Hi Marie,

Thanks for your support.
Earlier we suspected that issue is on serial peripheral side and hence checked with increased SPI clock from 1MHz to 6MHz. But issue remains same.
Checked SPI signals waveform on CRO, it looks OK for low and higher clocks.

Also checked with fixed data transfer in following two scenarios.

(a) when there are no data input from BLE, serial data output is ok and follows required periodicity
(b) when there is data input from BLE which is just coming to buffer but not sent to serial output, fixed data is sent to output. It is observed that data output stops after 5-7sec.

It looks like whenever there is data is received over BLE other tasks are not getting enough time to execute respective functions.
Is there any way we can customize task scheduling not just as per priority but round-robin or any other way.

Not sure we are using best scheduling for our application.

Can you please guide on the same?

Hi Jayesh,

Bluetooth low energy is a synchronous protocol, meaning the BLE packets have to be sent and received at a specific time. Thus the BLE-Stack needs to have the highest priority. However you can experiment with the BLE settings, e.g. connection interval. Please note some of these settings are controlled by the BLE central device so you need to set them there.

Cheers,
Marie H

Hi Marie,

Thank you for the suggestion, we are currently experimenting with the connection interval. 
Earlier it was set to connection interval Min. 12.5 ms and connection interval Max 42.5 ms

We have one doubt , using inbuilt function like  Display_printf(). It can be used to send bulk data over serial,  and we are getting serial data on UART at 10ms interval (keeping connection interval unchanged).

So, is there any function or API's to send bulk data to SPI? Or How efficiently we can use SPI? 

Hi Marie,

Thank you for the support. As previously mentioned, we experimented with the connection interval.

For the following scenario,

Con Interval: Min 11.5 ms Max 51.5 ms

We are getting data for three peripherals and for the 4th peripheral as we are not getting data, we are sending dummy data. The best outcome is that the data is not halted like it was before, but we are getting dummy data from one of the peripherals out of 4 peripherals.

We tried SPI using DMA, but we had no luck.

We are still curious, How UART is able to send data of all peripherals at 10ms periodicity and SPI not?

As you had explained earlier UART supports up to 3 Mbaud and SPI uses 12 system clock ticks,

We are using UART baud rate: 460800, SPI CLK: 4MHz and tried max 6 MHz which is supported by CC1352P mcu.

Hi Jayesh,

Is your CC1352P device acting as the SPI peripheral or the SPI controller? 

Can you tell me a bit more about the SPI implementation?

Cheers,

Marie H

Hi Marie,

Marie H said:

Is your CC1352P device acting as the SPI peripheral or the SPI controller? 

- It is acting as a SPI controller.

Marie H said:

Can you tell me a bit more about the SPI implementation?

-  We have interfaced MCP2518FD module to CC1352P and CC1352P act as master.

   please find the SPI configuration as below,

   SPI_init().

   /* Configure SPI as master */
   SPI_Params_init(&Can_spiParams);

   Can_spiParams.bitRate = 4000000; //4Mbps
   Can_spiParams.mode = SPI_MASTER;
   Can_spiParams.dataSize = 8;
   Can_spiParams.transferMode = SPI_MODE_BLOCKING;
   Can_spiParams.frameFormat = SPI_POL0_PHA0;

Hi Jayesh,

I talked to the software designer, and for your usecase I think using UART in NON-BLOCKING mode is probably the best approach. 

https://dev.ti.com/tirex/explore/content/simplelink_cc13xx_cc26xx_sdk_7_41_00_17/docs/drivers/doxygen/html/_u_a_r_t2_8h.html

Cheers,

Marie H

Hi Marie,

I appreciate your suggestion.
But our requirement is to transmit data over CAN using the MCP2518FD module (SPI slave device).
If achieving it with the CC1352P device is a challenge, please suggest an alternative MCU or workaround.
This will be greatly appreciated

Thanks,

Jayesh Wagh