• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 55 subscribers
  • Views 1521 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.

Quick question on CC2530 flash page lock and debug bits

Andrew Bakin
Expert 1665 points

Other Parts Discussed in Thread: CC2530, Z-STACK

Hi,

My application saves same sized data to flash periodically. It then retrieves data from flash treating it as one continuous address range. My development has been well within the 2048 bytes of one flash page and it works well.

Now I need to expand to use more pages of flash (not considering going across block boundaries just yet). I understand I need to handle writing across flash pages in my application, but reading across them using osal_nv should be fine, but I have discovered that each page has 16 bytes of lock and debug bits at the top (section 2.2.3 of cc2530 user guide) meaning I cannot read or write in 2048 byte chunks. More importantly, my data will be split up.

Can someone kindly confirm that every page in flash has these 16 bytes leaving only 2032 bytes per page before I start rewriting all my code to handle none contiguous storage?

Many thanks,

Andy

  • 0
    TI__Expert 3050 points
    Hi Andy,

    You will probably be glad to hear that this is not the case. As the user guide says, "The 16 bytes of the upper available page
    contain page-lock bits and the debug-lock bit" - what this actually means is the last 16 bytes of the last flash page. All the rest of the flash pages do not have any such "special bytes", and you can freely use them contiguously.

    Best regards,
    OD
  • 0 in reply to OD
    Expert 1665 points

    Thanks OD,

    That is good news. The reason I doubted it was because when initialising a page with a full 2048 bytes I don't read back what was expected. When initialising with 2032 bytes it works well. May be a coincidence or may be my app is writing to page 7: the information page.

    I currently don't understand how flash pages are allocated by osal. If I have the following NV items:

    #define NV_DATA_VALID 0x0401 //2 bytes
    #define NV_HISTORICAL_STATE_SAVE 0x0402 //10 bytes
    #define NV_HISTORICAL_RAM_STORE 0x0403 //512 bytes
    #define NV_HISTORICAL_DATA_PAGE_0 0x0404 //2048 bytes
    #define NV_HISTORICAL_DATA_PAGE_1 0x0405 //2048 bytes
    #define NV_HISTORICAL_DATA_PAGE_2 0x0406 //2048 bytes
    #define NV_HISTORICAL_DATA_PAGE_3 0x0407 //2048 bytes

    where the PAGE_X are full 2048 bytes, and the first three are smaller chunks, how does osal determine what goes where? Can I force the first three items into one page?

    I am investigating the osal code but it's great to know I don't have to change my core functionality.

    Many thanks,

    Andy

    Edit: It seems OSAL has its own software implemented header on every page: osalNvHdr_t and osalNvPgHdr_t which are eight bytes each. 16 bytes in total. This creates the same problem I thought I had in the first place albeit for a different reason. 

  • 0 in reply to Andrew Bakin
    TI__Expert 5255 points

    As you described at the end of your last post, the OSAL NV driver has some overhead in the use of flash memory. Each flash page used by the NV driver has an 8-byte "page header". In addition to that, each individual NV item has an 8-byte "item header". So, the largest data block that could be saved on an NV page is, as you observed, 2048 - 16 = 2032 bytes. I believe that the driver supports "logical" pages configured using 2 physical pages, so you should be able to create NV items of 2048-byte size which would be stored in parts of two pages - normally that is not a problem, the NV driver handles all of that behind the scenes. The NV driver figures out where to place items dynamically based on available space on active pages. The driver does not support user placement of items in specific locations.

  • 0 in reply to xyzzy
    Expert 1665 points

    Thank you for your information. I have rewritten my code to use NV items sized at 502 bytes on the basis that four items will fit on a page with no wastage, and it's advisable to limit an NV item write to around 500 bytes (as it is a blocking function I suppose).

    4 * (502 + (8 byte item header))  =  2040 + (8 byte page header) = 2048

    If I have the default 6 pages of NV available on my CC2530 z-stack code then I should be able to save 5 pages (5 pages of 2008 data bytes per page  = 10040 total data bytes), plus one page for other application data.

    On this basis, I expect this to be the most effective way to store large data without the need for any compaction as there are no free bytes on a page, and there is room for the item and page headers.

    Thanks,

    Andy 

    Edit: after testing it seems that I cannot store more than 3 pages of NV data and successfully read it back- the data simply stops getting written beyond 3 pages. I expect this is because the NV driver's flash 'even wear' algorithm requires some free space to play with. I think my next job is to increase the number of pages available to more than 6, whilst staying with the 32KB block.