startKit and XFLASH (Flash access testing)

All technical discussions and projects around startKIT
User avatar
mon2
XCore Legend
Posts: 1679
Joined: Thu Jun 10, 2010 11:43 am

startKit and XFLASH (Flash access testing)

Postby mon2 » 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.
User avatar
mon2
XCore Legend
Posts: 1679
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Wed Nov 09, 2016 6:03 pm

Answering my own first question:

1) Removed the SMD flash device @ U4. With the absence of the SPI flash memory @ U4, the breathing LED demo continues to load upon power up. This confirms that the breathing LED demo is a factory supplied demo and is inside the boot OTP rom. Respectively, if a valid program is detected inside of U4, the boot rom will proceed to jump and run the code from the external SPI flash.
colin
Experienced Member
Posts: 74
Joined: Mon Dec 16, 2013 12:14 pm

Postby colin » Fri Nov 11, 2016 3:09 pm

Hi mon2,

Yes, there is support now added to the XN for QSPI devices. As you rightly point out the intention of the QSPI device is for use with the xCORE-200 devices. That said I don't think XFLASH enforces that a QSPI cannot be attached to an L series device nor is there any xCORE-200 specific code in the QSPI implementation and thus it MAY be possible to do this on the startkit. It is not something I have done myself and I would be interested to hear if you make any progress on it.

Colin.
User avatar
mon2
XCore Legend
Posts: 1679
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Fri Nov 11, 2016 3:27 pm

Hi Colin. Thanks for your comments.

1) Fairly confident that the glowing (breathing) LED demo is inside the XMOS CPU OTP. Is that correct ? We have confirmed that the same demo continues to load even though we have removed the Winbond SPI flash on the startKit.

2) Performing assorted tests and learning a lot. Using the (slightly fixed) SPI Library code in SPI_MODE_0, we can now read from the same Winbond SPI on the startKit. Before leaving for the day yesterday, ran the SPI Command 03h (read flash), 90h (read vendor and device IDs) and 9Fh (JEDEC ID read) with success. According to the Beagle tool, the amount of time did not vary although we did alter the SPI speed value during these access calls. Tested with 1, 10 and 100khz values during the calls. Have not yet confirmed the CLK pin width using an external tool (logic analyzer, etc.).

3) For now, using the StartKit pin mappings as-is which are single bit ports for the SPI testing. Respectively, the same single port pins are not suitable for use in QSPI mode. Ran the xflash tool:

xflash --target startkit --erase-all ; this works to erase the Winbond flash on the Startkit - then the glowing LED demo boots since the user flash is now empty otherwise our LED blinky code boots as expected

Also ran our SPI read commands and confirmed that the XMOS firmware code we wrote is present inside the same SPI flash command.

4) Have assorted goals including to read / verify and/or enable QUAD SPI bit using simple SPI commands with the StartKit. Then simple (slower !!) write access can be made with the SPI flash footprint on the StartKit. This will be performed today. ie. simple and low cost method to prepare the QSPI flash for the XRHA processor using the StartKit.

more details later but first goal is to R/W in QSPI mode using StartKit...
User avatar
mon2
XCore Legend
Posts: 1679
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Fri Nov 11, 2016 5:51 pm

Correcting my earlier comments. The timing of the SPI routines indeed do vary with the passed parameters. Must have been late in the day...

Image

Image

Who is online

Users browsing this forum: No registered users and 0 guests