• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 56 subscribers
  • Views 740 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC2530: OTA - Image block response not being sent

MSantos
Intellectual 360 points
Part Number: CC2530

I'm having a strange behaviour on our OTA server and I'm not finding the reason for it to happen.

Sometimes when I try to send an Image Block Response with the function "zclOTA_ProcessFileReadRsp" nothing is send to the air.

After a bit of debugging I found out the problem is in the function "APSDE_DataReq" (inside "AF_DataRequest") returns "ZMemError". What are the situations when this function return "ZMemError"?

I noticed it happens if the end device changes parents 2 or 3 times in a short time (smalled than the child aging interval) even though I'm still able to comunicate with the device for the remaining messages.

I also checked if there was an heap overflow, but when it happens only 1300 bytes are being used and the heap size is 3072 bytes.

Did this happen to anyone in the past?

  • 0
    Guru 735545 points
    I suppose you call AF_DataRequest too fast and causes this ZMemError. Try to slow down while you call AF_DataRequest.
  • 0 in reply to YiKai Chen
    Intellectual 360 points
    Thank you for the reply but I'm not sure I get what you mean.
    The flow is:
    "Image block request" -> "Image block response"
    Nothing is sent in between aside from the regular stack functionality that I don't control.
    What can I do to slow it down?
  • 0 in reply to MSantos
    TI__Guru**** 208977 points
    Try using a periodic event and always check the return status of AF_DataRequest (definitions in AF.h).

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Intellectual 360 points
    I think I'm more or less capable of reproducing the problem now and I don't think it's a timing issue. I say this because each "Image block request" retry occours every 5 seconds and I get consecutive failures (about 8) until the device being updated just gives a abort.
    To me the problem is the routing table that for some reason is not working well. If I do a power cycle to the device being updated everything works fine afterwards and I start seeing the message on ubiqua.
    Sending "leave with rejoin" fixes the issue, but sadly not all devices in the client support this and asking someone to do a power cycle is a unfeasable since it's a lot of units.
    Is there a way I can force an entire routing table update? I tried the funtion "NLME_RouteDiscoveryRequest" but it doesn't seem to do much...
    I'm a bit stuck now and without new ideas to try
  • 0 in reply to MSantos
    TI__Guru**** 208977 points
    I don't think the routing table is involved but it is interesting that the devices seem to hang up, can you debug a project to explore this further? Do you have a sniffer log to provide? Have you tried evaluating with the OtaServer GUI and example switch projects? Please refer to the following E2E posts:

    e2e.ti.com/.../680983
    e2e.ti.com/.../690812
    e2e.ti.com/.../688108

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Intellectual 360 points
    Thank you for the links but I didn't find anything there that would apply to my scenario.
    The best solution I found to mitigate the issue is to reduce the OTA payload. And it seems to work a bit more reliably.
    It seems to be worst when the RSSI level is quite low. I was using a payload of 64bytes now I'm using 32.