• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 54 subscribers
  • Views 561 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.

CC1352R: MAC Layer hangs if it is busy and receives a disassociate indication to its extended address.

Jean Fontena
Prodigy 190 points
Part Number: CC1352R


Hi. I'm using a CC1352 with SDK version 3.10.01.11 and running a modified version of the sensor example project with a coprocessor. My setup uses a non beacon mode network and I'm using only the extended address (0xFFFE assigned as short address after association) to send messages to the sensor. I have been using the following workflow to perform some experiments:

  • Sensor is scanning networks;
  • A coprocessor starts a network;
  • Sensor receives a beacon indication;
  • Sensor tries to associate;
  • Coprocessor accepts the association request;
  • They exchange data for some time;
  • The coprocessor sends a disassociate request to the sensor;
  • The sensor disassociate itself and the process starts again.

Sometimes the coprocessor sends the disassociate request, the sensor receives it, but the coprocessor sends it again because an acknowledgement wasn't received. The second `disassociate request` the `coprocessor` sends might arrive while the `sensor` is busy performing some other operation (like waiting a associate indication callback to be called) and when it happens, the MAC layer just stops working: the association indication callback is never called. Every following call to `ApiMac_mlmeScanReq` returns `ApiMac_status_badState`. This situation only happens when the coprocessor uses the extended address to send data to the sensor. If the short address is used, the problem never happens because the MAC Layer clears the sensor short address when the first disassociate indication is received, so the sensor never receives the second one. We've already tried to call `ApiMac_mlmeResetReq(false)` when an `disassociation indication` is received, but it didn't solve the problem. Summarizing: if the MAC layer is busy performing some operation and the sensor receives a packet destined to its extended address, the callback for the operation being performed is not called and the MAC layer starts returning `ApiMac_status_badState` for the next function calls. Is it a known bug? How can we solve that?

To reproduce the problem, it is enough to send multiples disassociation requests to the extended address of the target sensor. As soon as one of them is received when the MAC Layer is busy, the MAC layer stops working.

  • 0
    TI__Mastermind 35070 points

    Hi,

    Have you considered doing a soft reset on the sensor (eg. SysCtrlSystemReset)?

    Why use the extended address rather than the short address?

    Can you share the following during the process?
    - sniffer log
    - application log (UART output from sensor)

    Regards,
    Toby

  • 0 in reply to Toby
    Prodigy 190 points

    No, we haven't considered calling SysCtrlSystemReset() because it doesn't make sense. It would probably solve the problem, but we would need to always check if any call to an ApiMac function returns an error code and then reset the sensor. Resetting the sensor isn't cool. We started the development using the short address, but it led us to another problem: sometimes the coprocessor would send an association response with the short address, the sensor would receive it, but the coprocessor would miss the acknowledgement for this frame. So the sensor would believe it was connected and the coprocessor would believe it wasn't. 
    I don't have any sniffer logs or application logs with me now and it would take me some time to generate them. Couldn't you reproduce the problem by your side? I've shared the exactly process (with specific versions) you need to follow to do this.

  • 0 in reply to Jean Fontena
    TI__Mastermind 35070 points

    Not yet, have you had time to gather logs (sniffer and application)?

  • 0
    TI__Mastermind 35070 points

    I was not able to reproduce this issue with the default examples (only modification was using extended addresses)

    Any other modifications you've made on the sensor project?

  • 0 in reply to Toby
    Prodigy 190 points

    Hi, Toby.

    Thanks for the effort. Yes, there are other changes we've made on the project, like removing the Orphan state or Sync loss related stuff. As a said before, the sensor only goes through the following states: scanning networks, trying to associate, associated, disassociated. Anyway, we are working on a minimal example to reproduce the problem and we'll open a new question and link to this one as soon as we have that. Feel free to close this thread.

    -
    Jean