CC2530 / CC2531 end device flash endurance while scanning for coordinators

Mark Pointing

Other Parts Discussed in Thread: Z-STACK, CC2530

Hi,

I have a CC2530 Z-Stack energy end device which is going to be installed long before a coordinator is available (possibly years). I have implemented the blacklist feature to ensure I can connect to the correct network, even if it is not the strongest. Instead of using flash, I have put the blacklist in uninitialised volatile ram, and I run a checksum algorithm on it to check if it is valid on boot, if not I initialise the structure.

If the end device is not on a network for 1 minute (indicating it has blacklisted all networks in range) the blacklist is cleared and the device is reset. It will then start again checking all networks in range to see if any have been given the correct link key.

My question is, what effect does this process have on NVRAM network variables? If I restart the scan every minute, do I risk wearing out the NVRAM due to some other network variables being altered in NVRAM?

Thanks for reading.

over 11 years ago

0 YiKai Chen over 11 years ago

Guru 735695 points

What do you mean wear out NVRAM?

0 Mark Pointing over 11 years ago in reply to YiKai Chen

Prodigy 145 points

Hi YK,
Thanks for the reply.

The NV memory flash endurance for the CC2530 is around 20,000 cycles. If my device was to clear the blacklist every minute, over the space of 5 years that would be 2,628,000 writes per network scan. If there are 4 networks in range, this is around 10 million writes. This would destroy the user flash page. What I am wondering is, are there any other NV values that are written during an attempt to connect to a network, because this could also destroy the NV memory over time.

I hope that makes more sense.

0 YiKai Chen over 11 years ago in reply to Mark Pointing

Guru 735695 points

If your application has to write NV flash so frequently, I would suggest you to use external EEPROM to do this.

0 Mark Pointing over 11 years ago in reply to YiKai Chen

Prodigy 145 points

Hi YK,
It is not my application that is writing to the NV flash.

I am wondering if there are Z-Stack variables that are written to flash on attempt to connect.
Are there any?

0 YiKai Chen over 11 years ago in reply to Mark Pointing

Guru 735695 points

I am not sure about how frequently your application would do NV flash write after your modifications. I would suggest you to set a breakpoint in osal_nv_write and check how often it is called during your application does this blacklist thing.

0 Mark Pointing over 11 years ago in reply to YiKai Chen

Prodigy 145 points

That's a surprisingly simple solution. Thanks.

0 YiKai Chen over 11 years ago in reply to Mark Pointing

Guru 735695 points

You are welcome.

0 embRTS over 10 years ago in reply to YiKai Chen

Expert 1125 points

@ YiKai :

I am trying to write in NVRAM using function given in OSAL API's
osal_nv_item_init - The return is not always SUCCESS,
then I am writing one array of data in user memory space // say 0x0403 onward
So it is skipping write_nv_ram ( as return value of init is not SUCCESS )

and then in for reading both osal_nv_itme_init and osal_nv_read worls fine

My question is how this osal_nv_itme_init return SUCESS

Do i need to always initialize it and then write (even if osal_write_nv skips if (return for OSAL_nv_init is not success)

and then only call osal_nv_read function

2nd question - is there really a limitation of 20,000 write ONLY ?

Thanks in advance

0 YiKai Chen over 10 years ago in reply to embRTS

Guru 735695 points

1. No, you don't have to initialize it before write.
2. It should be "Program and erase endurance: 20,000 cycles" but you might still be able to use it after 20,000 write.

Zigbee & Thread

Zigbee & Thread forum

CC2530 / CC2531 end device flash endurance while scanning for coordinators