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.

RTOS/CC1352P: Main Assert handler problem in cc1352 devices

Part Number: CC1352P

Tool/software: TI-RTOS

hi,

I am working on one CC1352P and two CC1352R launchpads using collector and sensor example codes in TI15.4 stack (SUB 1 GHz). I have connected two more sensor devices to my collector device and my device is working fine. Sensors send data with some interval configured. But after restart of collector if sensors are off and only collector is on, collector is executing Main_AssertHandler after one minute.

If i POWER ON any sensor or send any message from UART this is not happening.

So i have added an unused_evt and set for 50 sec and have done nothing in that event and set again in that event itself. The collector is working fine even if sensors are off and no data is sent from UART.

In Collector_process()

{

if(collector_events & COLLECTOR_START_EVT)

{

// events function to be executed

// clear event

}

..

..

if(collector_events & UNUSED_EVT)

{

// clear event

}

/* Don`t process Apimac messages until all of collector events are processed*/ 

here below line i kept break point and it hits only once  and after it is not executing

if (collector_events == 0)

{

ApiMac_processIncoming();

}

}

why if i didn`t add unused event, the collector is executing MAIN_ASSERT_HANDLER(TI_RTOS_HANDLER)?

  • what version of the SDK are you using? can you reproduce this issue with the default unmodified collector/sensor examples or did this issue happened after doing modifications to the application.
  • Hi Hector,

    I am using the following SDK simplelink_cc13x2_sdk_2_20_00_71, i think that this issue will be reproduced with unmodified code. I have done modifications in default collector and sensor codes. I have added some more events to default code and those events are perfectly executed as of now. But still i will try with default code and intimate in this forum.

    Thanks

    Haricharan

  • Hi Hector,

    The above problem didn't appeared with default code i checked with launchpads. This issue happened after doing modifications to the application. But my modifications are working fine with 10 sensors connected to one collector. I am using NON BEACON mode of operation.
  • does the issue happens after you add more than 10 devices?
  • Hi hector,

    I added 10 sensors only but i have dissassociated and joined again 3 devices.

    And most probably that could not be the problem. If you still want any more details you can clarify. 

  • hi hector,

    I had one more query, how many events we can utilize in this collector code. I think it was 16, presently i am using 10 events for my application purpose does this is one of the reason for my restart?

    Thanks & Regards

    Haricharan

  • The collector by default should allow for 16 evens as "Collector_events" is defined as a uint16_t and the events are based on a bitmask. If you wish to use more than 16 you should be able to redefine Collector_events as a uint32_t
  • hi hector,

    Can I get to know why my collector code is restarting with out Unused event what could be the possible reasons for that. And one more query my collector is missing some data sent from sensors. Sensor is sending i kept over night logs for both collector and sensors. Sensors are sending but collector is not receiving. I used One Collector and 5 Sensors with all sensors sending at 5 minutes interval. Over 150 datapoints each sensor has to send some are not reached to collector. What can i improve in my collector code OR Do i require to increase retry count(presently 3 i think) in sensor side? And from sensors log each datapoint is prepared and sent from sensors why does collector didn't receive all.

    Thanks and regards

    Haricharan

  • Hi,

    There are multiple reasons why the collector could be reseting. I do not see this behavior in the default example and cant reproduce this issue. If I had to guess it could be a null pointer dereference that might be causing this but it is not possible for me to give you an answer to what exactly is making your device reset.

    I suggest you try setting breakpoints while debugging your code to see where this might be happening.

    If you want to identify TX or RX issues I suggest you use an over the air sniffer and also I would recommend looking at the statistics collected within the collector and sensor "Collector_statistics" and "Sensor_msgStats"