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

Technical discussions around xCORE processors (e.g. General Purpose (L/G), xCORE-USB, xCORE-Analog, xCORE-XA).
kyeongjinjang
New User
Posts: 2
Joined: Wed Nov 15, 2017 8:39 pm

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

Postby kyeongjinjang » Wed Nov 15, 2017 8:57 pm

I have seen many application cases to check device IDs (incl. vendor ID) during basic booting process. ISSI device IDs have to be added in the FW to pass the device ID check. After passing the device ID check, an application used to not check the ID any more during the following process. That is the reason I thought it might not related ID issue.

But this application case can be different. Whereas XMOS controller does not check device IDs during the basic booting process, it may check during the custom data read process, unlike other applications. Now mon2 is working if this is related to the ID check command 0x9F. The result will be posted later.

By the way, the default driver strength of IS25LP016D (50%) is equal or stronger than IS25LQ016B. So we can rule out the driver strength from this cause.

KJ Jang
K_Audio
Junior Member
Posts: 7
Joined: Sat Nov 11, 2017 3:01 am

Postby K_Audio » Thu Nov 16, 2017 5:38 am

mattbc wrote:
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


Your experiences are pretty much my experiences.
I have determined that the block of code starting at address 0 (i.e. the "boot" code minus the configuration data) is not read entirely.
Rather, it seems that the OTP code in the XMOS successfully reads about 7200 bytes of data from the flash at which point the code contained in the flash takes over.
After that, nothing seems to make any sense.
K_Audio
Junior Member
Posts: 7
Joined: Sat Nov 11, 2017 3:01 am

Postby K_Audio » Thu Nov 16, 2017 5:51 am

mon2 wrote: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.


In my case, I am simply trying to determine if a LP080 can work.
To eliminate as many variables as possible, I simply removed the LQ016 from the XMOS audio eval board, copied it to a LP080 (actually one half of it), set the QE bit, and soldered it in.
I assumed that it should work since a LQ080 is a compatible part and the LQ080 and LP080 should be functionally identical in this application.

I also considered that some SFDP (and/or JEDEC parameters) was being read from the flash but that really didn't make sense to me.

We have 1000 pcs. of XHRA-2HPA-TQ64 showing up at the factory tomorrow...
User avatar
mon2
XCore Legend
Posts: 1227
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Thu Nov 16, 2017 11:45 am

1) Has the IS25LP016D (the replacement to the original IS25LQ016B) device been tested? Status?

2) The XRHA datasheet (section A, page 22) details the format of the configuration space of the external flash device. This section of space, using a hex file editor (Hex Editor Neo), does not appear to be encrypted. At initial review, do not see any specific hard coded flash IDs in this region of flash.

3) Assuming the configuration space is not CRC checked, it should be possible to alter the USB device name using the same editor. Will attempt this later today.

4) The XRHA datasheet notes the use external configuration straps. If applied, are these straps through the recommended 3k3 pull-up to VDDIO?

5) In a chat with ISSI yesterday, they have noted that factory still has some limited stock of the original IS25LQ016B device. Best to contact KJ Jang (ISSI, USA) above for more details.

So does Digikey (150 mil SOIC):

Image

6) Please post the exact binary image being tested with the IS25LP080D so we can do the same. Yesterday, we received the IS25LP016D and the IS25LP032D from Arrow (IS25LP080D was out of stock). If either one of these devices works then the issue must lie with the firmware image format. If you wish, send a private email with the contents. Will share more details later today on the review.
User avatar
mon2
XCore Legend
Posts: 1227
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Thu Nov 16, 2017 9:41 pm

Ok,

1) removed the IS25LQ016B off our XRHA PCB.

2) programmed the new IS25LP016D flash device -> enabled QSPI mode -> changed the "XMOS" to "MON2" in the 0x80000 offset (custom configuration) region.

3) installed this flash device onto the XRHA PCB. Powered up and the USB device continues to report "XMOS" label (not MON2). Assuming that the IS25LP016D flash is failing to load correctly using the XRHA PCB, placed this widget onto the Zeroplus logic analyzer with the QSPI module.

4) Logs are posted here:

https://axxonshare.s3.amazonaws.com/Axx ... LP016D.zip

5) It appears that the XMOS CPU is loading correctly (repeated the logs a few times) the reading of the IS25LP016D flash device in QSPI mode. However, the reading halts or intentionally stops at the same location inside the flash device. Then the QSPI mode PAUSE / HOLD state is maintained and then repeats the QSPI read again.

6) This exercise is very time consuming and took 2 days (mild under statement) to setup and review. Have not yet performed the same testing with the original IS25LQ016B device.

Guessing that no one from XMOS is reviewing this thread which is a shame considering how serious this issue may be. Must be a low priority. XMOS will have to offer a new list of compatible flash devices that are active and not EOL.

Is XMOS IP checking the IDs of the flash device? Do not believe so since the logs do not show this SPI / QSPI command. Rather the QSPI read to the same location and then halts. Assuming that this limited chunk of read is enough to launch the USB Audio widget status.

