XCore200 QSPI

Technical discussions around xCORE processors (e.g. xcore-200 & xcore.ai).
pwatts
Junior Member
Posts: 6
Joined: Tue Feb 14, 2017 8:54 pm

XCore200 QSPI

Post by pwatts »

Hi, We're developing with XCore200 where we need to reprogram the external bootflash from an external SPI master while keeping the XMOS in reset. This worked fine on our XS1-based products, and now we wish to do so with a new XE216 project. Since the eval board uses QSPI, I have a few questions though.

1) Has SPI Master mode been tested and confirmed operational on XCore200? This will be the easiest for us by far since we do not need the increased speed, but I'm reluctant to do this as we then cannot compare results with the eval board which is in QSPI.

2) I presume the "QSPI" method is really QPI, i.e. 4x bidirectional data lines? The ISSI datasheet described QSPI as 4x unidirectional data lines, whereas QPI is 4x bidirectional lines.

3) I'm also very puzzled on how exactly XCore200 bootstraps for QPI. According to ISSI, the flash initially needs to first be operated in regular SPI mode and the QE bit set to engage QPI mode. This is presumably automatically done by the XCore200 when strapped for QSPI mode. When releasing the QE bit to fall back to regular SPI, this instruction should (naturally) be sent via QPI.
A scenario that didn't make sense though is what happens when the XMOS is reset (i.e. by pulling low XSYS_RST_N on the XTAG header) without power-cycle of the flash? The XCore200 would then attempt to communicate with the flash in regular SPI mode to set the QE bit, but the flash would in fact still be in QPI mode since the QE bit wasn't disengaged and the flash wasn't reset/power-cycled itself? All I can think of is that the XMOS will first attempt to set the QE bit in SPI mode without actually confirming whether the flash has responded, and then immediately continue booting in QPI mode.


henk
Respected Member
Posts: 347
Joined: Wed Jan 27, 2016 5:21 pm

Post by henk »

Hi pwatts,

1) SPI master works fine and the same as before. QSPI was introduced to xCORE200 in order to speed up boot, and because it uses fewer one-bit ports.

2) You may well be right. Keep in mind that whilst booting data is only read, so technically all but one of the wires are probably uni directional.

3) The QE bit has to be set during programming of the flash, and xflash (the part of the tools that programs the flash) does that for you. Ie, the device assumes that the flash is quad-enabled.

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

Post by mon2 »

Hi pwatts, to add to the comments from henk (XMOS)

1) do not be confused by the many options available from the respective flash memory manufacturers. You will soon observe there are many unique options from each such supplier (ie. ISSI vs. Winbond vs. Spansion / Cypress, etc.).

If you wish, you can apply an external SPI Bus Master in some high speed QUAD mode supported by vendor A but in the end, the goal is to upload your code into the flash memory while the local PCB CPU is in reset mode (parked i/o lines = tri-state if you will), be sure that the QE non-volatile bit inside this target flash memory is "1" -> done !

2) we have reviewed a few ideas on this request and in the lab, we used standard SPI commands and the startKit (took forever initially) -> as the last step, enabled the QE bit -> applied this QSPI enabled flash memory device onto the XCORE-200 CPU and all worked well.

You can follow this long thread here for the details:

http://www.xcore.com/viewtopic.php?f=7&t=4659

3) summary as noted by henk is that, the XCORE-200 CPU does not care how you upload the code into the target flash device but to allow for the XCORE-200 boot from this flash, the QE bit (non-volatile) must be enabled out of circuit. Not to further confuse the topic but during our review, but you should benchmark the time taken by the xflash tool to program the target QSPI flash vs. your external options. Believe the xflash tool was performing a page erase before the writes which was slow vs. device erase option (should be much faster). Also review if you can invoke the use of QSPI mode from the start of the process. That is, take control of the target QSPI flash -> enable the QE bit 6 of the STATUS register -> restart with the QE=1 and proceed to use only QSPI transactions to program the flash memory device. This approach should be much faster to upload your firmware in production.

QE bit = bit 6 of the STATUS REGISTER

All reviewed QSPI capable flash memory devices feature this bit in the same register, same bit offset. During our rather lengthy review of flash memory devices, we found the Spansion brand to be the best for the capacitive lead lengths (aka pin drive strength) when we interfaced against our shielded logic analyzer probes. Spansion is now under the name of Cypress. Some Winbond flash device now also feature registers to alter the pin strength value. If you keep your QPSI master interface pins short and sweet (or even pogo pins for production), you should be fine to consider very high data rates during production flash programming.

We met with a few pogo pin manufacturers during our last trip to HK in October - chime back if you want these details. Can dig them up from our catalogs.
pwatts
Junior Member
Posts: 6
Joined: Tue Feb 14, 2017 8:54 pm

Post by pwatts »

Hi Henk, Mon2,

I agree that it doesn't matter how we get the code onto the flash if either of the two processors are 'parked' in reset at a time, BUT the same issue as I outline below will apply where a reset of the XMOS does not cause a reset of the flash; specifically the QE bit. If the QE bit is set to QSPI mode (which the XMOS will do), and the XMOS is held in reset, then I cannot use SPI to reprogram the flash! I'll have to either add XMOS code for the XMOS to first de-assert the QE bit before I pull it into reset, or my external host needs to program the flash in QSPI mode. Alternatively I'll need to power-cycle while holding the XMOS in reset to ensure the flash resets and the QE bit isn't set, which is impractical.

The 3rd question does not relate to using an external master, but rather just how the boot procedure works between the XCore200 and QSPI flash during a reset that does not involve a power-cycle. To go through the steps of a chip that's strapped to boot via QSPI:

