Hi,
We are developping a board that uses the XHRA-2HPA-TQ64-C-2HPA-TQ64-C (rather new version from 2016).
24 MHz clk is delivered to XHRA from the Si5351A-B04486-GT (exactly the same way as on the xCORE-AUDIO HiRes-2 DAC/HPA Reference Platform) and the QSPI IS25LQ016B is used for booting.
Powering sequence is OK. QSPI is programmed (QE enabled) with the binary that we created based on the XMOS example. All events were cleared and we only toogle the LED in the init event.
We removed all I2C programming of the timer and DAC to be sure that this does not make any problems.
We are watching EN#,SCK, and ID0 signals of the QSPI flash on the scope to see how they behave after the power up.
We can see that after CE# goes LOW the SCK is output from XHRA to the QSPI flash. The initial frequency of the SCK signal is 10 MHz and the command appears on the ID0. This command is EBh.
Seems to be OK but the boot process does not terminate. The CE# line never returns to HIGH and the booting seems to go into never ending loop. Of course the LED does not toggle.
To find out the problem we used the xCORE-AUDIO HiRes-2 DAC/HPA Reference Platform to compare its boot process.
We removed the original XHRA-2HPA-TQ64-C from the EVB and soldered the new XHRA-2HPA-TQ64-C that we purchsed for our project to have the same firmware.
This is exactly the same revision as we have on our board.
After the power up of the EVB we can see that the SCK signal on the QSPI is now 2,5 MHz. (it then changes to some higher value). The starting command on the ID0 is also EBh.
EVB terminates the boot process successfuly and everything works fine.
What makes these two XHRA-2HPA-TQ64-C generate SCK signal with different frequencies ?
Why does QSPI boot fails?
Seems that this is caused by different firmware on XHRA-2HPA-TQ64-C but as I have mentioned they have exactly the same version printed on them.
Wlodek
XHRA QSPI flash booting problem
-
wlodek
- Member++
- Posts: 22
- Joined: Fri Jul 22, 2016 3:19 pm
-
mon2
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
Hi Wlodek. Some ideas to check...
How does your QSPI device behave on the XMOS EVB ? Does your programmed QSPI device allow the XMOS EVB to toggle the LED port pin ok ?
Perhaps consider to review the contents (formatting) of your new QSPI device to validate that the LED toggle works ok. We recall a post on this user forum that QSPI must be enabled on the memory device (which you have done) to permit the boot code inside this XMOS processor to operate correctly.
The SPI flash ID extraction is standard SPI format and then the QSPI format is required for the boot.
Our focus would be on reviewing the already working QSPI flash memory device from the XMOS EVB.
Kumar
update...
Now recalling the not so much fun we faced while reviewing QSPI for another project with XMOS IP.
Do you see further activity on ID0..ID3 after the EBh command is sent ? The SPI master (XMOS) is required to transmit the 3 byte address of the flash memory after this EBh command in quad spi mode (over clock cycle 8..15 as per the ISSI datasheet Figure 8.7.1).
If not, do you see the similar activity on the working XMOS EVB QSPI device ? Logically you will since it is working.
On your PCB layout, how far / close is the QSPI device ? We recall that long traces (originally used some unshielded logic analyzer probes which impacted our review) will cause some issues. Also remember that specific QSPI vendors (Spansion was great on assorted testing) have a higher pin drive than others (Winbond was not so great till they forwarded to us a new version of their chip which features a register to alter the pin strength which was very interesting to learn).
What is the brand of the QSPI device found on the XMOS EVB ? Can you source the same to only rule out the vendor debate ?
How does your QSPI device behave on the XMOS EVB ? Does your programmed QSPI device allow the XMOS EVB to toggle the LED port pin ok ?
Perhaps consider to review the contents (formatting) of your new QSPI device to validate that the LED toggle works ok. We recall a post on this user forum that QSPI must be enabled on the memory device (which you have done) to permit the boot code inside this XMOS processor to operate correctly.
The SPI flash ID extraction is standard SPI format and then the QSPI format is required for the boot.
Our focus would be on reviewing the already working QSPI flash memory device from the XMOS EVB.
Kumar
update...
Now recalling the not so much fun we faced while reviewing QSPI for another project with XMOS IP.
Do you see further activity on ID0..ID3 after the EBh command is sent ? The SPI master (XMOS) is required to transmit the 3 byte address of the flash memory after this EBh command in quad spi mode (over clock cycle 8..15 as per the ISSI datasheet Figure 8.7.1).
If not, do you see the similar activity on the working XMOS EVB QSPI device ? Logically you will since it is working.
On your PCB layout, how far / close is the QSPI device ? We recall that long traces (originally used some unshielded logic analyzer probes which impacted our review) will cause some issues. Also remember that specific QSPI vendors (Spansion was great on assorted testing) have a higher pin drive than others (Winbond was not so great till they forwarded to us a new version of their chip which features a register to alter the pin strength which was very interesting to learn).
What is the brand of the QSPI device found on the XMOS EVB ? Can you source the same to only rule out the vendor debate ?
-
wlodek
- Member++
- Posts: 22
- Joined: Fri Jul 22, 2016 3:19 pm
Hi Kumar,
I will check how my QSPI flash behaves on the EVB on Monday. I already checked that the QSPI from the EVB does not work on my board. With the original EVB QSPI flash on my board I tried to observe any activity on the I2C bus that is used to program the Si5351A-B04486-GT timer in the INIT event. I2C did not show any activity so it made me think that XHRA does not execute the INIT event code.
As for the activity on ID1..ID3 lines, yes I coud see the activity on these lines but I did not analyze them in details.
What makes me quite confused is that the SCK frequency is different at the start of the boot process on EVB (2,5 MHz) and our board (10MHz). The input clock to XHRA is the same (24 MHz). This all happens before any data from QSPI is accessed. Even if QSPI flashes are different (and maybe wrong on my board) the XHRA does not know about it when it starts output the SCK signal.
Is there a way to compare the firmware on two XHRAs ? Seems there must be a difference even if the version numbers on them are the same.
We are using QSPI IS25LQ016B on both EVB (we made a copy of orignal QSPI that was on the EVB - also QSPI IS25LQ016B , programmed it to a new chip and soldered the newly purchased QSPI back to EVB - it worked fine).
We now have some mess on our board PCB. Originally we had a transil between the QSPI and XHRA but we removed it (as we were not sure that this could be the source of the problem) and now we have 1 cm wires. QSPI is close to XHRA.
Wlodek
I will check how my QSPI flash behaves on the EVB on Monday. I already checked that the QSPI from the EVB does not work on my board. With the original EVB QSPI flash on my board I tried to observe any activity on the I2C bus that is used to program the Si5351A-B04486-GT timer in the INIT event. I2C did not show any activity so it made me think that XHRA does not execute the INIT event code.
As for the activity on ID1..ID3 lines, yes I coud see the activity on these lines but I did not analyze them in details.
What makes me quite confused is that the SCK frequency is different at the start of the boot process on EVB (2,5 MHz) and our board (10MHz). The input clock to XHRA is the same (24 MHz). This all happens before any data from QSPI is accessed. Even if QSPI flashes are different (and maybe wrong on my board) the XHRA does not know about it when it starts output the SCK signal.
Is there a way to compare the firmware on two XHRAs ? Seems there must be a difference even if the version numbers on them are the same.
We are using QSPI IS25LQ016B on both EVB (we made a copy of orignal QSPI that was on the EVB - also QSPI IS25LQ016B , programmed it to a new chip and soldered the newly purchased QSPI back to EVB - it worked fine).
We now have some mess on our board PCB. Originally we had a transil between the QSPI and XHRA but we removed it (as we were not sure that this could be the source of the problem) and now we have 1 cm wires. QSPI is close to XHRA.
Wlodek
-
mon2
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
Hi Wlodek. Thanks for the details. We know the Si5351A quite well now and have a number of pending designs based on this amazing PLL. Just fighting our local distributors on the premium being demanded for the factory programmed version of the same part. Still in negotiations.
Please share the details on which clocks are being fed into the XMOS processor. Is it only the CLK output from this Si5351A device ? If yes, how are your generating the 24 Mhz clock out from this PLL ? For us, we used an external low cost micro (EFM8 by SiLabs and FPGA on a few other designs). Or did you get this part factory programmed to generate 24 Mhz upon power up ?
What is the ref crystal on this Si5351A PLL ? The crystal must be 25 Mhz or 27 Mhz.
Since you can take a fresh XMOS CPU and solder onto the EVB and the new micro continues to operate correctly with the SPI clock @ 2.5 Mhz, then there must be some other related issue. Do not believe the firmware inside the XMOS boot rom is the root cause of the clock difference.
If you are comfortable, share a portion of your schematic. Fearing that you do not have a clock on power up and Si5351A is the sole clock which requires to be initialized via I2C to start generating a valid clock for the XMOS device. Please correct us if wrong here...
The 1 cm wires on the QSPI are fine as we had 6" or so length wires (unshielded) and longer but shielded when tracing our XMOS code with a QSPI bus analyzer module.
Please verify the clock being fed into your XMOS PCB design. Not intimate with the specific XMOS CPU but does it also feature some PLL clock setting for the XMOS CPU ? (ie. if 24 Mhz clock in then PLL strapping must be xxx on some pins, etc.). Do check the same.
As an idea, consider to hard wire the clock that is working from the XMOS EVB onto your PCB to see if that allows for the expected 2.5 Mhz SPI clock.
Kumar
Please share the details on which clocks are being fed into the XMOS processor. Is it only the CLK output from this Si5351A device ? If yes, how are your generating the 24 Mhz clock out from this PLL ? For us, we used an external low cost micro (EFM8 by SiLabs and FPGA on a few other designs). Or did you get this part factory programmed to generate 24 Mhz upon power up ?
What is the ref crystal on this Si5351A PLL ? The crystal must be 25 Mhz or 27 Mhz.
Since you can take a fresh XMOS CPU and solder onto the EVB and the new micro continues to operate correctly with the SPI clock @ 2.5 Mhz, then there must be some other related issue. Do not believe the firmware inside the XMOS boot rom is the root cause of the clock difference.
If you are comfortable, share a portion of your schematic. Fearing that you do not have a clock on power up and Si5351A is the sole clock which requires to be initialized via I2C to start generating a valid clock for the XMOS device. Please correct us if wrong here...
The 1 cm wires on the QSPI are fine as we had 6" or so length wires (unshielded) and longer but shielded when tracing our XMOS code with a QSPI bus analyzer module.
Please verify the clock being fed into your XMOS PCB design. Not intimate with the specific XMOS CPU but does it also feature some PLL clock setting for the XMOS CPU ? (ie. if 24 Mhz clock in then PLL strapping must be xxx on some pins, etc.). Do check the same.
As an idea, consider to hard wire the clock that is working from the XMOS EVB onto your PCB to see if that allows for the expected 2.5 Mhz SPI clock.
Kumar
-
wlodek
- Member++
- Posts: 22
- Joined: Fri Jul 22, 2016 3:19 pm
Hi Kumar,
We are using Si5351 with factory preprogrammed 24 MHz on the SCK 1. The crystal is 25 MHz (I will check timings again on Monday as I am not sure of anything any more).
I will keep informing you on our progress.
Wlodek
We are using Si5351 with factory preprogrammed 24 MHz on the SCK 1. The crystal is 25 MHz (I will check timings again on Monday as I am not sure of anything any more).
I will keep informing you on our progress.
Wlodek
-
henk
- Respected Member
- Posts: 347
- Joined: Wed Jan 27, 2016 5:21 pm
Hi Wlodek,
The XHRA-2HPA-TQ64-C part boots from OTP - so it will run the flash clock at a different speed from the ordinary XS2 devices. From memory, 2.5 MHz is the default boot speed, but I guess that the OTP boot runs it faster.
I think it should have a 24 MHz oscillator.
What does the PCB design look like; in particular, the clock between the XHRA device and the flash, and the decoupling around the XHRA device?
Cheers,
Henk
The XHRA-2HPA-TQ64-C part boots from OTP - so it will run the flash clock at a different speed from the ordinary XS2 devices. From memory, 2.5 MHz is the default boot speed, but I guess that the OTP boot runs it faster.
I think it should have a 24 MHz oscillator.
What does the PCB design look like; in particular, the clock between the XHRA device and the flash, and the decoupling around the XHRA device?
Cheers,
Henk
-
wlodek
- Member++
- Posts: 22
- Joined: Fri Jul 22, 2016 3:19 pm
Hi Henk,
I will do some measurements tomorrow.
From my memory:
The clock between Si5351A PLL and XHRA is 24 MHz on both EVB and my board.
The clock between XHRA and flash is 2,5 MHz on the EVB and 10 MHz on my board (this is the starting frequency and it seems to be higher in latter boot proces).
(again I do not understand where is this difference from ).
I will share PCB details tomorrow. Traces from flash to XHRA are short (+/- 1 cm).
Wlodek
I will do some measurements tomorrow.
From my memory:
The clock between Si5351A PLL and XHRA is 24 MHz on both EVB and my board.
The clock between XHRA and flash is 2,5 MHz on the EVB and 10 MHz on my board (this is the starting frequency and it seems to be higher in latter boot proces).
(again I do not understand where is this difference from ).
I will share PCB details tomorrow. Traces from flash to XHRA are short (+/- 1 cm).
Wlodek
-
henk
- Respected Member
- Posts: 347
- Joined: Wed Jan 27, 2016 5:21 pm
Short traces are good - just check that there isn't a stub on the QSPI-CLK trace to a test-point or something like that.
2.5 vs 10 MHz - that is puzzling.
Can you describe the precise configuration(s) please? As far as I can tell you have
- two XHRA devices; one from the reference design, and one that you bought for your design.
- two flashes; one from the reference design, and one that you programmed for your design.
- two PCBs; the reference one, and the one that you made.
Just explain which combination gave which initial and latter clock frequencies.
Also - what straps (if any) did you put on pins X0D04..X0D07?
Cheers,
Henk
2.5 vs 10 MHz - that is puzzling.
Can you describe the precise configuration(s) please? As far as I can tell you have
- two XHRA devices; one from the reference design, and one that you bought for your design.
- two flashes; one from the reference design, and one that you programmed for your design.
- two PCBs; the reference one, and the one that you made.
Just explain which combination gave which initial and latter clock frequencies.
Also - what straps (if any) did you put on pins X0D04..X0D07?
Cheers,
Henk
-
wlodek
- Member++
- Posts: 22
- Joined: Fri Jul 22, 2016 3:19 pm
Hi Henk,
- I have two XHRA devices. Both were bought for our design. On the refference board, we have removed the original XHRA and soldered one of our XHRA (just to be sure we are using the same revision of XHRA on the refference and our board).
- I have two flashes. Both bough for our design. Again, we have copied the contents of original flash on the refference board and made two exacly the same copies into our flashes. Then we removed the flash from the the reference board and soldered in our copy. It worked fine. The second flash we put on our board. We expected some problems as we are using slightly different DAC on our board (it is also 2 channel SABRE DAC but without the headphone amplifier).
It did not work on our board so we reprogrammed the flash so that it does not anything in configutration events but flashes the LED. This also did not work.
- We have two boards: one from reference board with XMOS (where we put our XHRA and QSPI flash) and second board that was designed for our purpose..
- 2.5 MHz SCK is output from XHRA (our) on the reference board (and it works fine).
- 10 MHz SCK is output from XHRA (also our) on our board. Our board does not boot properly. It just tries to reboot in never ending loop. I can see it always starts with the EBh command on the ID0 QSPI flash (the some additional activity can be seen on IDx lines) and XHRA does not return the CE# signal to high.
We do not use straps - we wanted to use configuration from QSPI flash
Wlodek
- I have two XHRA devices. Both were bought for our design. On the refference board, we have removed the original XHRA and soldered one of our XHRA (just to be sure we are using the same revision of XHRA on the refference and our board).
- I have two flashes. Both bough for our design. Again, we have copied the contents of original flash on the refference board and made two exacly the same copies into our flashes. Then we removed the flash from the the reference board and soldered in our copy. It worked fine. The second flash we put on our board. We expected some problems as we are using slightly different DAC on our board (it is also 2 channel SABRE DAC but without the headphone amplifier).
It did not work on our board so we reprogrammed the flash so that it does not anything in configutration events but flashes the LED. This also did not work.
- We have two boards: one from reference board with XMOS (where we put our XHRA and QSPI flash) and second board that was designed for our purpose..
- 2.5 MHz SCK is output from XHRA (our) on the reference board (and it works fine).
- 10 MHz SCK is output from XHRA (also our) on our board. Our board does not boot properly. It just tries to reboot in never ending loop. I can see it always starts with the EBh command on the ID0 QSPI flash (the some additional activity can be seen on IDx lines) and XHRA does not return the CE# signal to high.
We do not use straps - we wanted to use configuration from QSPI flash
Wlodek
-
henk
- Respected Member
- Posts: 347
- Joined: Wed Jan 27, 2016 5:21 pm
Hi wlodek,
Just to recap, you use two XHRA devices.
- One works on the reference board with the reference Flash
- One does not work on your board with your flash
- You observe a different start frequency of 10 MHz (your board), vs 2.5 MHz (reference board).
You say they both start with the 0xEB command on flash as a SPI command; which is fast read; it is the only command that is issued.
There are two things that may affect the start frequency: the input oscillator; and the reset sequence. A third option is that you observe the clock at different times.
- Your board would need a 96 MHz input clock for the clock to be 4x - it would not work, but worth checking the input clock, levels, and PLL_AVDD filter
- you say the reset sequence is correct
- which leaves the option that you observe the clock at different times; e.g, the first read command on one, and a later one on the other? Can you see what data came back from the QSPI command on both reads?
A final question - you did set the 'Quad mode' bit in the flash status register?
Cheers,
Henk
Just to recap, you use two XHRA devices.
- One works on the reference board with the reference Flash
- One does not work on your board with your flash
- You observe a different start frequency of 10 MHz (your board), vs 2.5 MHz (reference board).
You say they both start with the 0xEB command on flash as a SPI command; which is fast read; it is the only command that is issued.
There are two things that may affect the start frequency: the input oscillator; and the reset sequence. A third option is that you observe the clock at different times.
- Your board would need a 96 MHz input clock for the clock to be 4x - it would not work, but worth checking the input clock, levels, and PLL_AVDD filter
- you say the reset sequence is correct
- which leaves the option that you observe the clock at different times; e.g, the first read command on one, and a later one on the other? Can you see what data came back from the QSPI command on both reads?
A final question - you did set the 'Quad mode' bit in the flash status register?
Cheers,
Henk