CC2430 Flash endurance with NV items (non-volatile memory)

It is in practice the number of erase cycles per page that is limited to 1000. This means that you can write to a page many more times than that as long as you don't write to the same bytes. The NV algorithm in the ZStack takes advantage of these two points to ensure long lifetime of the flash:

- Two or more pages are used to ensure wear sharing between pages and robustness against power failures during updates

- Each page is used to its full capacity before it is erased

Each time an NV item is written to flash it is written sequentially after the last entry in that page. The last written item of any type in the active page is the valid one.

When the page becomes full, only the valid items are written to a new page and the old page is erased.

This ensures very long lifetime and robustness.

Hello Peder,

Are there any plans to increase the endurance of the flash erase?  This could be useful for devices placed into more dynamic data environments.

Best Regards,

JT

This has been done for the cc2530 where the flash endurance is increased to 20 000 erase cycles.

See the cc2530 user guide chapter "2.2.3 Physical Memory"

Hello Moe,

Thanks for the reply.  It is much more capable than what we need, but the flash write endurance has become an issue for our customer.  I assume that the CC2510DK bds are compatible with the CC2530EMK .  Also are there any software portability issues or other gotchas that you might want to share if we swap parts.   I have not read the datasheet and probably won't in the next few weeks since we are fully engaged in getting a 2510 design out the door right now, but will we be able to assign the GPO register on the radio to get sync valid out? Thanks in advance for your attention.

Best Regards,

Jack Thiesen

I think this document summarizes what you need to know when changing from the cc2430 to cc2530:

CC2430 to cc2530 migration guide: http://focus.ti.com/lit/an/swra287/swra287.pdf

Thanks for the reply.  However, I'm not sure you answered even one of my questions unless the 2430 is the same as the 2510 (which of course would beg the question why the 2430 is not designated as a 2510).  Let me enumerate the questions to make it easier.

1. Are the CC2510DK bds compatible with the CC2530EMK or will we need to order additional boards ?

2. Are there are there any known software portability issues or other gotchas that you would be willing to share if we swap parts?  I care because we have a substantial amount of code built around the 2510 that we will need to port.  We are still in evaluation and will be performing field tests comparing several similar parts that have been developed in parallel.  Difficulties in porting software are an important consideration before a final downselect.

3. Can we assign the GPO register on the radio to get sync valid out? For us this is a critical concern and the only reason we chose the 2400 parts to begin with.  It seems as though someone should be able to provide a definitive answer to this.

Given the response to most questions here from TI employees I get the impression that the respondents are not FAEs and that rather than spending a few moments to find definitive answers to simple questions, that they would prefer to refer someone to what appears to be a massive but somewhat disorganized collection of documents, that may or may not be pertinent. However, a very large amount of bandwidth appears to be devoted to helping people debug software so maybe this site is just run by programmers and is not a place for product questions.

The documentation is a mess. Several of the engineers who worked for me complained about it and I have been working with the product myself  and fully concur.  The person attempting to set up a DE has to wade through what appears to be a randomly organized collection of unsorted documents looking into multiple zip files until they find the files that contain the software items they might wish to use.  The datasheets appear to be spread out over parts within families and now across families. For instance when reading the 2510 datasheet how would one know that they should read the 2500 datasheet for additional facts.  In fact why would they suspect this?  Or who would suspect that migration questions for the 2510 would be found in a 2430 migration guide. (Which I personally doubt I think you just slapped down an answer to see if you could shut me up.) But, I believe that the reason that  FAEs exist is to sort through confusing documents and make the knowledge within accessible to improve the chances of a build-in win.  In my experience, a good FAE goes out of thier way to assist  in providing quick and courteous responses to questions that pertain to the business side of engineering.  Although in the past I have had FAEs from your competitors assist in code or design development  this not our typical expectation. 

