CC1352P: TI 15.4 Stack with osalport: RX stops

hkr

Part Number: CC1352P

Hello,

I am struggling with a communication failure using TI 15.4 stack since moving to the NOICALL (and osalport) variant. Here is the environment of the problem:

- I am using SDK 2.20 for CC1352P.

- I have a working application that uses TI 15.4 stack communication between 1 device and 1 coordinator, using icall (Library: maclib_nosecure_combo_cc1352.a). Both RX and TX data like in ping-pong fashion.

- After moving the application to the NOICALL variant of the lib (maclib_secure_noicall_cc1352.a), within 60 minutes, the RX part of the 15.4 device „stops“, which means, the device does not receive any more frames. The coordinator still receives and transmits, the device still transmits.

Via the CCS debugger, by means of breakpoints, I tried to figure out where the RX “stops”. I compared call stacks in state “RX working” with state “RX not working anymore” and detected the following difference:

While RX is working, a breakpoint osal_port.c, line 320 (where the RX event is set) leads to the following call stack:

- macRxCompleteCallback()

- rxPayloadIsr()

- macRxFrameIsr()

- macRxCbSubG()

- RF_radioOpDoneCb()

Also, a breakpoint at the beginning of the following functions trigger regularly (I believe those schedule the RF command for RX):

- macRxOn()

- macSendReceiveCmdSubG()

As soon as RX is not working anymore, I can still set breakpoints in functions

- macRxOn()

- macSendReceiveCmdSubG()

which lets me believe that the RX commands are still scheduled. On the other hand, I can only trigger breakpoints in functions

- macRxCbSubG()

- RF_radioOpDoneCb()

and none of other functions that are called, starting with macRxFrameIsr().

Clearly, I don’t have the code of the MAC, but I would hope that you could help me find the cause of the failure by checking what reason there might be that macRxFrameIsr() is not called anymore in macRxCbSubG().

What I have checked or tried to solve or circumvent the problem without success:

- Checked in my application that transmit and receive functions do still work as expected at this stage.

- Played with task priorities (MAC Task has Prio 4, application task has prio 3, all others have <=2)

- Compared my XDC Configuration to the dmm_154sensor_remote_display_cc1352r1lp_app example project. (Just to be clear, I am compiling in the BLE Stack into the same binary, but I do not use it at this stage. I do not use DMM.)

- I have tried using Library maclib_secure_noicall_combo_cc1352.a instead of maclib_secure_noicall_cc1352.a

- Compared variables when stopping in both stages (RX working and RX not working) in macRxCbSubG() function – no significant different as far as I can tell (Screenshots attached).

Hopefully there is a way to fix this!

Thank you in advance,

hkr

over 6 years ago

0 hkr over 6 years ago

Intellectual 940 points

I am attaching some CCS screen shots from the debugger.

1) Working RX; Halted in macRxCbSubG(); to compare variables

2) Working RX; Halted in OsalPort_setEvent(); to view call stack

3) RX not working; Halted in macRxCbSubG(); to compare variables with 1) and to view call stack

0 Severin Suveren over 6 years ago in reply to hkr

TI__Mastermind 23730 points

Hi hkr,

TI 15.4-stack NOICALL is only supported with DMM. We cannot provide support for 15.4 NOICALL on a none-DMM 15.4 project.

0 hkr over 6 years ago in reply to Severin Suveren

Intellectual 940 points

Hello Edward,

Well - this would be an unsatisfying answer, hadn't I found the bug already...

By the way, I am using the 15.4 NOICALL without DMM and it works fine!

Here is a patch for macStack.c where I think I have discovered a crucial bug. At least for me the communication is now stable as before with icall:

diff --git a/RFlib/ti154stack/MAC/macTask.c b/RFlib/ti154stack/MAC/macTask.c
index 6f81eab..3ef8c04 100644
--- a/RFlib/ti154stack/MAC/macTask.c
+++ b/RFlib/ti154stack/MAC/macTask.c
@@ -105,7 +105,7 @@ static uint8_t macTaskStack[MAC_TASK_STACK_SIZE];
 Semaphore_Struct macSem;  /* not static so you can see in ROV */
 static Semaphore_Handle macSemHandle;
 
-static uint32_t macEvents = 0;
+static uint32_t macEventsStorageForOsal = 0;
 
 int16_t _macTaskId = -1;
 
@@ -410,7 +410,7 @@ static void macTaskFxn(UArg a0, UArg a1)
   macEventHdr_t       hdr;
   uint32_t            key;
   uint8               status;
-//  uint32_t            macEvents = 0;
+  uint16_t            macEvents;
 
   macUserCfg_t* userCfg = (macUserCfg_t*) a0;
 
@@ -421,7 +421,7 @@ static void macTaskFxn(UArg a0, UArg a1)
   /* Register task with osalport
    * By setting _macTaskId, the rflib task continues
    */
-  _macTaskId = OsalPort_registerTask(Task_self(), macSemHandle, &macEvents);
+  _macTaskId = OsalPort_registerTask(Task_self(), macSemHandle, &macEventsStorageForOsal);
   /* Set macTaskId */
   macMainSetTaskId(_macTaskId);
 
@@ -617,7 +617,6 @@ static void macTaskFxn(UArg a0, UArg a1)
       }
 
       OsalPort_clearEvent(macEvents);
-      macEvents = 0;
 
       Task_enable();
   }

So, to describe the bug as well: A variable was given to OsalPort for the storage of this task's events. In OsalPort, this variable is only changed in critical sections. But in macTask.c, by mistake, the result of the OsalPort getEvents() function is again written to OsalPort's storage variable (without criticial section). So I suppose, events simply got lost because of this bug.

Best regards,

hkr

0 Severin Suveren over 6 years ago in reply to hkr

TI__Mastermind 23730 points

Thanks for reporting the bug. I will make sure this is reported to the TI 15.4-stack team.

Sub-1 GHz

Sub-1 GHz forum

CC1352P: TI 15.4 Stack with osalport: RX stops