xflash speed in production

[aelder]

Hi all,

What is the theoretical fastest time to program a XLF208-256-TQ64 using xflash in a production environment?

We are using

xflash --quad-spi-clock 50MHz --factory xmos_factory.xe --loader xmos_loader.o --boot-partition-size 0x180000 --data info.dat

and we observe programming times of 2 minutes and 40 seconds. What can we do to speed up the programming?

Thanks,
Andrew

[akp]

If you are using the exact same binary each time (i.e. info.dat doesn't change) then try writing a factory binary once to disk using

xflash -v --noinq --factory xmos_factory.xe --loader xmos_loader.o --boot-partition-size 0x180000 --data info.dat -o xmos_factory.bin

Then each time you program, use that binary

xflash --quad-spi-clock 50MHz --target-file <target file.xn> --write-all xmos_factory.bin

The chip will run the binary when you power cycle it.

Alternatively, if the info.dat needs to be modified for each different widget produced, you can use the --no-compression flag to disable flash compression which will also substantially speed up the firmware load, but at the expense of no compression. Or you can use the --no-compression-validation which will skip the length process of making sure the compression is OK. Regardless with any of these optimizations you will save maybe 30 seconds to 90 seconds per widget flash.

If you can make the boot partition smaller that should also save some time as fewer sectors will need to be written

Look forward to hearing your results.

[mon2]

@aelder, has been a while in using xflash but as akp noted, do apply the -v flag (verbose) and confirm if the xflash tool performs a target chip erase. From (perhaps my fading memory), the xflash tool was taking eons to perform a page erase before writing the custom code to the flash. This was years ago. That is, it would be much wiser to perform a FULL CHIP erase which is much faster and may be practical for your production case.

Game plan would be to:

1) Attach to the target flash device
2) Read out and verify the flash ID / vendor ID to confirm all is well using standard SPI commands - we have posted the source code for this task using StartKit on this forum
3) Perform a full chip erase using standard SPI flash commands
4) Enable the QSPI bit for further QSPI command use
5) Apply QSPI commands and formatted traffic to quickly upload your custom code
6) Verify using QSPI commands the contents of the flash device to match your original binary

The xflash tool is closed source which sucks I recall us writing our own custom IP with QSPI support which was much much faster using the xmos CPU so it is possible to do this to expedite the production line. The other suggestion is to apply some zero force pogo pin jig where you use an external tool to park the CPU (tristate) the SPI / QSPI lines and the external tool then rapidly performs the flash programming. Could be done with another XMOS device and/or FPGA, commercial QSPI flash CPU / programmer. Many options here but the time reported is just silly for each widget to be programmed.