XUF208 in field update

[mon2]

Hi.

1) See attached on the recommended pull-up wiring of the external 1K that is required to boot from the internal QSPI flash device.

2) Be aware that you should not make use of these same pins externally - recommended - main reason being that you could load down these lines that are being used by the internal QSPI flash device during boot / reset cycle. If you are confident that the boot cycle is completed then you could consider to use these pins for other purposes but be sure to validate your external circuits do not load down these lines upon power / reset cycle. If you are pinched for I/O then use external logic (buffers) onto the same port pins but enable them ONLY after a few seconds have expired -> to guarantee the flash code has booted and then these port pins will be idle. Again, do test the logic to be sure of the timing.

3) On past devices - perhaps with more port pins - the XMOS datasheets do define a number of methods to boot the firmware for this CPU including QSPI or even SPI modes. These are the MODE pins. Which package size of the CPU do you plan to use? The TQFP 64 is not supporting of these alternate boot modes so you MUST use the internal QSPI flash device.

4) Regardless of which XUF208 package you use, the internal flash is from ISSI and this flash device is able to be accessed using standard SPI mode with an external SPI bus master (ie. could even use Total Phase bus master, STM32, another XMOS CPU, etc.) - the key is to force the target CPU you wish to program to be tri-state by parking #RESET to be LOW and keep it low while you are R/W this same flash device. Then proceed to communicate with the internal flash device using SPI or QSPI modes. Even if the QSPI flash bit QE = 1 for the QSPI mode, you can still perform the slower SPI commands as required including extracting the ID, R/W using the slower SPI modes.

The posted code for the StartKit was used to program the same QE bit using standard SPI communication as a SPI bus master. Fairly confident that the flash device inside this CPU will have QE = 1 from the factory during assembly time but however, it is trivial to do the same using an external flash programmer. In fact, believe it will be faster than using the XTAG3 tool to do the same.

Our company is all about CYA (cover your ...) so we embed everything including the kitchen sink. Glad we have done so as the customer demands - 10++ years after the product is in the field - allows us to work around real complex cases related to Windows, Linux and bios faults raised by Tier 1 computer manufacturers. You have a better chance of winning the lottery repeatedly than to get a large OEM to recode their bios because of a 3rd party product. For the same reasons, do all that you can to squirm out of such corner cases that may "brick" your box.

Highly recommend that you consider to include a small footprint to support the XTAG3 board - ignore the large 20 pin IDC header and place only the min required for JTAG use by perhaps the TAG CONNECT or similar pogo pin style interface. This way, you can flash program using the official XMOS toolchain (ie. no special coding required) your target PCBA BUT also include your original idea of a low cost external USB HID model or similar SPI flash tool. It should be possible to build such a widget using the STM32 CDC to SPI like follows (random link from the internet) - for about $1 USD for the BOM:

https://github.com/lenniea/stm32-usb-spi

Then the end user could easily reflash the target XUF flash via SPI and any host PC. Be sure to code this STM32 to force the #RESET on the XMOS CPU to be LOW during this process. The CDC model is supported by all major operating systems including Windows, Linux, MAC and others.

Consider to place a very common, low cost USB 2.0HS MUX to switch the signals either to the XMOS CPU (default) or your embedded STM32 SPI flash programmer (alternate mode of the mux).

So to close, the external 1K is required + the QE bit must be "1" to allow for the QSPI flash to communicate with the internal boot mechanism using QSPI mode. If QE = "0", the flash could still hold your firmware but the CPU will not boot as it is configured for standard SPI mode. This was a common error on the older (now EOL) XHRA Audio CPU. The XCORE-200 series CPU demands the boot flash be QSPI enabled.

Hope this is clear.

XUF208_boot_flash.png

[genap]

Hi mon2,

Thank you for the detailed explanation.

So the procedure I am going to use is as follows:
- prepare the bin file for a flash programming
- manually (or by a bat. program) insert version and maybe CRC into the binary at the end of a 64K block
- put the XMOS chip under reset by the arm host
- configure host for SPI master
- read version and CRC from a flash, calculate CRC if desired
- if version is incorrect (outdated or the memory is blank), or CRC doesn't verify, program internal flash using SPI (slower, but easier)
- set QE bit
- deactivate host SPI interface and tri-state XMOS QSPI pins
- after delay deactivate the XMOS Reset by the host

The only (for now) question is about pins IO3, IO4. They are connected to the WP and HOLD flash pins and should be high when using SPI.
I don't know if SPI programming will work if I leave these pins unconnected.
So if these pins should be high, I can set them high by the host (extra traces) or put weak (100K) pull-up on them. I don't know if pull-ups will interfere with XMOS QSPI boot.
Do you have any considerations on this?

Thank you

[genap]

I understand stuff related to the SPI master. And that QSPI flash can operate in SPI mode for programming under reset.
What I don't fully understand is it's connection to the QSPI pins on the XUF208.

XUF208_256 datasheet states:
Page 14: "X0D04..X0D07 should be not connected" (page 14).
Page 73: "Pins X0D04, X0D05, X0D06, and X0D07 are output only and are, during and after reset, pulled low or not connected (Section 8).

From the IS25LQ016B datasheet:
Pin 1 - CE# - I assume it's connected to X0D01 (CS_N of QSPI) and should be connected to CS of the SPI Master (with 1K pull-up).
Pin 6 - SCK - I assume it's connected to X0D10 (CLK of QSPI) and should be connected to CLK of the SPI Master.
Pin 5 - SI (IO0) - I assume it's connected to X0D04 (IO0 of QSPI) and should be connected to the MOSI signal of the Master.
Pin 2 - SO (IO1) - I assume it's connected to X0D05 (IO1 of QSPI) and should be connected to the MISI signal of the Master.
Pin 3 - WP# (IO2) - (X0D06). For SPI mode the flash requires this pin to be high. I assume it's not connected to the SPI master. So what is the state of this pin during SPI master operation?
Pin 7 - HOLD# (IO3) - (X0D07). For SPI mode the flash requires this pin to be high. I assume it's not connected to the SPI master. So what is the state of this pin during SPI master operation?

