XHRA-2HPA-TQ64 - Not showing activity after SPI, also SPI_CLK @ 10Mhz? Topic is solved

Technical discussions around xCORE processors (e.g. General Purpose (L/G), xCORE-USB, xCORE-Analog, xCORE-XA).
smiba
Member++
Posts: 18
Joined: Sat Nov 05, 2016 2:22 am

XHRA-2HPA-TQ64 - Not showing activity after SPI, also SPI_CLK @ 10Mhz?

Postby smiba » Mon Mar 20, 2017 2:20 am

Hey everyone,

I've been building my first prototype DAC with the XMOS-2HPA but I can't get it to work.
I've already written the right firmware to the SPI flash chip (S25FL116K) and confirmed it matched tbe .bin the xconfigurator made.

The chip has about 10-20ms of activity and then stops, SPI_CLK always keeps on running though.

Also whats the weirdest is that the SPI_CLK is running at 10Mhz right from the start, while I've noticed by reading threads its supposed to run at 2.5Mhz.
What could be causing this? May this be related?: https://www.xmos.com/download/private/D ... 1.0%29.pdf ?
My datecode is 1625 which should mean its produced with the updated OTP memory

Any idea's where to start looking?
View Solution
User avatar
mon2
XCore Expert
Posts: 657
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Mon Mar 20, 2017 2:58 am

The boot rom requires that the external SPI flash be in QSPI mode so you need to enable the QSPI non-volatile bit inside your SPI flash to allow for this compatibility. This programming has to be performed out of circuit using the standard SPI commands.

This is the QE bit # 6 of the STATUS REGISTER. If Bit # 6 = 1, then you are in QSPI mode.

If you have done this then do confirm that the binary image inside your flash device is properly formatted (ie. high / low byte ordering) and it is possible that your device is still related to the factory ROM issue:

viewtopic.php?f=26&t=4742


Image


Image


Image

Sounds like a factory ROM issue since the SPI clock is @ 10 Mhz (9.6 Mhz) upon power up. Do check that you are in QSPI mode which is still required once you have the SPI clock operational @ 2.4 Mhz.
smiba
Member++
Posts: 18
Joined: Sat Nov 05, 2016 2:22 am

Postby smiba » Mon Mar 20, 2017 8:49 am

On the S25FL116K the Quad enable is in SR2, Bit 1, I've set this to enabled and can confirm it does work.

Setting this option back to 0 makes the chip only have a few pules before dying right after

It might be possible the binary is wrong though, I'm unsure if I actually did the high/low byte orderning. How does one modify the firmware binary so it's right?


Thanks!

EDIT:

The source of the XHRA chips I have is digikey so it might actually be possible that it's the issue
smiba
Member++
Posts: 18
Joined: Sat Nov 05, 2016 2:22 am

Postby smiba » Mon Mar 20, 2017 11:02 am

Can anyone confirm that the QSCLK running at 9.6Mhz is not supposed to happen? As far as I can see its pretty much from the start and the clock also never stops. I keeps on running at 9.6Mhz for as long as the device is powered

Before I open up a chat with digikey
User avatar
mon2
XCore Expert
Posts: 657
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Mon Mar 20, 2017 12:21 pm

Here is a dump of the original flash sourced from the XMOS XRHA reference design:

https://axxonshare.s3.amazonaws.com/xrh ... backup.zip
** update ** -> corrected the URL for the download


Using standard SPI commands (slow process), you can clone the original XRHA flash device and then use the standard SPI command to enable the QSPI mode. After these steps, the XRHA CPU can use your external flash device.


The procedure we used to dump the original flash device is as follows:

Attached are multiple files which are named accordingly. The procedure was a time killer due to assorted issues and consumed all of Friday.

Took the StartKit and remove the SMD flash -> installed the IS25LQ016B flash -> created a custom def file as I was unable to get the default XFLASH definition for this IC to work. Using the enclosed definition, did manage to use with xTimecomposer and xflash with this custom file to erase / read / write in standard SPI mode (on the startkit).

First effort was to dump the entire flash as-is and the contents are attached. Then confirm the original is QE enabled = it is - read SR (05h command = 40h respond = QE enabled).

