Or order another fresh XHRA device from Digikey or similar. Order the SPANSION device as well for some testing. Leave the working XMOS EVB as-is.
Maybe nothing is wrong with the 10 Mhz QSPI clock but if the flash does not respond at this speed then could be causing the lock up ? Will be nice to see your PCB perform the LED blink as expected with your custom code.
===========
It appears there is a metal belly under the XHRA device. Are you ok to remove such a device ? That is a risky procedure to remove such a device. You have a hot plate and related tools for this removal ?
===========
Forgot to ask earlier - how did you QUAD ENABLE your flash device ? This is a non-volatile setting inside the flash device. From our understanding, you are required to configure the flash device, out of circuit, with the QE bit setting -> then solder onto your XHRA PCB. You could perform this with a standard SPI capable programmer.
XHRA QSPI flash booting problem
-
mon2
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
-
fazee
- New User
- Posts: 3
- Joined: Thu Jul 28, 2016 3:52 pm
Hi All,
I'm Chris and I'm working with Wlodek on this project.
Of course we act together on it in our Company, but I think I should join this discussion at forum.
Reading all posts I have noticed tha some questions have been repeated, so please let me summarize the problem...
We have two boards:
- original XMOS EVB - let's call it EVB,
- our Bellsbox project PCB, let's call it BB
Chips onboard:
EVB:
XMOS: XHRA-2HPA-TQ64-C from 2016 prod. line
PLL: Si5351A-B04486-GT
FLASH: ISSI IS25LQ016B
SUPERVISORY: ADM1085AKSZ + STM1061N28WX6F SOT-23-3
BB:
XMOS: XHRA-2HPA-TQ64-C from 2016 prod. line
PLL: Si5351A-B04486-GT
FLASH: ISSI IS25LQ016B
SUPERVISORY: ADM1085AKSZ + STM1061N28WX6F SOT-23-3 (of course we changed wrong pinouts)
all above means : HARDWARE THE SAME.
all voltages checked - values EVB-BB the same, ripples EVB-BB the same
all rest pinouts on BB PCB checked - all right
supervisory timing checked - EVB-BB the same
Flash with copied firmware from EVB flash - mounted on EVB - works fine - means programmed OK (we use ELNEC SmartProg2 programmer - declared on ISSI compatibility list).
The same flash mounted on BB does not work.
Let us look at problem in slowmo...
after RESET XMOS set flash SPI CE an generates SPI CLOCK:
EVB: 2,4 MHz BB: 10 MHz
We do not know what XMOS do between reset and setting SPI CE. I am sure it executing internal fimware instructions - maybe sets internal PLL divisors etc.
Even SPI CLOCK is wrong - serial out instructions should be OK, but Flash response in 4x faster clock may be not recognizable by XMOS and program loops - as we observe.
Differences in firmware in XMOS inside... I DO NOT WANT TO BELIEVE (in contrast to Fox Mulder :) ). When I was a young (and beautiful :) ) I had student practice in one of electronic companies - in 1984 - at SANYO's low noise transistors production line. I remember the fact that I had to physically remove signs of beta factor (A,B,C) on transistor bodies - if they did not pass secondary test of amplification factor. Of course - before they leave factory gates...
Hmm...
Thank You all for step-by-step analyzis - it is normal research process - but the longer I wonder on reasons of our defeat I think that XMOS was treated by ESD which partially destroyed fragment of its inside structure - let us say PLL area ?
We have technological line for replacing chips with exposed pad - but it is final and risky decision. We should be sure that XMOS is damaged - we have another XMOS chips but have no additional PCB boards :)
Chris
I'm Chris and I'm working with Wlodek on this project.
Of course we act together on it in our Company, but I think I should join this discussion at forum.
Reading all posts I have noticed tha some questions have been repeated, so please let me summarize the problem...
We have two boards:
- original XMOS EVB - let's call it EVB,
- our Bellsbox project PCB, let's call it BB
Chips onboard:
EVB:
XMOS: XHRA-2HPA-TQ64-C from 2016 prod. line
PLL: Si5351A-B04486-GT
FLASH: ISSI IS25LQ016B
SUPERVISORY: ADM1085AKSZ + STM1061N28WX6F SOT-23-3
BB:
XMOS: XHRA-2HPA-TQ64-C from 2016 prod. line
PLL: Si5351A-B04486-GT
FLASH: ISSI IS25LQ016B
SUPERVISORY: ADM1085AKSZ + STM1061N28WX6F SOT-23-3 (of course we changed wrong pinouts)
all above means : HARDWARE THE SAME.
all voltages checked - values EVB-BB the same, ripples EVB-BB the same
all rest pinouts on BB PCB checked - all right
supervisory timing checked - EVB-BB the same
Flash with copied firmware from EVB flash - mounted on EVB - works fine - means programmed OK (we use ELNEC SmartProg2 programmer - declared on ISSI compatibility list).
The same flash mounted on BB does not work.
Let us look at problem in slowmo...
after RESET XMOS set flash SPI CE an generates SPI CLOCK:
EVB: 2,4 MHz BB: 10 MHz
We do not know what XMOS do between reset and setting SPI CE. I am sure it executing internal fimware instructions - maybe sets internal PLL divisors etc.
Even SPI CLOCK is wrong - serial out instructions should be OK, but Flash response in 4x faster clock may be not recognizable by XMOS and program loops - as we observe.
Differences in firmware in XMOS inside... I DO NOT WANT TO BELIEVE (in contrast to Fox Mulder :) ). When I was a young (and beautiful :) ) I had student practice in one of electronic companies - in 1984 - at SANYO's low noise transistors production line. I remember the fact that I had to physically remove signs of beta factor (A,B,C) on transistor bodies - if they did not pass secondary test of amplification factor. Of course - before they leave factory gates...
Hmm...
Thank You all for step-by-step analyzis - it is normal research process - but the longer I wonder on reasons of our defeat I think that XMOS was treated by ESD which partially destroyed fragment of its inside structure - let us say PLL area ?
We have technological line for replacing chips with exposed pad - but it is final and risky decision. We should be sure that XMOS is damaged - we have another XMOS chips but have no additional PCB boards :)
Chris
-
lchenier
- Member
- Posts: 10
- Joined: Mon Apr 11, 2016 8:38 pm
I'm having the same problem as you guys.
Got lot of trouble getting our rev A board because of programming issue (using an external programming tool - Segger Aardvark - was very useful) so I was hoping that my rev B board was going to be easy...
So after doing the usual checks (visual inspection of solder, voltages, timing, clocks, SPI FLASH programming) I came to the conclusion that it was the XMOS chip that was the culprit.
ESD issues are only happening once in a blue moon. Long traces or stubs as mentioned in previous posts may be an issue but as long as the waveforms looks good and that there's enough margin, these should not cause any problem.
The problem is actually with the XMOS chip.
My working rev A board was having a XMOS chip labeled:
HPA20C
GT152301
P32W22.0
My non-working rev B board:
HPA20C
GT161701
PA4M20.00
Luckily, I was having some old chips left in our lab. Swapping the chip on my rev B board to the older type is allowing the external code to load properly and be recognized by the PC :-)
The code is loading 4 times faster (i.e. 2.4 vs 9.6 MHz) and the loading starts right away after the reset is released (as opposed to ~335 us of GT152301 chip) so obviously the firmware inside the XMOS chip IS different.
It is scary that a change like this is happening without having any changes in the documentation and no warning. Good thing that this is not happening (for me anyway) on a production run of hundreds or thousands of units!
I now suspect that we need to have different s/w in the external SPI FLASH? Can a developer at XMOS advice?
Louis
Got lot of trouble getting our rev A board because of programming issue (using an external programming tool - Segger Aardvark - was very useful) so I was hoping that my rev B board was going to be easy...
So after doing the usual checks (visual inspection of solder, voltages, timing, clocks, SPI FLASH programming) I came to the conclusion that it was the XMOS chip that was the culprit.
ESD issues are only happening once in a blue moon. Long traces or stubs as mentioned in previous posts may be an issue but as long as the waveforms looks good and that there's enough margin, these should not cause any problem.
The problem is actually with the XMOS chip.
My working rev A board was having a XMOS chip labeled:
HPA20C
GT152301
P32W22.0
My non-working rev B board:
HPA20C
GT161701
PA4M20.00
Luckily, I was having some old chips left in our lab. Swapping the chip on my rev B board to the older type is allowing the external code to load properly and be recognized by the PC :-)
The code is loading 4 times faster (i.e. 2.4 vs 9.6 MHz) and the loading starts right away after the reset is released (as opposed to ~335 us of GT152301 chip) so obviously the firmware inside the XMOS chip IS different.
It is scary that a change like this is happening without having any changes in the documentation and no warning. Good thing that this is not happening (for me anyway) on a production run of hundreds or thousands of units!
I now suspect that we need to have different s/w in the external SPI FLASH? Can a developer at XMOS advice?
Louis
-
mon2
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
Thank you Louis for chiming in (you fellow Canadian you :). Your details help.
Please confirm that your flash device is operating correctly in QSPI mode using the higher (x4 = 9.6 MHZ) clock. If yes, please share the brand name and model of the working flash device.
Is the root cause the new firmware inside the XHRA which is clocking the flash @ 9.6 Mhz ?
Please confirm that your flash device is operating correctly in QSPI mode using the higher (x4 = 9.6 MHZ) clock. If yes, please share the brand name and model of the working flash device.
Is the root cause the new firmware inside the XHRA which is clocking the flash @ 9.6 Mhz ?
-
lchenier
- Member
- Posts: 10
- Joined: Mon Apr 11, 2016 8:38 pm
Using a Spansion S25FL164K0XMFI011 SPI FLASH.
On boot-up, the host micro is doing a memory verify and if not the same, does a programming, another verify, then sets the chip in Quad mode, tri-states the lines going to the SPI FLASH and releases the reset line.
Identical host micro code is running on my rev A and rev B boards so I am positive that this has nothing to do with the host micro.
Louis
On boot-up, the host micro is doing a memory verify and if not the same, does a programming, another verify, then sets the chip in Quad mode, tri-states the lines going to the SPI FLASH and releases the reset line.
Identical host micro code is running on my rev A and rev B boards so I am positive that this has nothing to do with the host micro.
Louis
-
mon2
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
-
lchenier
- Member
- Posts: 10
- Joined: Mon Apr 11, 2016 8:38 pm
Great...
Good thing I only have 10 chips to replace...
Louis
Good thing I only have 10 chips to replace...
Louis
-
lchenier
- Member
- Posts: 10
- Joined: Mon Apr 11, 2016 8:38 pm
Also interesting to note that my chips are 1617 which is later than 1610...
-
mon2
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
Louis - have you tested the use of assorted vendors and types of flash devices to see if there can be a work around ?
Please clarify that your 1617 datecode firmware operates @ 9.6 Mhz for the QSPI clock. Also, this 9.6 Mhz QSPI flash fails to operate. Is this accurate ?
For us (we do not use this XHRA device but did review the QSPI firmware a while ago) - we found Spansion to be great and Spansion worked where Winbond failed. We reported our findings to Winbond who noted the raised issue was related to pin strength / drive and they now offer devices where such values can be altered. Perhaps source a mix of such compatible flash devices from Digikey to check if there can be a solution using the existing firmware ?
Please clarify that your 1617 datecode firmware operates @ 9.6 Mhz for the QSPI clock. Also, this 9.6 Mhz QSPI flash fails to operate. Is this accurate ?
For us (we do not use this XHRA device but did review the QSPI firmware a while ago) - we found Spansion to be great and Spansion worked where Winbond failed. We reported our findings to Winbond who noted the raised issue was related to pin strength / drive and they now offer devices where such values can be altered. Perhaps source a mix of such compatible flash devices from Digikey to check if there can be a solution using the existing firmware ?
-
lchenier
- Member
- Posts: 10
- Joined: Mon Apr 11, 2016 8:38 pm
Only tried the Spansion part. I knew that the Winbond parts were having some issues from reading some of the forum posts, so I stayed away from them.
Not really interested with a work-around - the chip needs to be working properly! Work around is just a recipe for trouble when supply or temperature fluctuate.
The 1617 chip clocks the SPI FLASH at 9.6MHz and the clock never stops.
Is the latest version of the chip runs at 2.4 or 9.6 MHz? Can you find out for sure which date code works properly because it is obviously still a problem after 1610.
Louis
Not really interested with a work-around - the chip needs to be working properly! Work around is just a recipe for trouble when supply or temperature fluctuate.
The 1617 chip clocks the SPI FLASH at 9.6MHz and the clock never stops.
Is the latest version of the chip runs at 2.4 or 9.6 MHz? Can you find out for sure which date code works properly because it is obviously still a problem after 1610.
Louis