The QSPI logs match 100% to the binary image of the flash device. Repeated a few times.

Based on the above posts, the exact same binary image works on the IS25LQ016B device? Will check whenever we have some free time to alter the USB name from XMOS to MON2 using the same approach. Perhaps the custom configuration region is crc checked and cannot be manually changed as we have done for the USB device name. In which case, the XMOS crc checker will fail the custom parameter loads. It is for this reason, we requested for the exact dump of the firmware from others. The XMOS tools are required to prepare the flash image (including the custom parameters). We are not audio developers so not sure.

Thanks to the ISSI staff for their continued support.

To be continued...
mattbc
Junior Member
Posts: 6
Joined: Mon Oct 30, 2017 11:34 pm

Postby mattbc » Fri Nov 17, 2017 3:13 am

mon2 wrote:Ok,

1) removed the IS25LQ016B off our XRHA PCB.

2) programmed the new IS25LP016D flash device -> enabled QSPI mode -> changed the "XMOS" to "MON2" in the 0x80000 offset (custom configuration) region.

3) installed this flash device onto the XRHA PCB. Powered up and the USB device continues to report "XMOS" label (not MON2). Assuming that the IS25LP016D flash is failing to load correctly using the XRHA PCB, placed this widget onto the Zeroplus logic analyzer with the QSPI module.

4) Logs are posted here:

https://axxonshare.s3.amazonaws.com/Axx ... LP016D.zip

5) It appears that the XMOS CPU is loading correctly (repeated the logs a few times) the reading of the IS25LP016D flash device in QSPI mode. However, the reading halts or intentionally stops at the same location inside the flash device. Then the QSPI mode PAUSE / HOLD state is maintained and then repeats the QSPI read again.

6) This exercise is very time consuming and took 2 days (mild under statement) to setup and review. Have not yet performed the same testing with the original IS25LQ016B device.

Guessing that no one from XMOS is reviewing this thread which is a shame considering how serious this issue may be. Must be a low priority. XMOS will have to offer a new list of compatible flash devices that are active and not EOL.

Is XMOS IP checking the IDs of the flash device? Do not believe so since the logs do not show this SPI / QSPI command. Rather the QSPI read to the same location and then halts. Assuming that this limited chunk of read is enough to launch the USB Audio widget status.

The QSPI logs match 100% to the binary image of the flash device. Repeated a few times.

Based on the above posts, the exact same binary image works on the IS25LQ016B device? Will check whenever we have some free time to alter the USB name from XMOS to MON2 using the same approach. Perhaps the custom configuration region is crc checked and cannot be manually changed as we have done for the USB device name. In which case, the XMOS crc checker will fail the custom parameter loads. It is for this reason, we requested for the exact dump of the firmware from others. The XMOS tools are required to prepare the flash image (including the custom parameters). We are not audio developers so not sure.

Thanks to the ISSI staff for their continued support.

To be continued...


This appears to be the exact same I am seeing. I did hear from an XMOS FAE that they were planning on EOL this part and recommended I use AN XU200 series part, but will I have the same problem with that part too?
I'll try to follow up with more data I have on Monday when I'm back in the office too.
K_Audio
Junior Member
Posts: 7
Joined: Sat Nov 11, 2017 3:01 am

Postby K_Audio » Fri Nov 17, 2017 4:28 am

There is a "XCORE audio configuration utility" that can generate a flash image including the configuration data.
I tried to upload a binary image file with no success.



Regards,

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

Postby mon2 » Fri Nov 17, 2017 1:25 pm

We have the xconfig utility but prefer to review the same image that is being tested by others. There are too many variables at play and need to streamline the permutations. If there is an image that works to alter the usb ids and or usb device name then that image is worth testing with the qspi bus analyzer.
K_Audio
Junior Member
Posts: 7
Joined: Sat Nov 11, 2017 3:01 am

Postby K_Audio » Sat Nov 18, 2017 10:31 am

mon2 wrote:There are too many variables at play and need to streamline the permutations.


That was my thinking as well.
By using "non-custom" hardware and software (i.e. an XMOS reference design), the focus is squarely on the SPI flash memory since we know that the hardware works and the SPI flash data is valid.

I can tell you that the XCORE audio configuration utility generates a binary image that is identical to what is used in the XMOS board.
User avatar
mon2
XCore Legend
Posts: 1227
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Sat Nov 18, 2017 1:23 pm

I can tell you that the XCORE audio configuration utility generates a binary image that is identical to what is used in the XMOS board.


We are not finding the same result. It is important for someone to post an image that is working with the IS25LQ series yet fails to work with the IS25LP series of flash devices. This image should alter the USB IDs and/or USB device name so that we can be sure that the IP is working to read the custom definitions @ offset 0x80000.

We can confirm that the xconfigurator tool is required to generate the target firmware image if there are changes to the configuration data @ offset 0x80000.

Does anyone have the full source code being used by the XHRA processor? Apparently the same firmware can be planted inside one the flash based XCORE-200 processors.

Who is online

Users browsing this forum: No registered users and 10 guests