XHRA-2HPA-TQ64 doesn't load unique configuration data at 0x80000 addr

[mattbc]

I've attached our bin image with custom data that I can program on a unit with IS25LQ, but not IS25LP.

To program the units I am programming the IS25LQ080B chips in circuit with the XMOS powered down, but the flash powered up using a total source cheetah spi tool.
I then read back the image from the flash chip to verify it is the same at 0x00000 - 0x80000+
I then set the QE bit of the status register using the cheetah to poke 06 unlock then 01 40 for write status register 0x40 (QE enable bit).
I then verify the QE bit is set with a read status register command (0x05)





After all of these steps I reset the board which then brings up the XMOS and everything else. With the LQ I get a custom identified device correctly. With the LP part it still looks like an XMOS even though the readback data from the part is exactly the same showing the flash part is programmed correctly.

I have some traces I took of the working LQ part today and I'm parsing through them for something notable to post. (This would be a lot easier if I had something that could decode QSPI automatically).

Hopefully this is helpful to someone. I'm not using the dev board because I don't have one unfortunately, so I do have the hardware variable in there. However, I can get the LQ part to work on multiple boards we have where the LP always works for the most part seemingly 'ignoring' the custom data. In reality it looks like the signalling coming from the XMOS chip after initial 0xEB commands at power up are not as stable (I see frequency modulation on SCLK, and SCLK active when CS is high). I will try to post something more quantifiable than that soon.

Regards,

Matt

[mon2]

@mattbc,

1) agree with your results using the posted firmware

2) applied the xmos_custom_readback.bin using our startkit and xflash into the IS25LQ016B device -> then used our small code on the same startkit to enable the QE bit as we have always done. Repeated the QE programming one more time for good measure.

Transfered the IS25LQ016B flash onto the XRHA (original XMOS) PCB. Docked into our Windows 7 box and indeed we see your "SPROUT" USB widget but was yellow marked. The USB name was important for us to confirm and it is indeed present with this firmware & flash combination.

3) Next, repeated the above using the IS25LP016D flash device -> upon USB docking, the USB name is back to XMOS factory default (no longer "SPROUT").

For both tests, as always, do perform a full chip erase using the --erase-all parm with xflash. We are using 2 different def files as the IDs are different for each flash device.

Starting to lean towards the ID checking by XMOS IP as raised by KJ (ISSI factory). However, do not have proof of this ID check...yet.

XMOS support - available here? Would someone in the UK or India group confirm if there is an ID check being performed by this IP??

Quality support by chip vendors is a lost art. Late last week we were hyped to test the new PSOC6 tools after watching a webinar. Within a few hours, found a compiler bug. Bravo! At least in this case, head of engineering @ Cypress confirmed our observation as a bug.

With regret, the vendors appear to be...hurry up and buy bucket loads and you are on your own, if you need support, well, doubt that you will receive it unless you are moving high high volumes. Sad approach.

[mon2]

QSPI logs with the SPROUT image inside the IS25LP016D flash device are posted here:

https://axxonshare.s3.amazonaws.com/xmo ... I_mode.zip

Using the IS25LP016D flash device and the above SPROUT image for the firmware, the XRHA PCB appears to load upto and including offset 1D07 before choking and then repeats the entire read process. Do not see any other SPI command other than the EBh (QSPI read) in these logs.

Repeated the logging a few times and the results are the same each time. Unless there is an issue with our tool or the related QSPI plug in from Zeroplus, the logs are consistent. Do not believe the tool is an issue.

Have any other brands of QSPI capable flash been tested with this same IP? Let us dig around as we may have some Spansion or equivalent Micron(?) devices.

[mon2]

SPROUT image works when programmed inside the Spansion S25FL116K device. The USB device shows up as the Sprout device.

Perhaps not a surprise as this device is on the approved list of flash components for use with the XHRA CPU. The small kink in using this device is that the READ and WRITE of the status register is not the same as on the ISSI device. Also the QE bit is Bit 1 of the SR2 register (as noted by another developer in a another thread on this forum).

[mon2]

SPROUT image also works when programmed inside the Spansion S25FL164K device. The USB device shows up as the Sprout device.

[mattbc]

Yes. We actually use this part and a near identical image on another product that uses the Spansion parts primarily. I've seen the same results. Problem with Spansion is they appear to be getting out of the business of smaller QSPI flash parts. It appeared to me that their replacement line started at 64Mbit.

[Lucas]

Looks like most of the recommended Flash devices are either "EOL"/"NRND" at Mouser and "Obsolete"/"Last Time Buy"/"Discontinued" at Digikey.
S25FL116K0XMFB013 is a "New Product" but the datasheet has a "Not Recommended for New Design" watermark.
ISSI IS25LQ032B still looks like a good part.

[mon2]

Till a developer or ISSI factory can confirm that other flash devices are compatible, highly recommend to stick with the proven part numbers.

IS25LQ016B is still available through Digikey:

https://www.digikey.com/product-detail/ ... ND/5189769

adding Mouser to the list of stocking distributors of this component (at this time of writing):

https://www.mouser.com/ProductDetail/IS ... nT6w%3d%3d

ISSI factory noted that the new generation of devices are lower cost due to process changes inside the device.

[mon2]

Hello. KJ (ISSI factory, USA) just emailed us with an update. They were kind enough to purchase the XRHA XMOS tool to further investigate this issue for a root cause. Have requested for them to post their excellent review and results.

Summary: The XMOS IP inside the XRHA OTP code is checking for specific flash IDs.

Will try to contact XMOS factory and request for the developers to do the same. SPI command 0x9F is being used for specific matches. It is sad that our Zeroplus tool was unable to log this command during our review. Time to source a real SPI bus analyzer or build one using XMOS processors?

Thank you ISSI for your excellent support on this issue.

[kyeongjinjang]

As Kumar stated, we got USB Audio evaluation board which XHRA-2HPA XMOS processor is mounted on and investigated all the packets during power on. 0x9F (Read JEDEC ID command) is being used just before reading the configuration out from IS25LQ016B. I think this will cause the failure of IS25LP016D since the device type code is different (0x40 vs. 0x60). Please refer to the attached here for more details.

We, ISSI, have enough IS25LQ016B in our inventory. Please contact us if needed.