• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 56 subscribers
  • Views 1004 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.

CC2530: CC2530/ZigBEE firmware issue

Nikolay Isakov
Prodigy 460 points

Part Number: CC2530
Other Parts Discussed in Thread: Z-STACK

Dear colleagues,

One of my customers recently faced an issue. They launched pilot project based on Zigbee (Zstack 2.5.0) in a small town of 400 housings, three different ZigBee networks with different PAN IDs. Each network has different frq channel too and consists of 70-100 routers. All networks worked successfully for 6 months, collecting data for automated energy metering.

But recently they received back all three networks coordinators, because host controller cannot connect to CC2530. After they read back CC2530 firmware and compared to master one, they saw the difference - somehow, firmware inside CC2530 has changed. All CC2530 show different location and different size of "damaged" area, and there are multiple areas inside each chip. All routers still work fine.

Any thoughts here? :)

  • 0
    TI__Mastermind 35070 points

    Hi,

    There are known limitations to using a CC2530 as coordinator, as discussed here.

    Did the CC2530s all fail to connect to host controller at around the same time?

    Was there an attempt to OTA firmware upgrade?

    What regions/locations of flash were damaged? Part of the flash is used for NVS (non-volatile storage).

    I'd recommend them to migrate to a newer version of Z-Stack, as improvements have been made since. Consider the latest Z-Stack for CC2530, Z-Stack 3.0.2.

    Also, the newer stacks include a voltage check for NV writes to ensure the voltage is at a sufficient level for flash writes.
    The following posts may be helpful:

    Regards,

    Toby

  • 0
    TI__Mastermind 35070 points
    Any updates on this?
    Please let us know if you require further support.
  • 0 in reply to Toby
    TI__Prodigy 460 points
    Toby, sorry for missing this.. Some help still required - we've managed to find the reason - power supply gaps during Flash writes. OK. Our NC are on 3 version of SDK, but devices remain on 2nd - hard to update hundreds of devices.
    So, just to be sure that we won't ruin flash on devices too - is there any way to see that CC2530 on 2.5.0 stack writes to flash and we shouldn't reset or turn power off?
  • 0 in reply to Nikolay Isakov
    TI__Mastermind 35070 points
    From the code, it doesn't look like there is a default method to check whether a write to NV is occuring.

    Is the host processor using MT commands to interface with the CC2530? If so, perhaps use the SYS_RESET_REQ command to request the device to reset. The CC2530 will then reset outside of any NV writes.
  • 0 in reply to Nikolay Isakov
    Genius 4540 points
    I think you can set same flag before write to NV and reset after this. And reset you device only software. In this case you can monitor tis flag.