Problem at first load with JTAG

[norman]

Hello everybody,

back to the board with the new 50Mhz oscillator instead of the 25Mhz in order to match the MODE0-1 pins configuration. But unfortunately, still not working.
The 1V rise 30ms after the 3V3, the oscillator works at 50Mhz, there is some activity on the MOSI SPI pin, but still unable to see the XS1 on the XTAG.
I've catched the 1V and 3V3 of the XR-AVB-LC-BRD board to power my board, for the power sequencing or if i've got a power supply problem, but not working also.

I will look for something else...

[mon2]

Wow. Tough case...but since you have tried so many logical ideas consider the following:

a) Remove the JTAG connection to the external XTAG interface and power up. Do you continue to see the same activity on MOSI ?

b) Without XTAG connected, what is the activity on Mode[2] & Mode[3] ? Since these pins are tied together, the results should match on both of these pins.

Here is what may be the next issue to review:

If you see activity on MOSI then the XS1 strapping appears to be in boot from SPI mode.

If XTAG is truly performing the JTAG function then believe that MOSI activity should stop. At this stage, best to check if the MODE pins are working / being sampled correctly. Sounds like the MODE[2] & MODE[3] pins are fixed to "11".

Force MODE[2] & MODE[3] to ground. Ok to do since drivers on these pins are open drain. Do not connect to XTAG tool and power up. Do you still see activity on MOSI ? In theory, you should not since now the MODE pins = boot from JTAG. Really interested to hear of your results from this test.

I did download the reference design you have followed and the original design also contains what appears to be the wrong PLL strapping. Unable to find any serious mismatch other than the power supply enabling & PLL pins. However, our local FAE believes that both PLL settings are ok to use. We have raised a technical support ticket with XMOS and they are reviewing why there appears to be differences in the PLL charts. Perhaps our misunderstanding but best to be safe.

On this note, review the same MODE values on the working reference design. If you feel comfortable, could you remove the SPI flash and place onto your board for testing as-is ? Then if your XS1 wishes to boot from SPI, there will be access to the working SPI flash. Just an idea. You may have to restore the original clock source since the original design uses the same clock source and appear to work even with the "wrong" PLL settings.

Since you are now using the same power source from working to your non-working board, we can no longer consider the power sequencing as the root cause. Please be sure that there is no conflict between the attached hardware (power supplies, etc.).

Do also check for assembly issues such as solder shorts, floating pins, etc.

Can you post again on what is your power supply source ? Voltage ? Current ?

[mon2]

One more thing...do you have another assembled board that matches your project ? Perhaps the XS1 is damaged or issue is local to this board only so worth testing on a fresh board ? Just an idea. Hoping this is not the case and certainly continue to test. There appears to be hope if MOSI is showing life.

Do you have perhaps the XMOS SliceKit or other similar tool / kits ?

Good luck and do post the MODE pin results.

[norman]

First thank you (again) for your time and ideas,

a) Remove the JTAG connection to the external XTAG interface and power up. Do you continue to see the same activity on MOSI ?

with or without le JTAG connected, on power up, i have the capture "power-up on SPI MOSI". SPI-MOSI stay 0 after, seems logical to me as there is no program in the flash.

b) Without XTAG connected, what is the activity on Mode[2] & Mode[3] ? Since these pins are tied together, the results should match on both of these pins.

without xtag, as MODE2-3 tied together with TRST, i've got 0->1 on power up and stay 1.

Force MODE[2] & MODE[3] to ground. Ok to do since drivers on these pins are open drain. Do not connect to XTAG tool and power up. Do you still see activity on MOSI ? In theory, you should not since now the MODE pins = boot from JTAG. Really interested to hear of your results from this test.

indeed same idea, i do force MODE2-3 to GND, there is not the activity on MOSI (and so TRST - no sure to understand how this pin work but should work the same way as the XR-AVB-LC-BRD) as the capture "power-up SPI MOSI with MODE2-3-GND"

If you feel comfortable, could you remove the SPI flash and place onto your board for testing as-is ? Then if your XS1 wishes to boot from SPI, there will be access to the working SPI flash. Just an idea. You may have to restore the original clock source since the original design uses the same clock source and appear to work even with the "wrong" PLL settings.

indeed also, i have considering it, i'll try.

do you have another assembled board that matches your project ? Perhaps the XS1 is damaged or issue is local to this board only so worth testing on a fresh board ? Just an idea. Hoping this is not the case and certainly continue to test. There appears to be hope if MOSI is showing life.

due to cost evaluation, i didn't have a second board, my first prototype is full of wired and temporary stuff and temporary-strange-zombie-power-supply but worked fine as the XR-AVB-LC-BRD works. With same components.

bye the way, as i have 2 xmos avb kit, so i have 2 xtag and the previous results are the same with both.
I'm in contact with my SMD provider to make an x-ray photo for the solder part in few days. I'll keep informed. Thanks !

[mon2]

Hi. Perhaps too early for my coffee to kick in but...

a) without XTAG, the Mode[2] & Mode[3] pins should be "11" = boot from external SPI flash = you should see lots of activity on MOSI pin. Is this correct behavior ?

MOSI = Master out (XMOS); Slave in (SPI Flash). The boot rom code inside the XMOS should attempt to load in data from the (blank) SPI flash. That is, I would expect more activity on the MOSI pin without the XTAG tool connected.

