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

Technical discussions around xCORE processors (e.g. xcore-200 & xcore.ai).
mattbc
Junior Member
Posts: 6
Joined: Mon Oct 30, 2017 11:34 pm

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

Post by mattbc »

I have a design I adopted that uses an XMOS XHRA-2HPA-TQ64. It historically has used ISSI and Spansion SPI flash parts as listed in the datasheet and on these forums. Specifically, IS25LQ080. ISSI now show this part as end of life and its replacement part is supposed to be IS25LP080. When I use the IS25LQ080 part everything works fine and the part boots up and identifies as my custom PID/VID on USB. However, when I switch to the IS25LP080 part the custom portion doesn't load, but the main FW loads and tries to enumerate as a default XMOS device.

I have the QE bit set and have verified by reading in circuit the flash part back that it is 100% the same as the working image. Anyone have any idea as to why this would happen?

When I scope the bus it appears that the code loads correctly through an EB command, then after a pause the SCLK goes crazy (before CE is asserted again) at around ~9.6Mhz opposed to ~2.5Mhz when it was working. SCLK continues when CE/SS is not asserted, and my data lines all seem to have spurious behavior, no commands make sense anymore.

Thanks!
Matt


User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Hi matt. Your silicon may be affected by a silicon bug. Read the details here:

http://www.xcore.com/viewtopic.php?f=26 ... ode#p30290

http://www.xcore.com/viewtopic.php?f=26&t=4742

However, interesting to hear that:
When I use the IS25LQ080 part everything works fine and the part boots up and identifies as my custom PID/VID on USB.
So to confirm, if you use the above p/n, the same silicon boots without issues? What is the SPI clock value with the IS25LQ080? Does it remain around 2.5 Mhz? If yes, suggest that you source a few compatible flash devices (personally recommend Spansion brand which is now Cypress based on an extensive review of flash devices a few years ago). Spansion worked the best with long cables in our test bench and logic analyzer. In either case, please post your results after your testing.
mattbc
Junior Member
Posts: 6
Joined: Mon Oct 30, 2017 11:34 pm

Post by mattbc »

Thanks for the quick response! We have used the same XMOS silicon and board with both a 'working', and 'non-working' part. Using the original Spansion FL116K, or ISSI LQ080 parts everything works as advertised. When we use anything else, so far, the results are either:

1) Doesn't load at all.
2) Loads the Default FW, but not the custom information above 0x80000, as with the LP080 part.

The date codes of all the parts I've checked have been past 1610 where the ROM code was supposed to be fixed.

Our main issue is we have a new product using this part an our CM cannot purchase your recommended parts because they are both EOL at this point. The ISSI LP part is ISSI's replacement part, though obviously something is different, and Spansion/Cypress seems to have gotten out of the business of sub-64Mbit parts and do not have any replacements for 8Mbit (ideal), or 16Mbit. Do you guys have an updated supported part list?

I don't have a SPI analyzer that can decode quad, so I'm relying on a scope with digital inputs and decoding manually. I will try to capture a working waveform next, and then a broken one to compare to and post my results. It appears to me the only command being sent is the 0xEB (fast read) with QE enabled to ready the FW. Is this the same command used to read the configuration too?

Thanks for your help!
Matt
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Hi matt.
Do you guys have an updated supported part list?
To be clear, we are not XMOS employees but a developer like yourself.

Some ideas:

1) be 110% sure that the QE bit 6 of the STATUS REGISTER is ENABLED on your flash device else this exercise will fail.

2) ISSI should be contacted on this review but immediately see a difference between the LP vs LQ versions of these flash devices. Specifically see section 6.32 of the LP datasheet:

http://www.issi.com/WW/pdf/25LP-WP080D.pdf

Image

It appears the factory default signal / pin strength is 50% on the LP (non-working) flash device. This register is not present on the LQ (working) flash device. ISSI factory engineering should be able to share what is the pin strength on the LQ (working) flash device. Reach out to them to ask specifically, what is the pin strength value of the LQ (working) flash device?

