Xcore200 External flash programming

[MarcAntigny]

Hi all,
We are working with Xcore 200 (XU232) based on the Audio USB software reference. We use a custom flash (ISSI IS25LP016D) addressed in QSPI, a custom loader (needed for factory image recovery) and data partition.
Currently all of this configuration works with JTAG programming (using xflash etc...). The DFU is ok too (except it doesn't update factory image but that's normal behavior).
We edited a binary file (with xflash command) to program directly the flash by direct writing with external programmer (our manufacturer tried it for us and need it for mass production). However it doesn't work (unit doesn't boot). The binary file contains the bootloader, a factory image, an upgrade image and the data of the data partition (everything packed with xflash -o command)
We dumped the programmed flash and compared it with the binary file sent to our manufacturer. The dump file and the original file are identical (exactly the same bits). It should work as the flash content and the file are identical, no ?
So what did we missed ? Is there some specific flash writing needed ?
Thank you, we really need some help on this topic.
Marc

[mon2]

Check the QSPI Enable Bit for your flash device. Most likely this step was missed.

If the XCORE CPU is strapped to boot from a QSPI flash, then this QSPI Enable bit must be enabled.

Please confirm and post your results. Also, post your xflash command exactly as used for a review.

Pretty sure that the XMOS tools are capable of enabling this bit for you or you may do so using the XMOS Startkit (we posted the source code here somewhere in the forums) or your choice of external flash programming tool.

This thread may be worth a quick read:

https://www.xcore.com/viewtopic.php?t=5874

This is Bit 6 of the STATUS REGISTER as shown here in the datasheet:

qspi_bit.png

[MarcAntigny]

Hi mon,
I did a mistake. The flash we use currently is the IS25LQ016B. We will switch to IS25LP016D later. The IS25LQ016B is supported "natively" by XMOS tools so the support of QSPI is done yet (?).
Or maybe I need to configure more things to have it boot in the right way ?
The xflash command is :

Code: Select all

xflash --factory image1_0_0_FACTORY_AF4.xe -v --loader loader.xc --upgrade 1 image1_0_0_DEVBUILD_AF4.xe --boot-partition-size 0x1ff000 --data data.bin --noinq -o binary_file.bin 

[mon2]

Would you have a local pull-up resistor on X0D01 to +3v3 in your design?

I see a 1k value to +3v3 (X0D01 = SPI_CS) used in the XMOS reference audio kit schematics.

[MarcAntigny]

I am not in charge of hardware design but I will check with the person involved.
Do you think it could be a significant lack for the QSPI communication ?

EDIT : Yes we have a 1k pull-up to 3.3V on QSPI_CS (X0D01)

[mon2]

1K resistor is required and good that you have this.

If you code up a small LED blinky program -> flash using the IDE toolchain -> the LED blinky will work fine upon each power up / cold reset?

Please run your xflash tool again but insert --verbose into the command line and post your results.

[mon2]

Also review AN00185

Boot an xCORE-200 device from QuadSPI
flash memory

to compare notes on the use of the QSPI flash.

[MarcAntigny]

Hi mon,

If you code up a small LED blinky program -> flash using the IDE toolchain -> the LED blinky will work fine upon each power up / cold reset?

When we flash with JTAG (IDE toolchain or command line), all of our code works well (same in debug, run). The issue comes with flash IC programmed by our manufacturer with the binary file. That is why I dumped the flash to check if there are some diff between the bin we provided and the flash content. But the content is exactly the same as the bin file.

Please run your xflash tool again but insert --verbose into the command line and post your results.

The -v option does the same thing, isn't it ?

Also review AN00185

As I wrote, the issue is not linked to Quad SPI booting when the flash was programmed with xflash command but with booting when the binary file was written directly on flash IC.

[mon2]

Hello. Please review this thread:

https://www.xcore.com/viewtopic.php?t=4659&start=40

It is possible that your byte or nibble ordering is reverse from what it should be. It is worth a try. That is, swap your high and low bytes in the dump -> program the external flash and test again.

Another option is to program your code using the XMOS tool chain over JTAG into the target flash device -> confirm the flash is able to boot upon each power up cycle. Then desolder this programmed flash IC -> ship to your flash programming company and ask them to clone the IC as-is. Suspecting that you are forwarding the bin file and the byte ordering is reverse as we found in the above referenced thread.

Please post your results.

Update - you can use xflash to READ back the flash programmed from the outside firm and then perform a binary compare against the golden known good sample.

[mon2]

More ideas...

1) program up your code using JTAG and XMOS tools into the external flash. Confirm the PCB boots your custom code (LED blinky, etc.) upon each and every power cycle as expected.

2) desolder this IC off your working PCB and transplant onto your custom PCB that you wish to take into production.

Does your custom PCB now boot and behave like the original? It should.

This is how we debugged the original firmware when working with the XHRA design by XMOS.