I am also trying to boot from SPI flash (M25P16). Programming seems to work fine, at least the ControlCenter reports SUCCEED (even though it seems possible to program also non-binary files while still getting no error message).
After releasing the RESET line, I can see activity on the SPI interface but then the FX3 falls back to USB boot. To exclude problems with the binary file it would be very helpful if you could provide a tested one. Thanks.
I have written a demo application that is writing and reading the whole flahs without problems. Therefore the SPI connection between flash and FX3 has to be in order.
In addition, I have now analysed the SPI activity more in detail. The FX3 is reading the first four bytes (0x43 0x59 0x00 0xB0) from the flash (which matches with the downloaded img file and is in line with AN70193) and then stops reading and falls back into USB boot mode. It looks to me that the FX3 expects some other data and therefore stops USB boot.
Has anyone successfully bootet from flash and can share the used img file with me? Expecially you guys from Cypress should have a working img file that I could test in my setup. Thanks.
I have just tested the "boot_fw" source provided with the V 1.0 SDK. This firmware, after downloading it to the RAM, was able to load my img file from the attached SPI flash and started it successfully.
So I am really getting curious if somebody has was able to boot using the internal bootloader and if the header of the img file was different to the one coming out of the eclipse project. Personally I would expect that this "boot_fw" source code is identical to the internal bootloader but obviously this does not seem to be the case.
maybe you can get it if you read out the bootloader revision of the FX3. That is described in the aplication note AN73150 on page 2. At the ROM addresses 0xFFFF0020 ... 0xFFFF0023 is the bootloader revision. Up to now what is see is just the minor revision (0xFFFF0020) filled with a value.
I have there e. g.:
Value 0x9C at FX3 Rev. ? ES(A) DateCode 1113
Value 0xA7 at FX3 Rev. ? ES(B) DateCode 1131
Value 0xA9 at FX3 Rev. D DateCode 1149
So the Rev. D I am almost sure and if you have a date code 1201 then this has to support what you need!
I am still not able to boot from SPI. According to the datecode (1149) and minor revision read out from the ROM (0xA9) my FX3 chips should be able to boot from SPI.
Now I noticed that according to the documentation the FX3 should use PID=0x00F3 and VID=0x04B4 after SPI boot fails. In my case the FX3 is using PID=0x0000 and VID=0x1480 in USB fall back. Any ideas why it is like that? Thanks.
the chip version with date code 1149 has that problem that the VID/PID is like you described while booting from internal hardware bootloader (fall back if fails via SPI). There is already a product information notifycation on the cypress website (see http://www.cypress.com/?rid=59869).
You may just can add the VID/PID combination (you wrote) to the .inf file and then it should work.
Thanks Lumpi6. This explains why my chip does not startup with the expected VID and PID. In fact I already adjusted the .inf file and everything was working apart from SPI boot. I was hoping that this was somehow related with each other.
So then I'm back at the problem that SPI boot does not work. I can see the FX3 reading the first four bytes of the .img file out of the flash (it perfectly corresponds with what I downloaded) and then the bootloader stops and falls back to USB boot. The downloaded .img file has to be in order, as a Cypress emplyoee was able to boot with this file on his DVK board.
At this point it would be good to know what can cause the bootloader to stop downloading the .img file. Moreover, I am curious to know if somebody has tested SPI boot successfully on a FX3 chip with production date 1149. As I have built my own hardware, there is still the possibility that I have a hardware issue. However, as said before, I can boot from SPI flash using the "boot_fw" demo application from Cypress, so the SPI interface has to work properly. I am using a M25P16 flash from ST.
Any hints are appreciated.
I never tried the SPI boot mechanism just tried via I2C. There it is so, that the FX3 first is reading out 4 bytes 'C' 'Y' '<Image Control>' '<ImageType>'. And just if these four bytes are telling the FX3 that it has to read more e.g. a firmware or a new VID/PID then the FX3 reads additional the firmware or 4 further bytes with VID/PID.
You may can try to boot with new VID/PID then set the first four bytes to...
2: 0x00 (10MHz, execution binary file)
3: 0xB2 (SPI boot with new VID/PID)
if this is programmed and read out from FX3 at the beginning, then the FX3 will read out 4 additional bytes and use them as VID/PID. If you tried that and it works, then you know that the signals CS, SCK, DIN, DOUT works fine with the used EEPROM. Then I think you are using wrong parameters at boot ctrl or image ctrl.
As you can see on the attached scope pictures, the FX3 stops again after reading out the first four bytes. As said before, the data read is correct and I was writing and reading the flash from the FX3 (using my own application) at least 100 times without data consistency problems. Also the "boot_fw" works very well.
Does somebody know the configuration that the bootloader uses for SPI boot? In my application I am using:
spiConfig.isLsbFirst = CyFalse;
spiConfig.cpol = CyTrue;
spiConfig.ssnPol = CyFalse;
spiConfig.cpha = CyTrue;
spiConfig.leadTime = CY_U3P_SPI_SSN_LAG_LEAD_HALF_CLK;
spiConfig.lagTime = CY_U3P_SPI_SSN_LAG_LEAD_HALF_CLK;
spiConfig.ssnCtrl = CY_U3P_SPI_SSN_CTRL_FW;
spiConfig.clock = 8000000;
spiConfig.wordLen = 8;
and this is working very well. Maybe the bootloader is using some other setting? As an example if the FX3 would be sampling the data on the falling edge, wrong data would be clocked in. But as far as I know all SPI flash are clocking the data out on the negative edge, so the FX3 has to sample on the positive edge, otherwise it would not work at all. I hope that the people from Cypress can give here some input what SPI configuration the bootloader is using. Thanks.
Finally I found the problem with help from Cypress: I had a 10k pull-up connected to the MISO line. Apparently the bootloader is reading the MISO line even if there is no active driver during the bootloading process and expects a low signal on this pin. Obviously this is not the case if a 10k pull-up is connected. Instead I have now connected a 10k pull-down resistor at MISO and the SPI boot is finally working.
I do not understand why the bootloader is reading the MISO line when no driver is active but for the moment I am just happy that it works.