XUF208 in field update

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

XUF208 in field update

Postby genap » Wed Jun 03, 2020 5:49 pm

I have a system with an ARM microcontroller and two XUF208 chips for usb audio.
The problem I have is the manufacturing and field update of XMOS chips.
In my previous system setup was about the same, but with two XS1-U8A.
On power-up controller sent request to XMOS (pin toggle) and XMOS responded with the version number over UART (on a separate core). If version is wrong, the external flash memory is disconnected from XMOS and connected to uC (by external multiplexer) for programming. After programming memory is switched back to XMOS. Then the same procedure is executed for the second XMOS.
This approach allowed us to eliminate XMOSs programming in manufacturing, eliminate necessity to reprogram each chip by DFU for update, and remove large JTAG connectors and save space.
In my current situation with XUF208 I have a few questions.
1. I believe I can interface uC to the XMOS through the QSPI bus.
I would like to use SPI for programming (easier and saves few pins and traces), but I can't see how I can do it since QE bit in a flash is preprogrammed for QSPI and in order to set it for SPI I need to use QSPI, what doesn't make sense. I
don't see any way around it. Is there any?
2. I would like to eliminate version request and UART use and read version from a flash memory directly. But for this I need to place version (3 bytes) at the particular static address. Does XMOS programming allow to do that?
3. In order to work with two XMOS chips I will need to connect QSPI buses (except chip selects) in parallel. I believe that since memory programming is done under chip reset and CS is high, the data lines will be tri-stated on inactive
chip.
Is there a problem with this conclusion?

Will appreciate any advise on the the above questions.
Thank you.
User avatar
mon2
XCore Legend
Posts: 1836
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Wed Jun 03, 2020 6:33 pm

Hi. Will re-read your post with a clear head later today but:

The QE bit can absolutely be programmed using standard SPI commands. We posted the source code for this using the StartKit a while ago. Please search for it or can locate the link and share with you later.

That is, even if the flash is in QSPI mode or not, SPI commands still work.

Hope this helps. Post back if you cannot locate the posted project for the SPI master.
genap
Experienced Member
Posts: 86
Joined: Sat Aug 31, 2013 11:23 pm

Postby genap » Wed Jun 03, 2020 10:58 pm

I searched forum posts but still couldn't find how I can clear the QE bit by SPI when when the flash is in QSPI mode.
So I will appreciate if you point me to the right resource.

Thank you
User avatar
mon2
XCore Legend
Posts: 1836
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Thu Jun 04, 2020 1:41 am

Hi. My google-fu is in a weakened state. Need more coffee. Also could not locate the original post but sure it is buried in here somewhere.

Anyways, here are the details again.

So to program the QE bit using any XMOS CPU:

a) locate 4 port pins that are single bit ports - the values shown in the attached project are from the XMOS StartKit (now an EOL kit). The single bit port pins are important to allow for individual port pin use (direction control) demanded by the SPI Master interface.

b) Each such port pin will be used to interface with the target SPI device (CLK, CS, MOSI, MISO)

c) Then using these port pin mappings, run the supplied code which will make calls to the SPI flash library and communicate with the SPI flash device

d) Review the datasheet for your flash memory and you will see the SPI commands (ignore the QSPI commands for this process) - you can use this same method to dump the IDs of the flash; the MANUFACTURER ID of the flash, etc. to get your feet wet. Many SPI commands are common across the industry but some are not.

Finally, use the same setup to read out the QE bit setting or to WRITE the QE bit.

mon2_workspace_spi_v2.rar
You do not have the required permissions to view the files attached to this post.
genap
Experienced Member
Posts: 86
Joined: Sat Aug 31, 2013 11:23 pm

Postby genap » Thu Jun 04, 2020 3:10 am

Thanks a lot, mon2.
There 2 problems I see in using this approach in my design:
1. I don't have enough available 1-bit ports.
2. As far as I understand, this method will work for update, but not for unprogrammed chip or chip with corrupt program (and I need that), since it operates by using program already on a chip.

If it is so, the only way I see is to use QSPI.
But in this case there is another question - do we know the state of a QE bit on unprogrammed XUF208?
If it is 1, I can proceed with programming by QSPI.
If it is 0, I can use SPI (I can map it on a microcontroller to the same pins as QSPI) to set QE to 1 and then use QSPI for programming.
But I need to know the initial state of this bit.

Now to the original questions 2 and 3:
Q2. I couldn't find how I can assign absolute address to the data (in my case version).
If it's impossible, I can manually insert version into the generated binary at certain address and then read at that address.
Q3, As I understand, I can use the same QSPI for two chips (with separate chip selects) as long as I operate on them one at a time.

Please confirm my conclusions or tell me where I am wrong.

Thank you.
User avatar
mon2
XCore Legend
Posts: 1836
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Thu Jun 04, 2020 4:17 am

Hi.

1) correct that you can use an external micro to

a) park the CPU by asserting a LOW onto #Reset pin. This will tristate the CPU interface lines.

b) proceed to use the external micro to communicate with the internal flash

2) the state of QE bit does not matter. You can communicate with the internal flash using SPI interface, even if the flash has QE bit enabled. You as the SPI bus master, will send out commands that are SPI specific. These command include R/W of the QE bit.

3) using the code example posted, you can use this code and the documented internal lines used by your CPU to access the flash. See the xuf208 datasheet. This includes the R/W of absolute addresses. Just be sure the flash memory locations are free.
genap
Experienced Member
Posts: 86
Joined: Sat Aug 31, 2013 11:23 pm

Postby genap » Thu Jun 04, 2020 5:26 am

I didn't know that I can use SPI interface with QE bit set.
Seems like I've missed it reading the flash datasheet?
User avatar
mon2
XCore Legend
Posts: 1836
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Thu Jun 04, 2020 10:18 am

See page 9 of the attached document.

XMOS uses the qspi flash from ISSI but the compatibility is the same. If you use SPI commands, SPI interface pins and timing applies.
AN0251V1 - Macronix Serial Flash Multi IO Introduction.pdf
You do not have the required permissions to view the files attached to this post.
genap
Experienced Member
Posts: 86
Joined: Sat Aug 31, 2013 11:23 pm

Postby genap » Thu Jun 04, 2020 2:21 pm

Thank you!
What is strange is that they mention only Read commands, no writes. Is Write also possible ?

Was this verified for XUF ?

If both read and write are possible, I can use SPI for programming, right? And then to make sure QE is set for XMOS boot.
Also, if I use it in SPI mode, do I need to put pull-ups on WE# and HOLD# (IO2 and IO3) ?

BTW, by mistake I assumed that the code you've posted is for a chip under programming, not SPI host :(

Thank you again.
genap
Experienced Member
Posts: 86
Joined: Sat Aug 31, 2013 11:23 pm

Postby genap » Thu Jun 04, 2020 2:46 pm

Also, the datasheet says that 1K pull-up is required, and somewhere in a forum I read this will force XMOS to boot in QSPI mode.
But if there is no pull-up (pin is floating), will XMOS boot in SPI mode ?

Who is online

Users browsing this forum: No registered users and 1 guest