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

Post by pwatts »

Thanks for the assistance; hopefully comments are forthcoming shortly. A workaround to access the flash after it has booted from another source such as SPI Slave or JTAG is pretty useless though.
Our methodology for XS1 was to use a MCU via an Ethernet-capable CPU to program the flash both for field updates and initial factory-load to avoid needing special programmers for either. The same method was understood to be fine for XCore200 (and I even raised it in this thread earlier to confirm since it is a critical design parameter).


pwatts
Junior Member
Posts: 6
Joined: Tue Feb 14, 2017 8:54 pm

Post by pwatts »

Follow-up: we use the latest xtools 14.2.4. However, even when attempting to program the flash via XSYS it still fails. The board traces are very short and with continuous ground plane so I doubt a signal integrity issue.
User avatar
Thomas
Experienced Member
Posts: 66
Joined: Fri Feb 05, 2010 12:34 pm

Post by Thomas »

Some words of clarification:
The XHRA-2HPA-TQ64 uses a custom boot loader which is burned into the OTP.
The OTP is an internal one-time programmable memory which can be used to override the standard boot loader in the ROM.

All other XMOS chips including XE216 use the standard bootloader in the ROM. This is a fixed internal memory and cannot be changed.
That means the issue found in the custom boot loader of XHRA-2HPA-TQ64 does not apply to XE216.

Chapter 7 Boot Procedure in the Datasheet has more information about the various boot sources.
Post Reply