You are here

Boot failure from SPI | Cypress Semiconductor

Boot failure from SPI

Summary: 1 Reply, Latest post by AssemblyRequired on 10 Apr 2014 08:59 AM PDT
Verified Answers: 1
Last post
Log in to post new comments.
Cletus's picture
7 posts

We have a custom board that uses an M25PE16 flash.  I've written flash read/write functions into our custom code and have verified that I can read/write this part reliably.  One of my tasks includes programming the boot sector on the part so that our system can boot directly without going through the Cypress bootloader.  On the development kit (with a different memory), this works flawlessly.  I upload an image to flash, switch the boot jumpers, and the part is recognized.

On our custom board, the boot step fails (the boot mode pins are set correctly, FWIW).  I have attached a logic analyzer to the SPI interface and monitored the bus transactions in both cases, and it appears that the boot loader is behaving differently for the two devices.  In the good case (with the DVK), I can see the "READ DATA BYTES" instruction sent to the flash, followed by 3 clock bursts to transfer the read address.  Then 6 bytes are read from the flash, including the all-important 'C' 'Y' marking the start of a valid image.

In the bad case, it appears that the boot loader only sends out a single address byte after the "READ DATA BYTES" command (which requires 3 bytes), then clocks in 6 bytes from the flash - but at a glance, it looks like the first two bytes are FF FF because the flash is expecting two more address bytes before returning data.  The bootloader then bails out when it doesn't find the expected header.  At least, that's my interpretation of the traces I'm seeing. 

Anyone encounter this before? 

Attached is a screen shot from my logic analyzer showing a failed boot sequence.  The good boot sequence looks similar, except there are 9 clock bursts instead of only 7, so instead of 0xFF 0xFF 'C' 'Y' 0x1C 0xB0, the boot loader reads 'C' 'Y' 0x1C 0xB0 0xCC 0x07

user_208843767's picture
49 posts

Hi Cletus,

I believe the problem is that MISO is floating high before the flash receives a valid READ DATA BYTES command. We found that the FX3 bootloader probes SPI flash with READ DATA BYTES commands of increasing address length until it sees a nonzero byte from the flash, at which point it decides that it knows the number of address bytes the flash requires in such commands.

Adding a pulldown on MISO might help.

See also here:


Log in to post new comments.