POWERUP
XMOS READS BOOTSTRAP PINS
XMOS SETS FLASH QE BIT VIA NORMAL SPI
XMOS BOOTS VIA QSPI

Now the XE216 gets reset by pulling its reset line low without removing power. Now the steps are:

FLASH QE BIT IS STILL SET TO QSPI MODE
[XMOS IS RESET; FLASH NOT]
XMOS READS BOOTSTRAP PINS
XMOS ATTEMPTS SETTING FLASH QE BIT WITH NORMAL SPI

This is the step where I'm confused. The XMOS will attempt to communicate with the flash with an incompatible protocol i.e. it will attempt to set the QE bit with SPI but since the bit is already set it expects communication to be in QSPI format. However, the bootup seems to work nevertheless. My only theory is that the flash just ignores this incompatible command and then just continues fetching its code in QSPI mode?
henk
Respected Member
Posts: 347
Joined: Wed Jan 27, 2016 5:21 pm

Post by henk »

Hi

The QE bit is actually programmed into flash; i.e., it is set once, and after that the flash acts as a QSPI flash.
So - it is not a run-time or boot-time issue, it is programmed at programming time.

So the process is:

POWERUP
XMOS READS BOOTSTRAP PINS
XMOS BOOTS VIA QSPI

Cheers,
Henk
mx12
Member++
Posts: 20
Joined: Thu Aug 18, 2016 3:22 pm

Post by mx12 »

As you have a SPI master device, I would set the XMOS to boot as SPI master too (instead of QSPI), so you don't have to switch between SPI and QSPI in the flash status register.
pwatts
Junior Member
Posts: 6
Joined: Tue Feb 14, 2017 8:54 pm

Post by pwatts »

To simplify matters since we don't need QSPI speed, I rather strapped the XE216 to boot from SPI master mode. The prototypes just arrived, but I'm experiencing some trouble:

- Running directly from XSYS works fine so there's nothing wrong with the XMOS device itself or its clocking etc. Ethernet, audio etc. are all OK.
- The three SPI Master straps measure correct as per the datasheet
- The same flash as on the XE216 evalboard is used but a slight variant, IS25LP080D-JNLE
- nHOLD and nWP are pulled up
- The pin behaviour of the four SPI pins are correct when in reset
- nCS has a 1k pullup as in the EVM, all other pins are directly connected to the flash without PU/PD resistors
- The external MCU for reprogramming the flash is disconnected to reduce the room for error
- Power sequencing has VDD applied 2ms after VDDIO & VDDIOT

When nRST is released the following is observed:
- nCS immediately goes low and remains low
- SCK is continuous at approx. 9.6MHz - this is not 2.5MHz as in the datasheet!
- MISO is continuously high
- MOSI remains low, with a single 200ns high pulse - this is the same as a single 2.5MHz clock cycle.

When attempting to program the flash via XSYS it fails and similar behaviour is observed on the SPI pins, except that the process timeouts after approx. 500ms.

It therefore would appear that MOSI wants to behave correctly but that SCK is at a rate that's almost four times faster.

Any assistance would be appreciated as the boards are useless without flash boot.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

pwatts,

your issue may be related to this incorrect boot rom code inside your controller. Not 100% sure of this but do review the details which are very similar to your observation:

http://www.xcore.com/viewtopic.php?f=7& ... Mhz#p28950

Upon power up, do you see the SPI continuously clock at about 10 Mhz ? That is the symptom of the bad rom code. The bug was raised for the dedicated audio controller from XMOS (XRHA-2HPA) so not sure if this is the same bug for your XCORE-200 CPU.

Talking out load, not sure why a faster SPI clock cannot be supported and still function properly. the SPI / QSPI interface is very capable of supporting high speed SPI clock values. Do check on the details and post your results. A bit of a wake up call as believe we may have similar devices in the building.

In addition to the above, post the relevant parts of your schematic so others can review the power supply sequencing and reset circuits of your design.

Correction to my above post...the raised issue is fixed if you use XMOS tools 14.2.0 or higher. Please review the linked post from XMOS:

https://postimg.cc/image/ffgmoz7kr/

My apologies for the panic and hope it works out for you.
pwatts
Junior Member
Posts: 6
Joined: Tue Feb 14, 2017 8:54 pm

Post by pwatts »

Thanks, I'll check it out tomorrow.
In response so far though:
- Yes, behaviour after removal of nRST is continuous 9.6MHz SCK and low nCS, with the lone singular 200ms pulse on MOSI.
- I can't comment yet on why SPI doesn't work @ 10MHz. The waveforms look fine but I have not measured relative timing to evaluate S&H violations.
- As I understand it, this problem with this OTP batch chips is not related to SPI Master boot but will still happen even if switch to QSPI mode?
- How does xtools solve the problem of booting as SPI/QSPI Master? Does it update the boot ROM?
- How can brand-new devices from DigiKey have this problem while the same XE216 chips on our much older evalboards are fine?
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

I agree with your reasoning. It is the chicken-egg scenario - on a fresh device, there must be a boot loader inside the XMOS CPU. It is that code that acts like the SPI master so somewhat confused as well. Perhaps once you compile your new code, the new code will be used (vector in) rather than the internal ROM code to act as the new boot loader. Try a simple boot from flash code like a LED blinky. Some other developers have reported that they do not see an issue even with the higher speed SPI clock but the results may vary with the brand / make you use in your design. Also, such a high speed clock is the alert flag of the rom issue which may pose a problem once your widget is out in the field. Especially if you perform field upgrades - will be not be nice to brick a working product.

Best to wait on XMOS to comment on this but the issue looks to be the same.
Post Reply