XLF216 XCore 0 not Enabled

Technical discussions around xCORE processors (e.g. General Purpose (L/G), xCORE-USB, xCORE-Analog, xCORE-XA).
GerhardNorkus
Active Member
Posts: 55
Joined: Wed Jan 05, 2011 2:15 pm

XLF216 XCore 0 not Enabled

Postby GerhardNorkus » Fri Mar 29, 2019 1:36 pm

Hi All!
XMosBot.zip
I have attached a design that we're trying to use. I've included the schematic and artwork excerpts for completeness. We based the power circuitry on a design that we are already successfully using an XLF208. The only difference is U07 has an SC189ASKTRT instead of the ADP2108, so that we can have up to 1.5A instead of 600mA for 1v0 bus (the schematic still has the ADP2108 in it, sorry!)

The oscope shows on power-up (or hitting reset button SW2, hooked to ADP2108 3v3 enable pin), that we have the following sequence.
1. TRST, RST, 1v0, 3v3 are all 0v
2. 150uS rise time for U09's output from 0v to 3v3
3. 5 ms delay
4. 50uS rise time for U07's output from 0v to 1v0
5. 100uS delay
6. 100nS rise time for TRST and RST to 3v3


The paddle for the ground is definitely attached (using solder paste). I have tried 3 chips, all with the same result. I even drilled a hole through the ground pad connections in the board and did a direct solder just to make sure I didn't have a mistaken idea about the ground connection. I get the xrun -l to correctly show the device O[0], but trying to run any XE file says that the XCore 0 is not enabled. I have 0.1uF decoupling attached to all of the VDD and VDDIO inputs as per the schematic and artwork. The 1v0 line is buried in the board and can be seen as a 20 mil trace.

What am I missing?
You do not have the required permissions to view the files attached to this post.
User avatar
mon2
XCore Legend
Posts: 1584
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Sat Mar 30, 2019 5:32 am

OTP_VCC (Pin 104 on TQFP128) MUST be powered and should be to +3v3 (currently is not connected) ; this is most likely your show stopper

X0D01 (Pin 27 on TQFP128) = requires 1K PU to +1v0 to allow for boot from internal flash

Please post your update after correction and testing.
GerhardNorkus
Active Member
Posts: 55
Joined: Wed Jan 05, 2011 2:15 pm

Postby GerhardNorkus » Sat Mar 30, 2019 12:40 pm

Hi mon2!

Thanks so much for taking a second to look at our design. :) Nice moniker!

Pin 27 is already attached to 3v3 on VDDIOL (not VDD) via R06(1k 1%) and R02 (68ohm 1%) as per the documentation (X007541, page 15, section 8). The resistors appear on the uProcessor schematic at the top right, attached to the QSIa bus. I don't think this is the cause, but I will check by moving the 1K connection to the opposite side of the 68 ohm resistor. This layout was used successfully with XLF208 chips and is in production.

We do not use OTP in our product. My understanding in the past, was that the OTP was optional (been using XMos since 2011, see XS1-L8A-64-TQ128-Datasheet(document X2843H) as an example of this at page 17, section 10). In scouring the document for the XLF216 and XLF208, I couldn't find anything that said it was optional. Over time, things change. OTP_VCC is not connected in the XLF208 design, which currently operates fine and was used as a basis for this design. But, as mentioned, things change. Perhaps this did.

I will give it a try. Hopefully, this is the magic bullet!

GJN
User avatar
mon2
XCore Legend
Posts: 1584
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Sat Mar 30, 2019 2:47 pm

Also, be sure that your external 24 Mhz clock oscillator is working as Pin # 1 (OE) is floating. For best results, always stitch Pin # 1 to Pin # 4 (to force the oscillator to be always enabled - just do not depend on the internal PU to be there).

While most oscillator companies feature an internal PU to +3v3 inside the package, we have been stung by this issue and was by a supplier in Taiwan who built for Fox oscillators. This was over 100k assemblies but still a pain when it fails to work as expected. We switched to a different oscillator supplier after this incident of around 5 parts that would not power up and oscillate (because our earlier PCBs left pin # 1 floating).
GerhardNorkus
Active Member
Posts: 55
Joined: Wed Jan 05, 2011 2:15 pm

Postby GerhardNorkus » Sat Mar 30, 2019 4:38 pm

Thx. The crystal operates fine. I hooked up to oscope.
GerhardNorkus
Active Member
Posts: 55
Joined: Wed Jan 05, 2011 2:15 pm

Postby GerhardNorkus » Sat Mar 30, 2019 4:38 pm

Thx...i haven't checked the other two issues yet.
User avatar
mon2
XCore Legend
Posts: 1584
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Sat Mar 30, 2019 5:41 pm

Perhaps picking at straws here but also review:

1) on the open drain buffer 74HC07 Pin 1 is for your external XTAG #RSTNT signal. This pin should have had the local pull up to +3v3 rather than pin # 2 (POR) as POR is already being driven by Pin 4 of U03 and features a local 10k PU. With this 2nd pull-up, the pull-ups are now @ 5k to +3v3. The XMOS original design has the pull-up only for the XMOS XTAG #RST line.

2) C22 delay cap on the XMOS ref design is at 2N2 but your schematic has 15pf.

3) Fairly confident and based on the assistance we did with another developer last year, the powering of the OTP_VCC pin was required else the same error was raised. After this fix, if you still have issues, consider to shorten the turning on of the +1v0 rail after +3v3 is stable. You are currently @ 5ms so you could try without C11 installed and check on the results.

4) Be sure that no other externally powered logic is driving voltages onto the XMOS CPU BEFORE the XMOS CPU is powered else you may be facing reverse bias / pre-bias issues due to an unpowered CPU. Have seen this issue with some major branded computers and it is a serious fault.

Curious to hear of your status and resolution.

Good luck!
GerhardNorkus
Active Member
Posts: 55
Joined: Wed Jan 05, 2011 2:15 pm

Postby GerhardNorkus » Mon Apr 01, 2019 2:17 am

Hi mon2,

Magic bullet indeed!

Soldered a jumper from the c04 to the VCC_OTP pin and it works fine. Also, good catch on the R07 and R26 both attached to POR. That was an error, but it did not affect the issue either way.

Much thanks for the time you spent on this. Always nice to talk to a master mechanic when working on the detail issues!
User avatar
mon2
XCore Legend
Posts: 1584
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Thu Apr 04, 2019 4:39 pm

Excellent !!

Who is online

Users browsing this forum: No registered users and 5 guests