• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 56 subscribers
  • Views 544 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.

INVALID_PARAMETER after spamming commands.

Ayman Hammou
Intellectual 330 points


Hi,

Hardware: CC2562P Sonoff dongle with Zstack 3.X,0

I've run the following test: sending a lot of packets, every seconds, to the dongle to control some lighting devices.

Result: After some time AF_DATA_REQUEST_SRSP returns with status 0x11 ( BUFFER FULL) and as I keep spamming commands, the dongle goes silent and stops responding to my AF_DATA_REQUEST ( I don't receive any AF_DATA_REQUEST_SRSP back) but after some time it returns alive and starts responding with status 0x02 (INVALID_PARAMETER) to all commands.

Any idea on why of this behaviour?

  • 0
    Guru 735695 points

    You shouldn't send too many packets every second. It's recommended to send packet with some intervals in between.

  • 0
    TI__Guru**** 220027 points

    Hi Ayman,

    As indicated by the status errors, requesting too many packets to be transmitted is causing the MAC buffer to fill and instigating further memory issues.  If this happens by accident then I recommend using a SYS_RESET_REQ to restart the ZNP.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Intellectual 330 points

    Hi Ryan, Yikai,

    I've came across a way to replicate my problem fast:

    As the commands are being spammed everything works fine until I remove one light bulb and this causes the DONGLE BUFFER FULL error after a couple of seconds.

    Any idea of why of this?

    I have the following theory: Since it cannot find the removed light bulb the messages, sent to it, are being stored in the dongle longer and this causes the dongle buffer to become full.

  • 0 in reply to Ayman Hammou
    TI__Guru**** 220027 points

    Refer to the Network Configurations section of the Z-Stack User's Guide.  NWK_INDIRECT_MSG_TIMEOUT (default 7 seconds) determines how long a message is held while waiting for a ZED to poll.  ZMAC_MAX_FRAME_RETRIES and NWK_MAX_DATA_RETRIES indicate MAC frame and NWK layer retries, respectively.  If an active entry cannot be found in the routing table or using an entry failed after the maximum number of retries, a route discovery is initiated and the packet is buffered until that process is completed.  You could increase NWK_MAX_DATABUFS_* inside nwk_globals.c but that may only delay the issue.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Intellectual 330 points

    Any idea on how to avoid this to happen? 

    I've set a sleep for 10 seconds, before writing anything, after I receive a buffer full ( 0x11 ) status, but with no avail.

    i tried a SysSoftReset and BDB Commissioning to restore the network, with no avail.

  • 0 in reply to Ayman Hammou
    TI__Guru**** 220027 points

    You avoid this issue by not spamming commands to non-responsive devices.

    Ayman Hammou said:
    i tried a SysSoftReset and BDB Commissioning to restore the network, with no avail.

    Can you please explain what you mean by this?  Issuing a reset will clear the buffer issue, and NV retention will restore the prior network settings.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Intellectual 330 points

    I run a SYS_RESET_REQ with type=soft reset and after i restore the network via bdb commissioning, all of this while spamming commands. 

    After the network restore no problem for a couple of seconds and then buffer fulls again.

  • 0 in reply to Ayman Hammou
    TI__Guru**** 220027 points

    This is the expected result.  You will need to stop spamming commands or modify the ZNP project to ignore spam commands from your host.

    Regards,
    Ryan