Agree that your flash is blank = corrupt with respect to the XMOS rom code but the rom code does not know of this detail so an attempt will be made to read in data and then halt / lock up due to this wrong formatted spi flash contents. Still should see some activity in the absence of the XTAG tool.

b) once the XTAG tool is connected, then the MOSI activity should be lot less or perhaps nothing (honestly never checked for this) - time permitting - can review this in the lab at work.

The XTAG tool is required to pull the boot mode pins to "00" = boot from JTAG.

Please be sure to monitor the proper pins (ie. MOSI vs. MISO) and certainly compare to the working board.

Another idea - you could strap the XSYS connector (on your working board) which is mated with MODE[2] & MODE[3] to ground to force the JTAG boot. However, remove the XTAG tool on the working board and review the MOSI pin - what is the activity ? Same as your board ?

Fully understand the pain and expenses in prototyping. We have been in the business for 30 years and have very high volumes of our products in the field. Once the dust settles, will be happy to share experiences on how to lower your production / sourcing costs. We have very reliable suppliers in Asia whom we have met and used for ages for our products. For best QC and control, we assemble locally here in Canada.

[norman]

a) without XTAG, the Mode[2] & Mode[3] pins should be "11" = boot from external SPI flash = you should see lots of activity on MOSI pin. Is this correct behavior ?

MOSI = Master out (XMOS); Slave in (SPI Flash). The boot rom code inside the XMOS should attempt to load in data from the (blank) SPI flash. That is, I would expect more activity on the MOSI pin without the XTAG tool connected.

Agree that your flash is blank = corrupt with respect to the XMOS rom code but the rom code does not know of this detail so an attempt will be made to read in data and then halt / lock up due to this wrong formatted spi flash contents. Still should see some activity in the absence of the XTAG tool.

on the previous capture, there is something like 400ms of activity on MOSI before going to 0, do you think there should be more ?
Finally, i try with a programmed flash memory (from my first prototype), i see activity on MOSI and MISO. MOSI signal is a little different from the empty flash memory, so i really do think (or hope...) that the SPI works fine and the software is loaded. I have to look further tomorrow if it has properly start or not. The Xtag still not see the XS1.

b) once the XTAG tool is connected, then the MOSI activity should be lot less or perhaps nothing (honestly never checked for this) - time permitting - can review this in the lab at work.

The XTAG tool is required to pull the boot mode pins to "00" = boot from JTAG.

I scan RST, TRST, TDO, TDI... and post in the middle of page 2 of this thread some capture where we can see that TRTS-mode2-mode3 is bring to 0 by XTAG dynamically. So i think (and as i experienced it with a working board) the xs1 can start with mode2-3 = 11 and then the Xtag bring it to 0 to boot by JTAG after reset (as i understand the capture of the JTAG page 2)

Please be sure to monitor the proper pins (ie. MOSI vs. MISO) and certainly compare to the working board.

I try it but as the flash memory is not programmed, the comparaison has not much value. There is some activity on MOSI after the power-up on both, not identical but make sense.
MISO on my board have no activity with an empty flash and some with the preloaded flash.

Another idea - you could strap the XSYS connector (on your working board) which is mated with MODE[2] & MODE[3] to ground to force the JTAG boot. However, remove the XTAG tool on the working board and review the MOSI pin - what is the activity ? Same as your board ?

for this test, MOSI pin stay at 0. On my board i've got a 75ms pulse on power-up and MOSI stay at 0 after.

[mon2]

Have a quick read of this thread:

https://www.xcore.com/forum/viewtopic.php?f=7&t=160

The boot rom inside the XS1 will send out standard (slow but common across all SPI flash vendors) the SPI commands to read from the flash memory. Based on this activity the boot process will continue or not from the external flash. The datasheet for the SPI flash will supply all of the details on which SPI flash commands are used for R/W, erase, etc.

http://www.spansion.com/Support/Applica ... N_01_e.pdf

The boot rom is most likely sending out SPI command 03 = READ command. Also note the timing for the other SPI flash pins which are worth investigating to see if they are the same as shown in this (typical) datasheet.

A logic analyzer or SPI bus analyzer will be of great help with this exercise. We use the Beagle tools from Total Phase with success + Zeroplus Logic analyzer (Taiwan) but there are many similar options on the market.

Nice to hear of something else to review on the SPI flash results. The more activity from the flash is due to the ROM reading a valid value from this external storage and then proceeding to read more data from this device. Very promising.

The difference on the XTAG strapping on the working vs. non-working is worth exploring. If possible, consider to source the same flash device (same footprint / vendor / part number) for inserting onto the working board -> use JTAG interface to compile a few lines of code to flash an LED or similar with a free port pin. You could even use the scope for this review and then apply this pre-programmed flash onto your board. Question is if your board is able to power up and flash the same port pin like the working board. This simple test will validate that your board is able to boot from SPI ok. It is a sanity check.

Best of course to not alter or erase the working flash from the working board. This is the golden sample which must be left in tact.

Believe you are getting closer to discovering the root cause. Keep at it !!

[norman]

hello,
after some round trip with my provider, it's finally works, "champagne !" . It was after all a soldering problem of the XS1. He made an X-ray picture and found 30% of pin soldering problem. I pass the details and the lost time... it's works (i didn't have the time to try the ethernet part, anyway).
He also made the adjustment of his process to not face this problem again.

thank you for your time and advice.

[infiniteimprobability]

That's great news and thanks for sharing the results.

Also, well done mon2 - shows how some strong technical knowledge and a helpful disposition can really benefit others.