• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 53 subscribers
  • Views 1060 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.

CC1352R: CC13x2 flash limitations?

Daniel Singer
Intellectual 320 points
Part Number: CC1352R
Other Parts Discussed in Thread: CC1310

I was alarmed to see this in section 8.5 of the CC13x2 technical reference manual (SWCU185D–October 2019)

There is a restriction on how many write operations are allowed to a FLASH row between erases. A row is comprised of 2048 bits (or 256 bytes). The FLASH memory is divided evenly into physical rows. One may perform a maximum of 83 write operations within a row between erases. If more than 83 write operations are performed before re-erasure, one may see unwritten bits in the row that are erased (in a logic 1 state) become programmed (change to a logic 0 state). User software must take care of this restriction, there is no hardware that checks and informs if this restriction is violated.
 
 
Ordinarily, it should be reasonable to write individual zeroes into flash without limitation, as is typically done to tally events or maintain completion bitmaps of file transfers, etc. We do this now with our CC1310 projects (the CC1310 TRM doesn't speak of this limitation). Is it really true that we cannot use bitwise zeroing like this on a CC13x2 without quickly running up against this 83-cycle limit? If that were the case, we would have to re-erase an entire 8k sector when just 83 of 2048 bits had been cleared. That seems unreasonable and would consume flash cycle life at a vastly accelerated rate.
Separately, but related, does this count of 83 represent the number of bytes modified, the number of times FlashWrite() from DriverLib is called (with perhaps a multi-byte payload, possibly spanning rows), or some other metric? The passage in the TRM is ambiguous about what, precisely, counts as an individual "write operation" to which this limit of 83 applies. Surely it can't mean that we can only write 83 bytes of a 256-byte row before having to erase them, otherwise we could never fully program the flash. 
  • 0
    TI__Guru**** 317180 points

    I will reach out internally to get more details on this.

  • 0 in reply to TER
    TI__Guru**** 317180 points

    From the CC1352R datasheet, 8.7:

    "Each wordline is 2048 bits (or 256 bytes) wide. This limitation corresponds to sequential memory writes of 4 (3.1) bytes minimum per write over a whole wordline. If additional writes to the same wordline are required, a sector erase is required once the maximum number of write operations per row is reached."

    From an internal resource:

    "For CC1352R, the minimum writable word is 32b.  With that limit, the customer will never hit the 83x limit.  If they are doing bit-wise operations, they will have to limit the # of words used per wordline."

    Hope that made it a bit clearer. 

  • 0 in reply to TER
    Intellectual 320 points

    Thanks for the clarity. We do indeed perform bitwise operations for the purposes of keeping tally counts, so we will need to be mindful of this.

    A follow-up question: can we expect any failures which result from exceeding that 83x limit to manifest immediately and be restricted to the wordline in question? If we simply read back what was just programmed and compare it against what we think we just wrote, can we detect the failure immediately, which we can use to motivate caching the whole sector, erasing it, and re-writing it, along with our new data? This would allow detection-based mitigation rather than having to count anything. The problem we wish to solve is not having to count writes to the flash, since that, too, requires non-volatile storage which would be subject to the same limitations, causing a recursive problem. If we can simply respond to detected failures with a cache-erase-write cycle, our driver can be simple and will have no need for out-of-band storage.

    Sure, we could simply count the written zero bits and when they get to 83 perform an erase cycle, but we don't always write the bits one at a time so simply counting them % 83 would lead to more erase cycles than strictly necessary. Even so, assuming the limit is near 83, whether in practice we might get 85 or 100 sometimes before detecting a failure, this limit reduces service life considerably, since we'd ordinarily not erase the bits until the erase unit was full. In the case of a CC13x2 with 8k sectors, that's 64k bits being erased every time 83 bits were written... or 789 times more often than would be necessary if we could write each bit sequentially, then erase the whole block when full.

    This limitation is not documented in the CC1310 and I've never heard of such a thing elsewhere - what changed to introduce it in the CC13x2 family?

  • 0 in reply to Daniel Singer
    TI__Guru**** 317180 points

    CC13x0 and CC13x2 uses slightly different technology and hence this limitation is not present on CC13x0.

    I have to check some more internally to cover your questions in full. Do you use our driver or something else to write to the flash? Since as I understand it the have to write 32b at the time and then you should not be able to hit the limit. 

  • 0 in reply to TER
    Intellectual 320 points

    We use FlashProgram() which takes an array of bytes - but sometimes we send just one byte in, with just one bit changed from what was there, to accumulate zeroes in flash as a nonvolatile counter, with each byte capable of storing a count from 0 to 8: FF (count is 0), FE (count is 1), FC (count is 2), F8, F0, E0, C0, 80, 00 (count is 8). Obviously, individually writing zeroes to the same byte means a total of 8 program cycles per byte, blowing past that 83 cycle limit shortly after 10 bytes have been zeroed (80 bits = 80 write cycles), long before the 256 bytes in the row have been used. We then would need to erase the entire 8k sector to reset that cycle counter, re-write a baseline cumulative count value, and resume the count. It is certainly doable, but definitely means a lot more erase cycles than necessary or we waste 246 bytes of every 256 (a utilization of just 4%!), since we'll have just about exhausted a row's write-per-erase limit (83) after 10 bytes worth of counts (80 cycles). 

    Clearly, we will need to revise our counting scheme to use some kind of wear-leveling algorithm to work around this limitation. Fortunately, the 13x2 has a lot more flash available to the developer, so we have considerably more room to make this work.