- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I have developed an own PCB design based on Denebola development kit. Whit the following differences:
- the SPI FLASH, which is used to store the firmware image, is supplied by 1.8V. Because I have replaced the 3.3V domain by 1.8 V.
- The boot mode is fixed to start always as SPI mode. But I can also start in USB boot mode in order to update the firmware embedded in SPI FLASH memory.
My own design works correctly if I supply the firmware through USB boot mode, I mean, in this case, I program the CX3 through RAM using the USB Control Center, embedded in the Cypress EZ USB Suite.
But I have detected an issue, also in my own design, When I try to supply the firmware from the SPI FLASH. Because I can store the firmware in the SPI Flash and the USB Control Center does not show me any warning.
The error appear when the CX3 has to get the firmware from the SPI FLASH, since he can't do it.
For this reason I have compared, in both Denebola and own design, the writing and reading of the firmware image between the CX3 and SPI FLASH. To do this, I have used an oscilloscope and a logic analyzer in order to be sure of the results.
I have attached the results, and as you can see. The writing process of the firmware image is exactly the same in both denebola and own design. I mean, I have registered the same writing values in the SPI FLASH.
But in the reading process from the SPI FLASH, my own design does not send the same values. Because I detect some corrupt values in dataframe.
So my question is the next:
It is possible that the memory problem is preceded by the high reflow temperature in the soldering process?.
The memory Cypress model S25FS064S, so, could you tell me please the maximum solder temperature of the device, because it is not appear in the datasheet?.
Thanks.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
I understand that the writes to the flash part S25FS064S are successful but the data read back from the flash is not same as the data written into the flash. In order to isolate the issue, we need to understand if the flash erase is working as expected or not. Please try erasing the first sector of flash and then read back the data present in the first sector of the flash. Please refer to the SDK example pointed out in the following thread to understand how to erase a sector of the flash:
how could I communicate with SPI Flash memory through CX3's firmware?
After erasing, please try to read the data present in the first sector of the flash. If the erase was successful, then all the data present in the first sector of the flash would be 0xFF. You need not read back the entire data present in the first sector of flash. As of now, after erasing the first sector of the flash, please try reading back first 4096 bytes of the first sector of the flash. Please share snapshots of the control center after the vendor commands are sent to erase the first sector of flash and to read back the data present in the first sector of flash.
If the sector erase is not working properly, please try the suggestion mentioned in the following KBA:
FX3 SPI boot fails when S25FS128S flash is used – KBA231163
Best Regards,
Jayakrishna
Jayakrishna
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
I understand that the writes to the flash part S25FS064S are successful but the data read back from the flash is not same as the data written into the flash. In order to isolate the issue, we need to understand if the flash erase is working as expected or not. Please try erasing the first sector of flash and then read back the data present in the first sector of the flash. Please refer to the SDK example pointed out in the following thread to understand how to erase a sector of the flash:
how could I communicate with SPI Flash memory through CX3's firmware?
After erasing, please try to read the data present in the first sector of the flash. If the erase was successful, then all the data present in the first sector of the flash would be 0xFF. You need not read back the entire data present in the first sector of flash. As of now, after erasing the first sector of the flash, please try reading back first 4096 bytes of the first sector of the flash. Please share snapshots of the control center after the vendor commands are sent to erase the first sector of flash and to read back the data present in the first sector of flash.
If the sector erase is not working properly, please try the suggestion mentioned in the following KBA:
FX3 SPI boot fails when S25FS128S flash is used – KBA231163
Best Regards,
Jayakrishna
Jayakrishna
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
after to see all threads nearest of this topic, I can guess that it is a problem related about Cypress memory design. Now I am going to explain my experience about that:
In order to discover that it was a SPI memory problem, I replaced the broken memory by a new one. Firstly The system behaviour was correct, I mean, I could store the boot image from the SPI Flash memory without any problem, and the device showed a perfect performance. But everything changed, after to store a new boot image in the SPI Flash memory, becasue the CX3 can not get a correct boot image never more.
I have done the same test four times, and I have had the same result in all of them. So I have the next question:
- Could you affirm me if it is due to Cypress's SPI Flash memory design? Because our principal aim for this year is to carry out a max production release of an electronic device which embeds this memory.
By other hand I am thinking about to store the boot image into a I2C EEPROM memory instead of the SPI FLASH. Do you think that it is a right decision? in case yes, could you tell me which is the most proper I2C memory in order to store a boot image for CX3 device?. And how to connect it?
Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
The flash part s25fs064s makes use of hybrid sectors by default. While downloading the firmware into the SPI flash using control center, the boot programmer utility requires that the flash to have uniform sectors. The commands used for erasing uniform sectors and hybrid sectors are different. Due to this reason, erase of first sector is failing when you are using the default boot programmer utility for downloading the firmware image to the SPI flash. Initially, all the flash sectors will be erased. This is the reason why you are able to download the firmware image at the start and boot from the flash without any issue.
This is not a problem with the flash part s25fs064s. You can change the default boot programmer utility to configure the flash to make use of uniform sectors by referring to the following KBA:
FX3 SPI boot fails when S25FS128S flash is used – KBA231163
Even though the KBA is written for the part s25fs128s, the same procedure can be used for the part s25fs064s too. Please try this and let me know if you are seeing the boot failure again.
Also, it is possible to use I2C EEPROM on your board for storing the firmware image. But the boot will be comparatively slower compared to that while using an SPI flash. I see that you have already created another thread for the discussion on the use of EEPROM with CX3. The link to the thread is given below:
I2C Memory in Denebola Development kit
Please carry on the discussion regarding the EEPROM on the thread mentioned above.
Best Regards,
Jayakrishna
Jayakrishna