So how do I connect SPI master to the QSPI pins?
Statements from XMOS and ISSI datasheets are contradicting.

I am totally confused.
Please help me to figure it out.

[mon2]

Hi.

Page 14: "X0D04..X0D07 should be not connected" (page 14).

Meaning that X0D04..X0D07 should not be under load externally. This is to avoid possible conflict with the internal flash during boot time. If you are wanting to use these pins for other purposes, you will have to come up with a scheme that either after xx period of guaranteed boot time expires, only then proceed to make use of these pins for your own alternate code. However, be sure that the internal flash is not enabled (#CS = HIGH) during such access.

Page 73: "Pins X0D04, X0D05, X0D06, and X0D07 are output only and are, during and after reset, pulled low or not connected (Section 8).

This is because a 4B port present on the CPU is being used. With the #RST = "0" on the CPU, the port pins will be tri-state. This is one of the recommended procedures to flash the internal flash using external flash tools / programmer as you are considering to build. See attached document.

Guidance-for-mass-production-programming-of-integrated-flash-in-xCORE-200_3.pdf

From the IS25LQ016B datasheet:
Pin 1 - CE# - I assume it's connected to X0D01 (CS_N of QSPI) and should be connected to CS of the SPI Master (with 1K pull-up).
Pin 6 - SCK - I assume it's connected to X0D10 (CLK of QSPI) and should be connected to CLK of the SPI Master.
Pin 5 - SI (IO0) - I assume it's connected to X0D04 (IO0 of QSPI) and should be connected to the MOSI signal of the Master.
Pin 2 - SO (IO1) - I assume it's connected to X0D05 (IO1 of QSPI) and should be connected to the MISO signal of the Master.

Yes.

Pin 3 - WP# (IO2) - (X0D06). For SPI mode the flash requires this pin to be high. I assume it's not connected to the SPI master. So what is the state of this pin during SPI master operation?
Pin 7 - HOLD# (IO3) - (X0D07). For SPI mode the flash requires this pin to be high. I assume it's not connected to the SPI master. So what is the state of this pin during SPI master operation?

Apply 10k or similar pull-up resistors to +3v3 for these pins to park their states as inactive. You should be fine to consider leaving these external resistors always in the design as they are not strong enough to override the internal QSPI traffic. That is, when you do wish to use your external SPI master, either you will be introducing these resistors externally but then your programming jig will need to add 2 more connections OR place room for these pull-up resistors in your design now and use low enough value to not impact the QSPI operation but strong enough for the external SPI programming tool to park to a default of "1". Do not leave these pins floating. Resistor networks like the SMD 1206 size from Yageo are a good, low cost and common choice. Do not use 2 x resistors in a RN as they are crazy priced with respect to the 4 x resistors (0603) in a 1206 package. Actually are a multiple times the cost of the 4 resistors in a network - perhaps due to low volumes of use and production. We use the 1206 (4 bangers even if only 2 are required) all the time and they are cheaper than dirt and common to source if you end up building in Asia or elsewhere. Using such grouped parts will save on your SMT assembly fees.

If #WP = "0" then the flash is WRITE PROTECTED - not desirable.
If #HOLD = "0" - the the flash is placed on HOLD (PAUSE) for the communications between the SPI MASTER and this SPI SLAVE - usually not desirable.

Off topic but important - do apply USB EMI filters in series with your design - very common and low cost to use from Digikey / Mouser, etc. and then offshore. Somewhere in this forum, have shared where we source these parts. Suitable for USB 2.0 and/or USB 3.1 designs.

Also, very important to place low impedance ESD protection devices on at least the USB 2.0 lines.

From our research, the TI ESDS312 appears to be the best in the market:

https://www.ti.com/product/ESDS312

Wherever you have outside world potential contact, review their normal voltage range and apply ESD protection there as well. As always, test and retest before mass production. Our philosophy is to throw alternate parts onto the PCBA and pick-off what may be deemed as not required afterwards. Simple to pick off rather than to add after the PCB is assembled.

Be sure to review the PCB layout for impedance controlled traces for the USB 2.0 High Speed lines @ 90 ohms. 4L or higher is highly recommended. The PCB shop should be informed of these special traces and they MUST perform the TDR testing of these connections to confirm that they have the proper impedance control for the applied laminates. That is, they will tweak the traces to suit the laminate being used by the factory.

The simple but effective XMOS MOUSE IP is great to test out custom PCBs to validate your design is able to communicate @ 480 Mbps - the MOUSE HID IP operates @ USB HS.

[genap]

Hi mon2,

The picture is a lot more clear now thanks to your recommendations.
I am also considering using XU208 instead of XUF.
In this case if SPI access doesn't work good for ISSI memory, I can replace it by another memory. Though XUF is more convenient.
What do you think?
Also I was trying to find a structure of a binary programming file, in particular location of a file size and CRC. Couldn't find it anywhere.
Do you have an idea where I can look for it?

Thank you.

[genap]

I've sent an email to the ISSI about SPI support in QSPI mode.
Here is the response:

Our IS25 series of flash supports SPI commands even when the QE bit is enabled.
The IS25LQ016B is an older part and not recommend for new designs.
The latest 16Mbit is the IS25LP016D and the DS is here:
http://www.issi.com/WW/pdf/25LP-WP016D.pdf

Please consider moving to the new die for your design.