Using standard SPI commands, you should be able to alter this non-volatile factory default pin strength from 50% and dial it up to 100%. Although, admitting it will be rather strange if this works, this is worth a try. Guessing that your PCB layout is nice and compact so perhaps this is not the issue but again, worth a try.

We invested many weeks on the QSPI review of XMOS and QSPI flash use about 2-3 years ago and found differences between the quality of QSPI reads using our logic analyzer (Zeroplus with QSPI module) - tested Winbond, Spansion and some others. Even with rather costly shielded logic analyzer cables (6"-12", the default Winbond parts were wimpy and could not drive the same cable lengths we used in the lab. Replaced the target flash with Spansion, no issue and even at higher data rates. Reported our findings to Winbond and they forwarded us from Taiwan a new line of flash device samples which featured...(drumroll)...a pin strength register. After programming of this aux pin strength register, we did manage to make the operation equal in the testing. So this is worth a deeper review. This may or may not be the root cause of your issue.

The other plan is to pay the scalper pricing for the original LQ (working) flash version of the ISSI device from those that still offer the part to keep your assembly line running. At least while you explore a viable solution. From my (fading) memory, yes the default EBh command is used to read out in QSPI mode from the flash. Now if the returned data is corrupt (due to the pin strength?) then this is all logical.

Otherwise, from a quick scan of the 2 related datasheets, the LP (non-working) flash looks to be an "improved" version of the LQ (working) flash device.

Any chance you have other XCORE-200 kits around? If yes, consider to validate the same tests by removing the SMD device off the XMOS original kit and replace with your XX variant. Then, program some blinky code, etc. and power cycle 10+ times. Does your blinky IP code boot ok on the XCORE-200 kit? We have these kits in the lab and free time pending, we can do some quick tests but need to bring in some fresh and current silicon from Digikey. No promises but can review when possible.

Our faith is with the Spansion line till Cypress breaks their working formula due to their acquisition of Spansion. Cypress appears to have a reverse midas touch to many IPs but hope they do not tarnish the quality of the Spansion line. Noting this, why not consider the higher density Spansion / Cypress device - at least for testing. This way you have a non-EOL device and sourced from legitimate and authorized suppliers.
K_Audio
Junior Member
Posts: 7
Joined: Sat Nov 11, 2017 3:01 am

Post by K_Audio »

mattbc wrote:I have a design I adopted that uses an XMOS XHRA-2HPA-TQ64. It historically has used ISSI and Spansion SPI flash parts as listed in the datasheet and on these forums. Specifically, IS25LQ080. ISSI now show this part as end of life and its replacement part is supposed to be IS25LP080. When I use the IS25LQ080 part everything works fine and the part boots up and identifies as my custom PID/VID on USB. However, when I switch to the IS25LP080 part the custom portion doesn't load, but the main FW loads and tries to enumerate as a default XMOS device.

I have the QE bit set and have verified by reading in circuit the flash part back that it is 100% the same as the working image. Anyone have any idea as to why this would happen?

When I scope the bus it appears that the code loads correctly through an EB command, then after a pause the SCLK goes crazy (before CE is asserted again) at around ~9.6Mhz opposed to ~2.5Mhz when it was working. SCLK continues when CE/SS is not asserted, and my data lines all seem to have spurious behavior, no commands make sense anymore.

Thanks!
Matt
I have exactly the same issue.

Using an IS25LP080, the XHRA-2HPA-TQ64 will boot and the USB will enumerate. However, it is not reading the configuration data.

A few notes:
1) This is with the XHRA-2HPA-TQ64 eval. board. With the original SPI flash, of course it works fine.
2) The IS25LP080 is half the size of the original LQ116 part but I did confirm that the image in the IS25LP080 is exactly the same as the first half of the original LQ116 part.
3) The QE bit is set (otherwise it couldn't boot the firmware image).
4) I tried setting the drive stregth to 100% but that didn't help.
5) The date code (I assume) on the XHRA-2HPA-TQ64 is GT152301. I was hoping that the root of this problem was the "old" OTP firmware in the XHRA-2HPA-TQ64.
K_Audio
Junior Member
Posts: 7
Joined: Sat Nov 11, 2017 3:01 am