But, perhaps this 'site' is not where such product questions are to be answered.  If not, I apologize for asking and would like to know where the FAEs responsible for the CCXXXX products reside so that I may contact someone who, either, has the expertise or the willingness to answer straightforward questions that are important when build-in decisions are being made.

Sorry if I did not answer your questions. Of course the cc2510 is not the same as the cc2430, I guess the the confusion arose as the thread is on cc2430 flash endurance and I the concluded that you were using cc2430 today and then were asking about swapping to the cc2530. My apologies.

Let me try to answer your questions:

1) The Smart RF Evaluation board found in the cc2510DK is compatible with the CC2530EM (found in the cc2530EMK). However the pin out is different so you will observe e.g. the GPIO signals on other pins on the evaluation board

2) A lot of your code will have to be rewritten when changing from cc2510 to cc2530. The peripherals has been updated with new functionality, and the radio part is completely different. I do not know of any difficulties as such with porting code, but the devices are from two completely different families.

3) You can configure a GPIO to give sync valid out on the cc2530. However this signal will go high whenever sync word is sent and when sync word is received. You will have to combine it with the RX_ACTIVE signal if you want to filter out the sync word sent events.

Did this help?

Thank you very much that was extremely helpful.  If I may, I would like to ask a few follow-on questions.

1.  If GPIO appears on different pins, I assume that this is covered in the 2530 Dev guide.   Is it easier to just buy the 2530DK or is it essentially the same as the ones we currently own.

2. For our purposes we are only using two peripherals right now, the DMA controller for flash write and the SPI.  For the purposes of a quick test we basically modified the TI example code and added the functionality we needed to demonstrate capability.  In many ways we have found the code to be extremely acceptable, with a few reservations about the depth of certain macros.  The question is: is there separate SPI and DMA flash code required for the 2530 than that which we used for the 2510?

3. We are using the MRFI which we will meet our testing needs. We may use a more sophisticated protocol when we move to product development, but that is not clear.  However, I would have assumed that even if the radio changes, that the MRFI  ports easily from device to device.  Am I incorrect?

I apologize if I was harsh, but we are very much under the gun here.  We like many of the aspects of your parts and the fairly substantial body of developed software (although it would be nice if it were easier to sort through) and the various protocols you have available.  Thank you for answering the questions.

Best Regards,

JT

1) I double checked the compability between cc2530EM and the cc2510dk and I need to be a bit more precise. The cc2530 will be compatible with the cc2510dk. If you use smartRF studio you need to use the latest smartRF studio software. It will work with the flash programmer and IAR. However all example applications for the cc2530 assume that it is connected to a smartRF05 board (the one in the cc2530dk) so IO mappings will need to be updated.

2) The DMA controller and SPI are very similar between the cc2510 and the cc2530 so changes in code for using these should be small. However due to different crystal frequency between the cc2510 and the cc2530 timing on the SPI will be a little different. The flash controller has a few changes from the cc2510 to the cc2530, word size is increased to 32 bits and new flash controller register mapping etc. A side by side comparison between the cc2510 data sheet and the cc2530 user guide should give you all the details.

3) I do not know MRFI unfortunately

Thank you very much.  I have ordered the DKs and look forward to seeing what happens.

Best Regards,

JT

Thank you again,

Just to close this thread, The port went very well, moved ~ 10k lines of code and test software over without too much hastle.  

 I suppose that the major difference from our point of view was the difference in memory addressing between teh two parts, specifically the difference between Code and Xdata when using banked memory,large model during compile.  This caused us to change all of our flash read addressing, there was a nice hint on your boards for this.  For others like us, who are less familiar with operating the 8051 in banked memory mode a more prominent note of this could be helpful.    Also a note regarding the elimination of the need for 2-byte alignment in the 2530 and thus the elimination of the need for the assembler routines provided in the 2510 DMA/Flash read could be helpful for anyone migrating from the 2510 to the 2530. 

The documentation appears to be better organized for the 2530 and the  part is much better.  All in all the change appears to be all good. Thanks again.

Best Regards,

JT