bfrom_SpiBoot fails with failure mode depending on SPI clock speed
I'm writing a boot loader for an embedded system using a BF525 and a SST25VF016B flash memory. The boot loader loads from flash during a cold boot then checks to see if there is a valid application image in flash starting at 0x040000. If it finds a valid image it then attempts to use
bfrom_SpiBoot(0x040000, BFLAG_NOAUTO | BFLAG_TYPE3 | 5, 0, 0);
to load and run the application image.
Using 5 for the OTP_SPI_BAUD value gives a SPI clock of around 4MHz. Using this clock speed the first LDR block is read correctly from flash (as seen with a logic analyzer on the SPI bus) except that two extra bytes are transferred and there is a partial (3-4 bits) transfer of another byte. The following bytes are transferred:
01 50 0C AD 00 00 A0 FF 00 00 00 00 9C 32 01 00
Another flash transfer is then started at address 0x040008 (although I'd have expected it to start at 0x040010), but only 5 SPI clocks are issued before CE is released and the transfer is aborted.
Using 6 for the OTP_SPI_BAUD value gives a SPI clock of around 2MHz. The first block transfer is similar to the previous case except there is only one clock in the partial transfer. The second LDR block is fetched from 0x000800 which is incorrect, but manages to transfer 7 bytes (the values are the actual flash content) with an extra SPI clock at the end.
Using 7 or 0 (950kHz or 450kHz) the behavior is as for 6, but without the extra partial transfers.
I am using VisulalDSP++ 5.1.2.0 IDDE 8.0.7.22 and a ADZS-USB-ICE for debugging. An earlier build of the application image boots fine written to the flash starting at address 0. Manual inspection of the .ldr files shows that
What am I doing wrong and how do I fix it?
Update:
I wrote the firmware application image to flash at address 0 and performed a cold boot. The image loaded correctly. The logic analyzer shows a first read transaction to discover the flash address width followed by a 8 byte read starting at address 0. The 8 byte read is followed by a second 8 byte read starting at address 8.
This is different than the bfrom_SpiBoot read sequence described above. Note that removing the BFLAG_NOAUTO and BFLAG_TYPE3 flags makes no difference to the first transfer from flash following the discovery transfer.
Do I need to provide a call hook and modify the ADI_BOOT_DATA structure in some fashion?
The issue was that the PLL had been altered from hardware defaults so the SPI clock was running too fast. Restoring VrCtl, PllCtl and PllDiv to hardware faults has fixed the problem.
This question has been closed by the EZ team and is assumed answered.
Please log in to reply.