Then removed this SMD part and installed a fresh (non QE enabled part) -> wrote this content / image as-is -> then wrote to SR to enable QE bit. Each R/W of the flash = 8 minutes since we are writing the full amount (start to finish).


Quickly review this thread on this subject:

http://www.xcore.com/viewtopic.php?f=7& ... spi#p25628
* see page 5 for the end results
* the exact XRHA flash dump is posted in the first URL

Can anyone confirm that the QSCLK running at 9.6Mhz is not supposed to happen?


The linked document from XMOS states that the 9.6Mhz SPI clock indicates the ROM code inside the XMOS CPU is the wrong version. So does the long referenced thread.
smiba
Member++
Posts: 18
Joined: Sat Nov 05, 2016 2:22 am

Postby smiba » Mon Mar 20, 2017 5:32 pm

I've flashed xhra_dump_original_flash.bin to the SPI flash and it still gives me the same issues

After checking, my QSPI_CLK is at a much higher speed then 9.6Mhz it seems, although this might just be my cheap digital oscilloscope acting up. I don't remember it being like this yesterday, but I'm sure today it shows this behaviour with both firmwares
What does this behaviour tell us about the chip? The QSPI_CLK signal dies almost instantly if I do not connect the SPI flash chip, but keeps on pulsing for ever with the flash connected.

Image
smiba
Member++
Posts: 18
Joined: Sat Nov 05, 2016 2:22 am

Postby smiba » Mon Mar 20, 2017 9:07 pm

Well its not a defective chip!

By putting a long (unconnected) probe or wire on my SPI_CLK test point it works and gets detected over USB, however if I do not cover the SPI_CLK test point with a long wire it will keep on sending out SPI_CLK and never finished

What does this mean? Shielding issue? Have I made a mistake by adding a probe point for a high speed signal?

EDIT: Problem solved!! By removing the wires that I soldered onto the SPI part of the debug header. It seems these wires are horrible isolated and bring in noise. Its working now!
User avatar
mon2
XCore Expert
Posts: 657
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Tue Mar 21, 2017 12:22 pm

According to the advisory from XMOS and the referenced post from Matthew (who works for XMOS), you have the wrong firmware inside the OTP of the XMOS CPU.

The firmware may be ok for your initial testing but not reliable for production / future flash upgrades, etc. as the QSPI clock keeps running @ 9.6 Mhz regardless of the #CS line state.

A proper OTP inside the XMOS CPU will clock QSPI clock @ 2.4 Mhz and will output this clock and then halt if no valid external QSPI flash is found. As you noted, the QSPI clock keeps running, non-stop @ 9.6 Mhz (10 Mhz) which is indicative of the older OTP code.

Apparently there is a second "R" in the markings located on the bottom right of the CPU to denote the fixed firmware code. If you have additional chips then you should consider to get them swapped out. It sounds like you may have random boot success using the wrong OTP code. Also, in our opinion, your success may very well be related to the vendor you have chosen for the QSPI flash. In the past, we invested a great deal of time studying assorted QSPI flash vendors and found that Spansion (now Cypress) was much better behaved than Winbond. The pin drive strength on Spansion (Cypress) was much better to drive the longer logic analyzer cables used for the DUT as compared to Winbond. Winbond (Taiwan) then sent us new devices which featured registers to program using standard SPI commands, the pin strength to match the Spansion parts.

The QSPI mode was developed to allow for high speed clocking but care must be applied by the QSPI master (XMOS CPU) to properly align with the #CS and QSPI CLOCK edges. That is the root concern of your working XMOS CPU.

If you review the Spansion QSPI flash datasheet, note the timing diagrams which show that:

1) first the #CS line is brought LOW while SCK is HIGH
2) then the SCK is clocked while #CS line is kept LOW

the wrong OTP keeps SCK clocking regardless of the #CS line state and this can throw off the QPSI communication with the XMOS CPU. Suspecting that Digikey technical services is now clear on which XMOS CPU contains the corrected code.
smiba
Member++
Posts: 18
Joined: Sat Nov 05, 2016 2:22 am

Postby smiba » Thu Mar 23, 2017 4:11 pm

Thanks, i will try to get the other few chips from this wafer that I have back and replace them with fixed ones before I leave the prototyping stage

Thanks again for your help!

Return to “Processors”

Who is online

Users browsing this forum: No registered users and 6 guests