startKit and XFLASH (Flash access testing)
Posted: Wed Nov 09, 2016 5:30 pm
Hi. To better understand the xflash tool, experimenting with the startKit and have some questions.
1) Using xTimeComposer 14.2.3, compiled the working LED DEMO example (AN00175). Runs fine out of RAM so flashed to the startKit. Now the startKit runs this demo correctly upon each reset or power cycle of the kit. No issue.
2) Went to DOS prompt (command line mode) and applied the following command:
xflash --target startkit --erase-all ; to erase the XMOS supplied serial flash device
The AN00175 LED DEMO stopped working after a few seconds (assuming the code was erased).
Power cycled the board and now the LED (breathing) demo is the boot default on the same startKit. From where is this breathing LED being being retrieved ? If this is from the visible 8 pin SOIC flash device, should the --erase-all not have erased that code as well (ie. chip erase) ?
Or is this led demo example inside the boot ROM of the CPU on the startKit ? Not sure if we did this or was this a factory supplied demo which loads in the absence of a blank external SPI flash ?
Just trying to understand the features and limits of the xflash tool...
Will hot air off this SMD flash device to confirm our understanding in a few minutes.
3) Another question - the XN file defines the hardware properties of the startKit (in this example). Found the SPI pin mappings to / from the CPU and the local SPI device. For some experimenting, wish to use a 4 bit port (ie. for pending QSPI testing). Did see some chatter that the XN file now offers QSPI support but not sure if the QSPI support extends to the CPU on the startKit.
Specifically, is the QSPI support for the new XCORE-200 series and forward ? Believe this is true as the 4 bit port must move in the same direction on the CPU soldered on the startKit. On the XCORE-200 some tricks can allow for the 4 bit port to be used in different directions. Please confirm if the understanding is correct.
1) Using xTimeComposer 14.2.3, compiled the working LED DEMO example (AN00175). Runs fine out of RAM so flashed to the startKit. Now the startKit runs this demo correctly upon each reset or power cycle of the kit. No issue.
2) Went to DOS prompt (command line mode) and applied the following command:
xflash --target startkit --erase-all ; to erase the XMOS supplied serial flash device
The AN00175 LED DEMO stopped working after a few seconds (assuming the code was erased).
Power cycled the board and now the LED (breathing) demo is the boot default on the same startKit. From where is this breathing LED being being retrieved ? If this is from the visible 8 pin SOIC flash device, should the --erase-all not have erased that code as well (ie. chip erase) ?
Or is this led demo example inside the boot ROM of the CPU on the startKit ? Not sure if we did this or was this a factory supplied demo which loads in the absence of a blank external SPI flash ?
Just trying to understand the features and limits of the xflash tool...
Will hot air off this SMD flash device to confirm our understanding in a few minutes.
3) Another question - the XN file defines the hardware properties of the startKit (in this example). Found the SPI pin mappings to / from the CPU and the local SPI device. For some experimenting, wish to use a 4 bit port (ie. for pending QSPI testing). Did see some chatter that the XN file now offers QSPI support but not sure if the QSPI support extends to the CPU on the startKit.
Specifically, is the QSPI support for the new XCORE-200 series and forward ? Believe this is true as the 4 bit port must move in the same direction on the CPU soldered on the startKit. On the XCORE-200 some tricks can allow for the 4 bit port to be used in different directions. Please confirm if the understanding is correct.