Post Go back to editing

Info: Booting from CFI Parallel Flash - ADSP-21262 or ADSP-21364

The ADSP-2126x & ADSP-21364 DSPs have a multiplexed parallel interface that always reads and writes in 32 bit word increments. This can be two consecutive addresses for 16 bit words or four consecutive addresses for byte wide transfers. You cannot turn off packing and unpacking.

This does not present a problem with reading, but it is a showstopper for writing CFI compliant flash. CFI flash requires that addresses be toggled from x555 to 0xAAA (byte operation) between each 8 bit word for write and erase instructions.

The EZ-Kits use a non-CFI flash, the AMD/Spansion AM29LV081B. The address is ignored (don't care) for all commands, which avoids the 32 bit packing issue. Recently, we heard from a customer that the 29LV081B is EOL (end of life). This is going to be an issue if your design uses on-board programming using a Danville dspFlash programmer or an ADI ICE.

I don't know of any workarounds. As I see it, these are your options:

1. Buy enough AM29LV081B parts to cover your needs. If you know of other current non-CFI flash that will work, we are interested and will add  support on the dspFlash Programmer. BTW, I believe our current support list for the dspFlash is wrong with respect to this issue.

2. Preprogram the flash chip before soldering and don't expect to reprogram later.

3. Migrate to SPI flash. We support most serial devices.

4. Migrate to a newer DSP such as the 214xx family.

Please note this is not at all applicable to newer SHARCs or any of the Blackfins. It only affects the devices with multiplexed parallel port.

Regards,

Al Clark

www.danvillesignal.com

  • Hi Al,

    It is true that in the parallel port on ADSP-2126x and ADSP-2136x, it's not directly possible to generate a series of desired addresses. This is  because of the fact that the accesses always happen in 32 bit words either using 8-32 or 16-32 packing option.  So,  there may not be any software workaround for this situation.

    Having said that, I believe, there can still be a hardware workaround(by using some kind of logic block with inputs as /MSx, A0 (and A1 for 8 bit accesses), and  a flag output to enable/disable the workaround from the DSP end)  possible where one can manipulate the chip select (/CS) signal which goes to the FLASH in such a way that it is asserted only for a specific bus cycle out of the four bus cycles (8-32 bit packing mode) or out of the two bus cycles (16-33 bit packing mode) and thus the rest of the bus cycles can be ignored by the FLASH device. This way one may probably control the sequence of the addresses received by the FLASH device required for the erase and write commands. While, the parallel port can still work normally when the workaround is not enabled.

    Thanks,

    Mitesh

    Message was edited by: Mitesh Moonat

  • I am sure that you could add hardware to achieve the necessary context switching of the addressing. I think you would need several 74 logic parts or a small CPLD, all which add complexity and board space. You would also probably need a spare flag as you suggest. I haven't looked at this interface for a long time. It might also be possible to configure the port as flags and intercept the bus control lines (WR# and maybe CS#). Regardless, the flash burning routines would be very odd and take custom drivers.

    Unless you really need fast booting or the SPI pins are completely unavailable, I would suggest migrating to serial flash. Modern serial flash is much larger (and faster) than the devices available when the 2126x & 2136x parts were designed so I doubt that size would be an issue.

    I haven't tried it, but you might be able to modify the ldr kernel file to reconfigure the SPI port for faster operation. This could speed up the boot time if this is actually important.

    Al Clark

    www.danvillesignal.com

  • Hi Al,

    I do agree with you. Yes, it is possible to reconfigure the SPI port for faster operation by reconfiguring the SPIBAUD regsiter in the USER_INIT section of the boot kernel.

    Thanks,

    Mitesh