XHRA-2HPA Flash communication problems

[Decourcf]

Hi all,

I am currently working on an audio board integrating a XHRA-2HPA chip with a IS25LQ016B flash memory.

I checked several mandatory parameters according to the datasheet :
- Powering up sequence
- Quad SPI enabling
- Load firmware found on this page : https://www.xmos.com/support/boards?product=18340
- No configuration/straps = default values used

1) But there are some points related to the configuration I don't understand. It is written that the configuration has to be written at the 0x800000 address but what about the file produced with the xMOS configurator tool? Has it to be loaded as a 'standard firmware' or as a configuration file?

2) It is also written that it has to be loaded in memory with less significant nibble first, I then load the first nibble at the first address, am I correct? Or should it be loaded at the last address? For precisions I use a python script on a raspberry pi in order to load the firmware into the memory.

3) Is there an easy way to check if the xMOS is awake/communication with the flash memory?

Sorry if some of my questions seem irrelevant but it is the first xMOS chip I am using.

Regards

François

[henk]

Hi François,

A good test is to just load the firmware - not any configuration information. That will just use all default settings.

* Erase the flash, and store the firmware from address 0 onwards.

* Byte 0 goes at address 0 of the flash; byte N at address N.

Inside each byte, make sure that the LSN (least-significant-nibble) is stored first. Depending on how you write to QSPI, you may have to swap the nibbles of each byte of the firmware. Some programmers write the MSN (most significant nibble) first.

H

[Decourcf]

Hi Henk,

Thanks a lot for your answer. It seems that the RaspberryPi is only able to write MSB first, then that may be the issue.

Then if I understood correctly this mean I have to :
1) Take the bits by group of 4 (half byte)
2) Reverse the group (1100 --> 0011)
3) Write it in the flash

Am I right?

[henk]

Almost - Say the image has the following bytes:
0x12
0xA5
0xF3
...

Write the following bets:
0x21
0x5A
0x3F
...

Ie, swap the first and the last 4 bits.

[Decourcf]

Thanks a lot for your help, I tried that but still nothing.

I looked at the CS signal and it remains always HIGH as if the xMOS doesn't try to communicate with the SPI flash at all.

I you have any idea of what could be wrong, I am quite lost at the moment.

[henk]

Is this your own design around the XHRA-2HPA?

By the looks of it the chip doesn't boot - otherwise it would pull CS low to start reading flash.

It does get out of reset alright and has a sequenced power supply?

[Decourcf]

Thanks for your advices.

I used mainly the reference design with just few adjustement in order to use some components from my stock. But I checked the sequenced power up according to the datasheet and everything is ok.

I then solder a new board in case of defective components on the prototype one and now the xMOS does change the CS state to low. So there is improvement.

But still, it seems that the data on the rom is not recognized by the xMOS. I did follow your example though :

Originial file (beginning) : d370 0000 5337 0009 000a 0000 0000 8000
Data strored on ROM : 0x3D 0x07 0x00 0x00 0x35 0x73 0x00 0x90 0x00 0xA0 0x00 0x00 0x00 0x00 0x08

So it seems to be ok according to your previous post but the board is not recognized as a usb device by 'xMOS USB AUDIO 2.0 ST' when plugged to the computer.

Did I miss something in the process?

[henk]

Hi François,

That's progress. Does the chip-select return to high?

* I am slightly concerned that the data is formatted as 16-bit shorts; as I am not sure how they have been assembled in shorts. The may have been assembled first byte MSB second byte LSB, or the other way around... One of them will cause all even and odd bytes to be swapped. A probe on Q3 should be low-high-low-low-low-low-low-low, whilst Q2 should start low-high-low-high-low-low-low-low.

* You did set the QUAD-mode bit in the flash?

It would be good to understand why the other board failed - you may have had a faulty component, it may have been a short/dry joint, or it may be a design marginality that is going to bite you a few milliseconds later on the second board.

Just checking - you have soldered the exposed paddle to ground have you?

Cheers,
Henk

[Decourcf]

Hi Hank,

Sorry for my late answer I had not a lot of time to work on it these last day, but should be focus on it next week.

About the chip select yes it goes low then high (as shown on the picture)

For Q3 and Q1 they just briefly reach high then go down and don't switch state anymore. So maybe your are right about the data which is not well formatted. Then what kind of programmer should I use? Currently I am just using a raspberry Pi with a python script that I wrote.

Yes I did set the Quad-mode bit in the flash. And same for the exposed paddle I did soldered it.

For troubleshooting the other board I had some problems during soldering and had to heat the board a lot in order to solder the pad. Maybe that's why.

Again thanks for your help
Francois

[henk]

Q3 should be up and down 50% of the time.

If it is not, there could be a few reasons:
- Maybe flash is programmed with zeroes
- Maybe the quad bit is somehow not set (in which case Q3 defaults to HOLD)
- Maybe the length is programmed incorrectly (in which case it may stop reading too early)

It would be good to get a trace with a few clocks, chip select, and Q3 - maybe 10-20 cycles or so. Hold that against the SPEC, and you should be able to see what it is reading on Q3 and check that against the image.

I suggest to read the QSPI flash out again - using the programmer; in Quad mode. See what comes out.