• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 2 answers
  • Subscribers 54 subscribers
  • Views 700 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CCS/CC1310: CC1310 Collector sendMsg failed

Shaolin Zhang
Intellectual 800 points
Part Number: CC1310

Tool/software: Code Composer Studio

collector to sensor Message sending failed.rar

Hi All:

I have a problem with CC1310 collector and sensor.

collector failed to send message to sensor(sensor can't receive message from collector by sending date request).

I found it through printing by uart, the function    static bool sendMsg(Smsgs_cmdIds_t type, uint16_t dstShortAddr, bool rxOnIdle, uint16_t len,uint8_t *pData)； return false, it happens occasionally.(I tried it 100 times and it came up once)

When sensor power-on again,back to normal.

Accessory is my sinffer file by pack snifffer and wireshark.(Start at line 9618)  The short address 0x0002 is sensor and 0x7686 is collector.

 

  • 0
    TI__Genius 14845 points

    Hi, 

    Which version of the SDK are you using and what kind of modifications have you made to the project? Can you reproduce this issue using the default project from the SDK?

    Thanks,
    Elin

  • 0 in reply to Elin W
    Intellectual 800 points

    We use the 1.6 SDK, and the demo is collector and sensor. Our applications are all modified on this. This problem is not easy to reproduce. It will only be tested once a hundred times. Can you see any problem in sniffer's wireless packet capture?

  • 0 in reply to Shaolin Zhang
    TI__Genius 14845 points

    Hi, 

    Thanks for sharing. 

    What error code are you getting on the datareq API call inside sendMsg()? This error code will tell us more about what the problem is. 

    Thanks, 
    Elin

  • 0 in reply to Elin W
    Intellectual 800 points

    Hi,

    We have traced this problem to sendmsg() at present, but we haven't traced it down yet, but we are testing it now, because it doesn't happen very often, so we need to do a lot of testing to make it happen. We'll keep tracking down to see when it's wrong with apimac_ Return value of mcpsdatareq (& datareq). Is there any way to deal with these corresponding errors?

  • 0 in reply to Shaolin Zhang
    TI__Genius 14845 points

    Hi, 

    Thanks for the update. 

    Perfect, just let me know when you have an update on the error code. You can see all the error codes here: 

    So the fix really depends on what kind of error message you are getting. 

    Thanks, 
    Elin

  • 0 in reply to Elin W
    Intellectual 800 points

    hi

    When we test here, we caught an error code of 0xf1. From the error table, we can see that the send buffer is full. When this kind of error occurs, can we clear this buffer?

  • 0 in reply to Shaolin Zhang
    TI__Genius 14845 points

    Hi, 

    Thanks for the update!

    There are two possible fixes for this. Either you can use the ApiMac_mcpsPurgeReq() API to clear the buffer. 

    Or you can increase the MAC_CFG_TX_DATA_MAX to 10, which also should fix the problem. 

    Thanks, 
    Elin

  • 0 in reply to Elin W
    Intellectual 800 points

    Thank you for your reply. We will test this problem according to these two methods, which should solve these bugs

  • 0 in reply to Shaolin Zhang
    Intellectual 800 points

    hi Elin

      After a lot of testing, we found that this method did not solve the problem. Enlarge mac_ CFG_ TX_ DATA_ The value of Max will only delay the error prompt for a few packets. When I fail, I call apimac_ Mcpspurgereq() API is used to clear messages, but I found that it doesn't work. This API needs to pass msghandle data, and I should send that value. I found that every time I send a piece of data, this value will be + 1, and its range is from 0x80 to 0x9f. And we also found a phenomenon through the packet capture software. When the collector reports an error, the packet capture data can see the data sent by the collector, but there is no ack from the sensor

    The normal data interaction is that the sensor sends a packet of data to the collector and the collector returns a packet. However, in some cases, the sensor cannot normally receive the data replied by the collector. The phenomenon of bag grabbing is as follows:

    However, under abnormal circumstances, the collector will always reply to the sensor poll request, but the sensor does not reply with ack. The sensor can send data to the collector normally, and the packet capture phenomenon is as follows

    It looks like the sensor can't receive the data from the collector. The length of our payload data is 131 bytes. Does this have anything to do with the data traffic?

  • 0 in reply to Shaolin Zhang
    TI__Genius 14845 points

    Hi, 

    Thanks for letting me know. 

    The images are unfortunately broken so I cannot see them in the E2E post, but I did receive them over email together with some additional information. 

    The new issue you are seeing is likely due to the combination of the size of the payload, a short sensor polling interval and using the 5kbps PHY. This issue can be fixed by either changing PHY or increasing the sensor polling interval. 

    Thanks, 
    Elin