Post by K_Audio »

mattbc wrote:Thanks for the quick response! We have used the same XMOS silicon and board with both a 'working', and 'non-working' part. Using the original Spansion FL116K, or ISSI LQ080 parts everything works as advertised. When we use anything else, so far, the results are either:

1) Doesn't load at all.
2) Loads the Default FW, but not the custom information above 0x80000, as with the LP080 part.

The date codes of all the parts I've checked have been past 1610 where the ROM code was supposed to be fixed.

Our main issue is we have a new product using this part an our CM cannot purchase your recommended parts because they are both EOL at this point. The ISSI LP part is ISSI's replacement part, though obviously something is different, and Spansion/Cypress seems to have gotten out of the business of sub-64Mbit parts and do not have any replacements for 8Mbit (ideal), or 16Mbit. Do you guys have an updated supported part list?

I don't have a SPI analyzer that can decode quad, so I'm relying on a scope with digital inputs and decoding manually. I will try to capture a working waveform next, and then a broken one to compare to and post my results. It appears to me the only command being sent is the 0xEB (fast read) with QE enabled to ready the FW. Is this the same command used to read the configuration too?

Thanks for your help!
Matt
Have you confirmed that the SPI clock is running when the CS is not asserted with parts that have a date code > 1610?
My understanding was that this only applies to parts with a date code prior to 1610.
The part that I have exhibits this behavior but I assumed it was because of the older date code.
The LPxxx is rated to run at a higher clock speed than the LQxxx so I can't imagine what the problem is.
mattbc
Junior Member
Posts: 6
Joined: Mon Oct 30, 2017 11:34 pm

Post by mattbc »

K_Audio wrote:
mattbc wrote:Thanks for the quick response! We have used the same XMOS silicon and board with both a 'working', and 'non-working' part. Using the original Spansion FL116K, or ISSI LQ080 parts everything works as advertised. When we use anything else, so far, the results are either:

1) Doesn't load at all.
2) Loads the Default FW, but not the custom information above 0x80000, as with the LP080 part.

The date codes of all the parts I've checked have been past 1610 where the ROM code was supposed to be fixed.

Our main issue is we have a new product using this part an our CM cannot purchase your recommended parts because they are both EOL at this point. The ISSI LP part is ISSI's replacement part, though obviously something is different, and Spansion/Cypress seems to have gotten out of the business of sub-64Mbit parts and do not have any replacements for 8Mbit (ideal), or 16Mbit. Do you guys have an updated supported part list?

I don't have a SPI analyzer that can decode quad, so I'm relying on a scope with digital inputs and decoding manually. I will try to capture a working waveform next, and then a broken one to compare to and post my results. It appears to me the only command being sent is the 0xEB (fast read) with QE enabled to ready the FW. Is this the same command used to read the configuration too?

Thanks for your help!
Matt
Have you confirmed that the SPI clock is running when the CS is not asserted with parts that have a date code > 1610?
My understanding was that this only applies to parts with a date code prior to 1610.
The part that I have exhibits this behavior but I assumed it was because of the older date code.
The LPxxx is rated to run at a higher clock speed than the LQxxx so I can't imagine what the problem is.
I have confirmed that the same chip (XMOS) works with an LQ and not an LP. I also don't have a QSPI capable protocol analyzer currently. I have taken several scope traces and the broken ones (LP part shown here) look about the same as the LQ... I can't determine eyeballing where the chip reads the config data. It's easy to manually follow the QSPI transitions at first and they look correct and don't have the clk going when CS is de-asserted initially. However, on both working and non-working traces it appears to load the code at around 2.5Mhz SCLK, then pause (no SCLK, no CS, no data), then start over at a faster SCLK reading the same locations at around 10Mhz. Almost like the ROM code was fixed, loaded the main FW in the first couple EB commands, then jumped to the new FW and started the load all over again or something using a different procedure. At this point I see what appears to be a very asymmetrical SLCK signal, and one that starts before CS is asserted and continues past the CS line returning high. I saw this on the working one too. I can no longer manually decode the data because I start to see data switch faster than the SCLK line sometimes (scope issue maybe?). It seems pretty clear that the following sequence is happening:

