1
\$\begingroup\$

I'm working on an application involving NOR flash chips. I had to switch chips halfway through the design process. The stated differences between the new and old chips are only 'Device ID' and 'sector erase time'. I thought I could get by without rewriting my flash driver given the small differences, but the driver for the old chip doesn't work with the new one.

Why does the sector erase time matter so much for the driver? How do I change it?

\$\endgroup\$
  • 1
    \$\begingroup\$ We will need at least the following information: old/new flash chip part numbers, what platform are you writing the driver on/for, can you show us the driver code, can you provide any datasheets for the chips? \$\endgroup\$ – AngryEE Apr 5 '12 at 15:07
  • \$\begingroup\$ When you say "my flash driver", is it something you wrote? Do you have source code for it? It should be fairly easy to check if the code is looking for the specific device ID of the older chip. It's very common for software managing flash to explicitly check device IDs. \$\endgroup\$ – darron Apr 5 '12 at 16:47
1
\$\begingroup\$

The sector erase time matters to any driver because it is a bit of timing that is necessary to use the chip correctly. Flash chips have erase times, which is how long the special erase voltage must be applied to the cells to guarantee they are erased. If this minimum time isn't met then cells may not be fully erased, which is in effect a data error.

Some chips may also have a maximum erase time. Some chips require the external hardware to perform erase timing, others perform internal timing and set a status bit when erase is complete. In that case a driver would either have to wait the maximum possible erase time, or poll the bit to ensure erase has completed before proceeding to other operations.

As with any specification, violating it means that none of the other parameters can be relied on any longer. If this chip self-times erase and sets a bit when complete and the existing driver polls this bit to determine erase completion, then no modification to the driver should be required.

In any case, thinking you can "get by" violating a spec just because it's only off a little is very very bad practise and you should be ashamed of yourself for even considering it.

\$\endgroup\$
  • \$\begingroup\$ How many flash devices have you used where software had to worry about erase timing for anything other than timeout determination? I can only think of one: the internal flash on a TI DSP. Every single other flash device I can think of that I've ever used has had self-timed erase cycles. Are you aware of any standard "standalone" flash chips which do not have self-timed erase? \$\endgroup\$ – supercat Apr 5 '12 at 16:19
  • \$\begingroup\$ Probably all large flash chips do internal timing. When you program the program memory of some PICs via a external programmer, the programmer has to perform the timing in some cases. Or, it's faster if the programmer does and can do it accurately because the chip has slop in its oscillator so the nominal time is longer than needed. There is often a maximum spec for the internal erase time, so a driver could conceivably do its own timing without checking. \$\endgroup\$ – Olin Lathrop Apr 5 '12 at 17:56
  • \$\begingroup\$ From what I've seen, Microchip's OTP parts relied upon an external programmer to time programming pulses, but its flash-based parts are all internally timed; I vaguely recall some flash-based PICs might have allowed an external programmer to control flash-write timing, but don't remember any hint of control over flash-erase timing. \$\endgroup\$ – supercat Apr 5 '12 at 18:34
  • \$\begingroup\$ BTW, one feature I remember from the DSP that allowed software control of flash timing was a feature to select one of three "read" thresholds, to allow the CPU to distinguish bits which were fully erased, mostly erased, mostly programmed, or fully programmed. One could thus determine whether a range of memory had any potentially-marginal bits. I know that error-correction and multi-level flash mean that the concepts of individual bits being "partially programmed" aren't meaningful in the same sense as they were on the TI part, but ... \$\endgroup\$ – supercat Apr 5 '12 at 18:38
  • \$\begingroup\$ ...it would still seem useful if flash chips could provide an indication of whether part of a block was marginally written, as a clue that software should try to copy data on that block somewhere else and then, once the copy was complete, erase and recycle the block. \$\endgroup\$ – supercat Apr 5 '12 at 18:48
1
\$\begingroup\$

You haven't mentioned any part numbers, but flash chip manufacturers have over time changed various little details about how their chips work. It's possible your driver has code which uses the device ID something like "If ID=this, use new method, otherwise use method". If the previous chip required "new method", and the new chip has a different ID but also requires "new method", the code won't work because it will try to use "old method". It's also possible that your code relies upon some detail of how the device reports when it's ready. On some old devices, if one was clocking out data and stopped when the device reported its "ready" status, the reported value would change asynchronously when the device finished the operation in progress. On newer devices, if one reads the status and the device reports "not ready", it will continue to do so unless or until one clocks out another status byte.

\$\endgroup\$
  • \$\begingroup\$ I agree on the device ID bit. In my experience, it is VERY common for software to explicitly check device IDs. I think it's more likely the problem is on the device ID side than erase time... although anything is possible. \$\endgroup\$ – darron Apr 5 '12 at 16:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.