xCore-200 XUF line internal flash

Technical discussions around xCORE processors (e.g. General Purpose (L/G), xCORE-USB, xCORE-Analog, xCORE-XA).
genap
Experienced Member
Posts: 86
Joined: Sat Aug 31, 2013 11:23 pm

xCore-200 XUF line internal flash

Postby genap » Wed Jun 10, 2020 2:19 pm

The XUF line of xCore-200 uses the IS25LQ016B as internal flash device.

I've received a message from ISSI that the IS25LQ016B is not recommended for new designs.
Instead they recommend to use the IS25LP016D .
http://www.issi.com/WW/pdf/25LP-WP016D.pdf

And the IS25LQ016B is not shown anymore in the ISSI product list, but is shown as an alternative to the IS25LP016D.
Does this mean that it's better to use XU line devices with external IS25LP016D flash instead of XUF for new designs?
User avatar
mon2
XCore Legend
Posts: 1829
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Wed Jun 10, 2020 3:50 pm

Hi stranger :)

1) The XUF is a solid solution with an internal flash. The XMOS tools are able to use this flash with ease.

2) Which XMOS CPU are using in your design? Study the datasheet to confirm if an external flash can be used or not. The smaller devices do not offer this luxury. The larger pinout devices do offer options using the MODE pin.

3) No matter which model they recommend or even different vendors although ISSI support was off the charts when we reviewed the XRHA XMOS CPU and a related QSPI issue - see the forum for full details. It is rare to receive this high level of support from a semiconductor manufacturer. So for this reason, recommend you consider ISSI as a primary vendor.

If you do use a different part number then you must create a text file that will define the full details of this external flash device and pass this text file to the xflash command line tool. The QSPI flash definition file must be supplied if it is different than the basic list of parts supported by the toolchain by the factory. Google / search this forum for this topic. Will try to locate the same document references perhaps later today.

Summary:

Only if your CPU supports it, use the MODE pins to strap the use of the EXTERNAL flash device but this will only work IF you supply a custom SPI / QSPI flash definition file. Then you are good to go :)
genap
Experienced Member
Posts: 86
Joined: Sat Aug 31, 2013 11:23 pm

Postby genap » Wed Jun 10, 2020 4:04 pm

I am using XUF208-256-TQ64.
Considering to use XU208_256_TQ64 - it is available and it's using external flash.
User avatar
mon2
XCore Legend
Posts: 1829
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Wed Jun 10, 2020 4:10 pm

The XU208_256_TQ64 looks fine. You can see many products on Aliexpress with this CPU and an external flash.

Be sure to apply external pull-downs to force the "000" strappings onto X0D06, X0D05, X0D04. Then proceed to use the QSPI interface and their recommended pinout.

Alternate is to use the SPI MASTER strappings and then the slower SPI interface will be used to boot in the firmware.

The external flash you use must be already supported by the XMOS tools OR you can define your own custom table and pass this filename to xflash for use.

viewtopic.php?t=6448
genap
Experienced Member
Posts: 86
Joined: Sat Aug 31, 2013 11:23 pm

Postby genap » Wed Jun 10, 2020 4:25 pm

I am going to use SPI for programming and QSPI for boot. ISSI have confirmed that their 25 flash line accepts SPI interface even with QE bit set.
User avatar
mon2
XCore Legend
Posts: 1829
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Wed Jun 10, 2020 4:34 pm

Yes, unless stated, the QE bit = "0" from the factory.

However, once you create the custom QSPI flash definition file - the xflash tool will proceed to enable the QSPI bit (QE = "1"). You have many options here but the quick one is to allow the xflash tool to QSPI enable this flash.

A bonus if you allow for the end user to park the CPU and use the external SPI MASTER tool to correct dead flash devices. End users will appreciate it.
genap
Experienced Member
Posts: 86
Joined: Sat Aug 31, 2013 11:23 pm

Postby genap » Wed Jun 10, 2020 7:14 pm

I am not going to use xflash tool. The blank chip will be programmed by SPI from ARM host (xmos image file is stored on arm).
Then QE will be set by SPI.
On an update the flash will be reprogrammed by the updated image stored on ARM.
So the end user will not need to do anything but update the system image on ARM through the network :)
User avatar
akp
Respected Member
Posts: 447
Joined: Thu Nov 26, 2015 11:47 pm

Postby akp » Thu Jun 11, 2020 4:26 pm

Just spitballin' -- did you consider going without any flash for the XMOS part (e.g. XU208) and instead use the XMOS spi slave boot mode? Then whenever you turn on the XMOS part you just transfer over the image from the ARM part. It would save you a dollar per board at least I should think.
genap
Experienced Member
Posts: 86
Joined: Sat Aug 31, 2013 11:23 pm

Postby genap » Thu Jun 11, 2020 4:34 pm

akr,

That could be a valid option.
But my concern is not really a price, but ability to program a blank flash and upgrade it from a host if necessary.
I have two XMOS devices on a board with different programs.
Almost always boot will be QSPI fast. And in a rare situation when programming is needed the time spent for it is justified.
User avatar
akp
Respected Member
Posts: 447
Joined: Thu Nov 26, 2015 11:47 pm

Postby akp » Thu Jun 11, 2020 4:51 pm

Of course. Transferring a binary image to an XU208 via SPI at 10MHz should take less than 200msec for a maximal image size, but I could see if that's too much time to boot.

Who is online

Users browsing this forum: No registered users and 1 guest