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
xflash speed in production
-
- Active Member
- Posts: 37
- Joined: Mon Sep 24, 2012 1:45 pm
-
- XCore Expert
- Posts: 580
- Joined: Thu Nov 26, 2015 11:47 pm
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.
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.
-
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
@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.
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.