1) ROM code sends 0xEB command with Address 0x000 and reads 4 bytes at 2.5Mhz
2) ROM code sends 0xEB command with address 0x004 and reads what appears to be most (but not all) of the initial programmed FW from the Spi Flash.
3) ROM finishes transfer. Stops SLCK, and CS. SPi Flash stops sending data and lines stay in an 'idle' state.
4) XMOS chip (ROM code, or what it read from SPI now) starts using 0xEB command again starting at addr 0x000 again, but at a faster rate and SCLK now will continue all/most of the time. It almost seems to repeat this and here is where I get lost.

Some of the images have a decode state, it is only interpreted as normal SPI. Also, some traces have an analog signal probed as well. Something was definitely funny here, I probed a couple lines, and the scope would almost look like the ground reference was lost and I had some DC offset when zoomed out, but when zoomed in looked ok.... Not sure what that was about, but for now, I'm blaming the scope on that one.

Regards,
Matt
Attachments
XMOS_with_ISSI_LP_QSPI.zip
(390.71 KiB) Downloaded 634 times
XMOS_with_ISSI_LP_QSPI.zip
(390.71 KiB) Downloaded 634 times
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

To summarize, your firmware with your customized configuration, if applied to the original ISSI device (ISSI LQ080) will boot fine with the XMOS CPU?

Then the same firmware image, when programmed into a same density part (as above) but this part is the new version (ISSI LP080) from ISSI, will only boot the XMOS firmware and ignore the customized configuration?

Have you tested the (ISSI LP080) on the original XMOS evalboard - does that work?

If not tested, can you post the following?

a) schematic of your custom design that is using these parts for a review
b) exact firmware being used for the testing - what is the custom configuration doing? Changing the USB VID & PID if it boots correctly?
c) exact vendor and part numbers that have been tested by your side.

We do have a QSPI bus analyzer but it is very time consuming to probe and setup for this exact environment so trying to understand the most basic setup to mimic this quirk.

We do have the XMOS official headphone PCB for similar testing. For now, do not recommend to alter the density of the flash devices till more is known on the root cause that is in effect. Perhaps you need to inform the firmware of the details of the flash such as the density and component ID, etc. It is quite possible the firmware is loading fine and expecting the flash to be the same size as the original yet you are using a 50% of the original density. XMOS can clarify these details.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Hello. Quick updates:

1) ISSI factory is now involved in this review and have opened a dialog with their engineering group. They are reviewing this thread as well.

2) ISSI is asking if the XMOS firmware is hard coded and linked to the IDs of the FLASH devices. Are they? A SPI bus decode of the boot process should reveal if they are extracting this info from the flash device - will review the logs at work. Welcome this detail from other developers as well.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Hello.

1) Any comments from XMOS on this issue? Any chance the IP is hard coded to search and support only these specific flash device? Likely not but worth asking.

2) ISSI is requesting to review the PCBs that are having this issue. Here are the contact details for the applications engineer reviewing this case:

Hello Kumar,

I read the forum you sent me. It looks basic booting is OK. This means there might not have device ID issue. As I know, the driver strength will not be issue. It possibly can be related to signal integrity. Can you send a board to me so that I can check the signals, if you have?

You can call me below phone number if you want to chat with me.

Best regards,

KJ Jang
Integrated Silicon Solution, Inc.
Application Engineer
Phone: 408.969.5137

KyeongJin Jang
kyeongjin_jang[at_usual_stuff]issi.com



3) Please post your results here in the forum as this may be a serious issue moving forward for all developers.
Post Reply