|
|
ADSP 21xx 
Have you found this site useful? Did we save you time? Did we cure your head-ache? Is your hair growing back now? Please make a donation to help with maintenance. |
Objective Real-Time Software on the ADSP21XXRead and Write Flash Memory using the BDMA PortGeneralFlash memory became immensely popular, due to its low cost. It only requires one transistor per bit and Intel recently reduced it to 1/2 a transistor per bit, using a special multiplexing technique. This low cost does however have a major drawback, in that the devices are awkward to use, since they require special sequences of commands to activate the erase or program logic (There has been a big improvement on the original flash memories however, which were well nigh impossible to program!).
Memory devices from various manufacturers have different control logic, but there is sufficient similarity, that a generic algorithm can be constructed, which will work with most devices. The routines to read/write the AMD 29F010 flash memory which is discussed in this chapter, are on the CD-ROM in directory work\eeprom and work\eeprom\inc. These routines will work with most flash devices, but a memory databook is required reading, whenever you use a new part. A driving reason behind using the AMD device, is the page size of 16 kilobyte, which corresponds exactly to the BDMA page structure. Therefore, a flash memory page and a BDMA page can be considered to be the same thing, for the remainder of this chapter. TimingThe most important thing regarding flash memory devices is timing. These devices are sloooooow... It is therefore advisable to set the processor BDMA logic to its maximum number of wait states. As a rule of thumb, the memory device needs to be 5 to10 times as fast as the cycle time of the processor (If you want to be exact, you need to read a databook on the processor). If the DSP runs at 16 MHz, it is 1/16 million second per cycle = 62.5 nano second per cycle. In order to be 5 times faster, the memory needs to be rated at 12.5 nano seconds. A quick look at a flash chip lying here on my desk shows that the device is rated at 120ns. Oops! Even at 7 wait states, our rule of thumb shows that we are treading on thin ice... Objective StructureOur old friend H.Acker with his loosely structured code, has serious difficulty with this flash memory chip. The AMD 29F010 is a page addressable device, with 8 pages of 16 kilobytes (0000H..3FFFH) each, for a total of 1 megabit, or 128 kilobyte. This paged structure enables one to erase one or more pages at a time, while leaving the rest of the chip intact. This forces one to think carefully where one has to put what. It is advisable to put the code contiguously in the lower pages, starting from page zero, since the default loader in SPL21.EXE can then be used with good effect. Persistent variables consequently needs to be clumped together somehow and saved in one of the upper pages. This clumping together, kind of looks like an object structure doesn't it? Undaunted, H.Acker immediately sets about writing an extremely complex set of routines, to save all his scattered variables in a single flash page...
Typically, the persistent variables in a DSP system will be small in number and will be updated very infrequently, usually during a special setup session to configure the modem or data recorder, or whatever gizmo you have, after which they are pretty much left alone. Therefore it is not usually required to create a fancy flash file system, unless one is building a solid state disk drive, in which case that is inevitable. In most cases, a simple block read/write cycle will suffice. Many programmers are perturbed by the 100000 guaranteed program/erase cycle time of a typical flash memory. To put this figure in context, consider that it represents 15 changes per day, every day, for a period of 20 years, which in most cases is nothing to worry about. If the system would write to flash memory every time it is powered up, the memory would outlast the power switch. Example 1 shows the definition of an array object which can be saved to flash memory whenever something is changed. Typically, one will allow the user to edit the RAM based array and when she exits a setup menu, go and write the whole object to flash memory in one go. We therefore only have two public procedures: rom_read and rom_write, which do not even require any parameters, making them as easy to use as it can possibly be. This being in stark contrast to H.Acker's multiple read/write and update method.
Read CycleReading a flash device is straight forward, except that in this case, we need to use the BDMA port for all accesses of the byte wide EPROM. This is kind of awkward, but if you can perform a boot load using the BDMA, then consider that writing is simply the opposite direction. Example 2 shows the code required to read the non-volatile memory object from flash memory, via the BDMA port, into RAM, where it can be accessed as normal.
Erase CycleBefore one can program a flash memory device, one first has to flash erase it (Yep, that is where the name comes from). Example 3 shows the erase code. The trick is to disable interrupts while we are performing time critical activities.
Most flash devices have internal timers which typically time out in about 80 microseconds. So, one has to ensure that a program cycle is completed in one operation, otherwise the device may revert back to read mode and whatever we wanted to do, won't work.
The flash device requires us to write an unlock code to it, before we can give it a command. This is a two cycle affair. First we have to write AAH to address 5555H, followed by 55H written to address 2AAAH. This presents a slight difficulty, since address 5555H is larger than the maximum page address of 3FFFH. This means that we cannot simply write to page zero, but has to write to address 1555H in page 1 instead. After this tricky business, we have to write the erase command 80H, followed by the sector erase command 30H. Note that the sector erase command is written to the page that we want to erase, in this case page 5. Once we have completed the command sequence, we have to wait for the flash memory to go and do its thing.
The memory device signals that it is busy, by toggling a data bit every time we read it. Therefore, as soon as two consecutive reads are the same, we can proceed. The trick is to wait at least 80 micro seconds, before polling the device. For some unknown reason, the page erase function will occationally fail if one would start polling too soon. This finicky timing only occurs in the page erase cycle. The chip erase (not shown here) and byte programming functions do not suffer from this hiccup. Write CycleFinally, after erasing the page, we can write new data to it. Example 4 shows the code required to save the non-volatile memory object. Writing is the art of turning ones into zeros. Only the erase cycle can turn zeros into ones.
An attempt to write to an unerased byte, may cause the chip to hang up and go into powerdown mode, which will require a system power reset, to get going again.
The procedure is much the same as for the erase cycle. First we have to issue the two step unlock sequence, after which we can issue the write byte command, by writing A0H to address 5555H, followed by a single data byte. We then have to wait for the EPROM to finish doing its stuff, before we can go through the whole rigmarole again, to write the next byte.
Note that for simplicity, we omitted all error checking. It is therefore possible for the processor to get stuck in a loop. However, since the DSP code is saved in the flash device, it probably won't be able to get started if the memory is broken, so it is largely a moot point. However, if you are working on a critical application, such as a nuclear missile, we'd appreciate it if you would nevertheless add some error checking... |
|
Copyright © 1996-2008, Aerospace Software Ltd., GPL. |