• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Answers 1 answer
  • Subscribers 58 subscribers
  • Views 1348 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.

MAC Scan Request yields Bad State status

TyWebb
Prodigy 10 points
Other Parts Discussed in Thread: CC2430, TIMAC

I've got a situation where occasionally when calling MAC_MlmeScanReq() to perform a passive scan, the MAC immediately generates the MAC_MLME_SCAN_CNF event with a hdr.status enumeration of 0x19, which is defined to be MAC_BAD_STATE. Unfortunately, the documentation does not list MAC_BAD_STATE as a possible status for a MAC_MLME_SCAN_CNF. The only reference to this enumeration value is found in the section documenting Proprietary Status Values, and the description of this enumeration is "The operation could not be performed in the current state".

Has anyone else ever encountered this problem.  I don't know how the MAC got into the "bad state" or how to get the MAC out of this condition.  Since I'm out-of-comm and performing a scan, I can afford to be aggressive regarding recovery methods or work-arounds...I just don't know what to try.

Thanks in advance.

  • 0
    Prodigy 110 points

    I've also got a similar problem with MAC_BAD_STATE status when using 802.14.5 MAC API (versions 1.2.1 and 1.3.0) with CC2430.

     

     

    In my case, the MAC_BAD_STATE status related to MAC_MCPS_DATA_CNF event generated in response to MAC_McpsDataReq() call. This happened regularly under the following conditions. 

     

    First, a device was initialized by calling MAC_InitDevice(), and a coordinator was initialized by calling MAC_InitCoord(). Then, the device performed successfuly an active scan and association procedure with the coordinator. After that, the device accomplished successfully several data exchange cycles with the coordinator (both the device and the coordinator used MAC_McpsDataReq() calls to send data and processed MAC_MCPS_DATA_IND events to receive data). After each of the data exchange cycles, both the device and the coordinator switched their MACs to the MAC_PWR_SLEEP_DEEP mode for some time and then, before the next cycle, switched the MAC's back to the MAC_PWR_ON mode.

    All this worked well, without any MAC_BAD_STATE, until a coordinator was switched off unexpectedly, and the device had to repeat its data sending procedure multiple times because it didn't receive any response from the coordinator. After that, the device tried to rescan and reassociate with the coordinator again, but couldn't accomplish this because the coordinator was unavailable. So the device issued several unsuccessful scan and association requests (the association requests were sent, because the device occasionally received beacons from another coordinator which didn't accept association requests from this device) until the coordinator was switched on again and sent an association response to the device's request. Having successfully reassociated with the coordinator, the device tried to send data by calling MAC_McpsDataReq() and at this time it got the  MAC_MCPS_DATA_CNF event with the MAC_BAD_STATE status. From this time on, the device's MAC kept generating the MAC_BAD_STATE in response to any MAC_McpsDataReq() calls.

    At first, I tried a simple solution to the problem by reinitializing the device's MAC every time when I got the MAC_BAD_STATE, and it really worked. However, I wasn't satisfied with such a solution because it didn't actually prevent the MAC_BAD_STATE status but just recovered normal operation after its occurance. So I revised the method of allocating memory for outgoing data messages. Originally, memory for the outgoing data buffer was allocated (as it is recommended in the MAC API documentation) by MAC_McpsDataAlloc() call, but the buffer has never been deallocated because the same buffer was reused for each new outgoing data message. As far as I could see, the buffer was initialized and used correctly, but there was a sentence in the MAC API documentation that gave me the idea that the buffer must be allocated each time when a new message is prepared for sending and deallocated when the MAC_MCPS_DATA_CNF event occurs. So I changed the method of memory allocation accordingly - and this really helped. At least, the MAC_BAD_STATE status didn't occur any more, even under the conditions described above.

  • 0 in reply to Andrei Moldovanov
    Prodigy 110 points

    In my previous post I described a situation in which the MAC_MCPS_DATA_CNF event occured repeatedly with the MAC_BAD_STATE status, and I also wrote that the problem had been solved by allocating a new data buffer before each call of MAC_McpsDataReq(). In fact, this did help to recover after the MAC_BAD_STATE but didn't prevent the MAC_BAD_STATE status occurrence. The actual reason for the MAC_BAD_STATE status occurrence was in the fact that the program eventually tried to send data by calling MAC_McpsDataReq() at the time when a scan or association procedure was running. After those incorrect data sending attempts had been removed, the MAC_BAD_STATE status didn't occur any more.

  • 0 in reply to Andrei Moldovanov
    Intellectual 420 points

    Just to add my problem to the pot... I'm also seeing MAC_BAD_STATE, but this time returned from a MAC_MlmePollReq.

    The MAC will still send out data packets with no problem at all, but within apparently random intervals (I've seen both from power up / only one poll request gets sent, to a few minutes, whilst sending challenges out every 250ms).

    I'm still using TIMAC 1.2.1 - if someone can confirm that this has been fixed in the latest version, we may consider upgrading (since we'd also have to upgrade our IAR license)

    *edit: The workaround I'm currently using is to reset the device

  • 0 in reply to Andrei Moldovanov
    Intellectual 260 points

    [ In response to the message posted by  on 06-09-2010 4:57 AM where he explains he found the root cause for his MAC_BAD_STATE issue]

    Did you then retry to reuse the same buffer rather than always reallocate a new one? Does it work?

    -- Xavier

  • 0 in reply to Xavier Boniface
    Prodigy 110 points

    [ In response to the message posted by Xavier Boniface at 09-07-2010 3:57 PM ]

    Yes, I did return to the previous implementation, where the same buffer was used, and it works not any worse than the implementation in which the buffer was reallocated. However, the MAC_BAD_STATE error is not eliminated completely either by changing the method of buffer allocation or by correcting the mistake in the program described in my previouse post. After the mistake has been corrected, the MAC_BAD_STATE error occurs not as often as it used to be, but it still occurs. So, in fact, the root cause of the MAC_BAD_STATE issue has not been found yet. 

    Our problem was not in the fact that MAC_BAD_STATE error occured, but in that sometimes the MAC sublayer kept generating this error and didn't recover to normal operation. Because we haven't yet found the root cause of the error, we ended up making a software watchdog in the program, that restarts the system in the case when the MAC sublayer is stuck. 

    -- Andrey

  • 0 in reply to Andrei Moldovanov
    Intellectual 260 points

    OK,  thanks for the answer.

    Xavier

  • 0 in reply to Andrei Moldovanov
    Genius 4525 points

    Thanks for this interesting finding. I also have a similar problem, the device drops and tries to re join network (either through orphan rejoin or try another association). The device can successfully receive the coordinator realignment/beacon in MAC layer(confirmed by MAC Ack), but no association request can be issued. so I wonder whether this could be another issue of this MAC_BAD_STATE. And this process will repeat, no successful rejoin will be done in most cases.

    Is this a MAC problem also that lower MAC data can not been processed in higher layer? I have suspected it could be a memcpy overlap risk (see link:http://e2e.ti.com/support/low_power_rf/f/158/p/229913/808130.aspx).

    Any idea?

    Thanks

    Rui

  • 0 in reply to Andrei Moldovanov
    Genius 4525 points

    Can you elaborate more on how is your change on MAC_McpsDataAlloc()? you mention "but the buffer has never been deallocated because the same buffer was reused for each new outgoing data message." I am not sure I follow your claim that "same buffer was reused", since the MAC_McpsDataAlloc() will call osal_msg_allocate() eveytime so I assume every time a new memory allocation will happen.

    But you are right I did not see any de allocation function?

    Rui

  • 0 in reply to Rui Zhang69778
    Prodigy 110 points

    Hi Rui,

    In fact, I have not changed the MAC_McpsDataAlloc function. I've just tried to use the function in different ways with the hope that this would help me to get rid of the MAC_BAD_STATE status.

    At first, the MAC_McpsDataAlloc function was called once during program initialization and the buffer allocated by this call was reused every time when data was sent. In this case there was no need to free the buffer because the same buffer was used for the program lifetime. 

    Then, I thought that this method of using the function was wrong and tried to call it immediately before each data sending (so it was called multiple times, each time allocating a new buffer). In the latter case there was a need to free buffers in order to prevent memory leakage.

    However, as I wrote before, none of these methods helped me to eliminate the MAC_BAD_STATE completely.

    Andrey

  • 0 in reply to Rui Zhang69778
    Prodigy 110 points

    Hi Rui,

    You write that the device receives coordinator beacons and acknowledges them, but no association request can be issued. Could you explain how you know that the association request is not issued? Do you observe this using a sniffer? Or you set a breakpoint on the MAC_MlmeAssociateReq call in your program?

    Andrey

  • 0 in reply to Andrei Moldovanov
    Genius 4525 points

    Yes, I use a packet sniffer and no packet is issued(so precisely I can not see this packet is not issued, maybe it is issued but not transmitted). And of course device can not rejoin successfully.this is very hard to repeat and as far as right now, it happens very rare and we can not repeat in lab.

    I saw your post so I think it may be related to some bad MAC state.

    Thanks

    Rui

  • 0 in reply to Andrei Moldovanov
    Genius 4525 points

    Hi Andrey:

    I don't quite agree with you the "MAC_McpsDataAlloc function was called once", every ZMacDataReq will call MAC_McpsDataAlloc(). right?

    Thanks

    Rui

  • 0 in reply to Rui Zhang69778
    Prodigy 110 points

    Rui Zhang69778 said:

    Hi Andrey:

    I don't quite agree with you the "MAC_McpsDataAlloc function was called once", every ZMacDataReq will call MAC_McpsDataAlloc(). right?

    Thanks

    Rui

    Hi Rui:

    Yes, you are quite right, the ZMacDataReq() function does call MAC_McpsDataAlloc(), but I didn't use the ZStack library in my project, I used the TI MAC directly and called MAC_McpsDataReq() every time when I needed to send data. The first variant of my program was written in such a way that the MAC_McpsDataAlloc() was called once during initialization and then the buffer allocated by this single call was used with each MAC_McpsDataReq() call.

    Best regards

    Andrey