Xrun: Cannot load image, XCore 0 is not enabled

Sub forums for various specialist XMOS applications. e.g. USB audio, motor control and robotics.
Post Reply
Bfisher
New User
Posts: 2
Joined: Fri Apr 05, 2019 10:16 pm

Xrun: Cannot load image, XCore 0 is not enabled

Post by Bfisher »

Hello All,

I'm working on a set of demo boards for some TI Audio DACs using the XEF216-512-TQ128, and I have just received my first order of prototype boards. Of the 10 I ordered, 4 of them are returning this error when I attempt to program them via JTAG. I've been following the recommendations from this support post to try and locate the cause, but so far nothing has worked.

1. The JTAG interface to the XCore has been disabled in the OTP security register. Not likely, devices should have been received in default configuration

2. The device is being permanently held in reset by the RST_N signal. Checked the RST_N signal, it is correctly releasing

3. No clock is being supplied to the device; or the clock frequency supplied to the device is unsuitable for the selected PLL multiplier. The PLL multiplier is set using the MODE pins and should be configured so that the XCore boots up at or below its maximum frequency. Further details on the MODE pins can be found in the relevant device datasheet. Supplied clock is at 24MHz, within datasheet recommendations. I've compared it to some other XMOS boards we have and it seems to be as clean or cleaner than those signals.

4. The VDD Core supply is outside of tolerance (see the device datasheet). Checked at source, pins, and at all bypass caps. Well within 10%.

5. The VDD PLL supply is outside of tolerance (see the device datasheet) or not present, or has a filter with too high a resistor. This will mean that the PLL is not locked and hence the XCore will be kept in reset. Checked this as well, filter is the recommended 4.75Ohm with 0.1uF cap, and voltage is within limit.

6. The power supplies have not been correctly sequenced. The VDDIO (and OTP_VDDIO if present) supply must be within specification (3.0V-3.6V) before the VDD Core supply is turned on; see the datasheet for details. This was my initial suspect. So I changed two of the caps to better follow the sequencing in the datasheet. After changing C102 (delays 3.3V rail) and C141 (delays RST_N signal) to 0.1uF, the 1V rail rises first, followed by the 3.3V rail slightly more than 10mS later. The RST_N signal is released about 400ms after that.

7. The device, especially the ground paddle, has not been correctly soldered to the board. This can either be in the form of not connected solder joints or shorted solder joints to other pins, ground or power. This is the last thing I'm checking, I have checked all of the pins around the device under a microscope and them seem to be okay. I can also see that some solder has flowed through the vias underneath the XMOS to the underside of the board, so I know that it was at least applied. However I am having one of the bad boards reflowed just to be sure.

I've included a capture of my power-up sequence and my schematic. If you have any other suggestions as to what it may be I'd appreciative. I'm running out of ideas on what else to look at.
Attachments
Power_Up_Sequence.png
(44.77 KiB) Not downloaded yet
Power_Up_Sequence.png
(44.77 KiB) Not downloaded yet
XMOS_EVAL_BOARD_SCH.pdf
(918.22 KiB) Downloaded 138 times
XMOS_EVAL_BOARD_SCH.pdf
(918.22 KiB) Downloaded 138 times


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

Post by mon2 »

Hi. From a quick review...
xmos_power.png
(12.08 KiB) Not downloaded yet
xmos_power.png
(12.08 KiB) Not downloaded yet
1) That is incorrect for the proper power sequencing. The 1v0 rail is the VDD rail so it is to be brought up LAST.

Please see here (more details should be posted inside the XMOS datasheet for your CPU)

https://www.xmos.com/developer/support/ ... os-devices

Moving forward, the issue is most likely due to your 1V0 regulator with EN pin being pulled high via R167. That is, the 1v0 rail is immediately enabled upon power up.

The correction here is to allow for the 3v3 rail to power up FIRST, monitor that the 3v3 rail is stable using a 3v0 rail monitor IC, then output a PG good to enable the downstream 1v0 regulator. Often these PG signals are OD (open drain) so be sure to have a local pull-up. Now only if the upstream 3v3 rail is stable (VDDIO), then enable the 1v0 rail for VDD.

Also be sure that the 24MHZ oscillator ALWAYS remains enabled - tie it hard HIGH to +3v3 for Pin # 1.


Hope this helps. Please review again and post your results for closure of this thread for future readers.
Attachments
xmos_power_sequencing.png
(64.26 KiB) Not downloaded yet
xmos_power_sequencing.png
(64.26 KiB) Not downloaded yet
Bfisher
New User
Posts: 2
Joined: Fri Apr 05, 2019 10:16 pm

Post by Bfisher »

Hi mon2,

Thank you for clarifying the power up sequence. I made some modifications to delay the bring-up on the 1.0 V rail until after the 3.3 V.
Modified_Enable.png
(15.19 KiB) Not downloaded yet
Modified_Enable.png
(15.19 KiB) Not downloaded yet
The power up sequence is now 3.3V rail -> 1.0V rail in roughly 20ms (within the 50ms recommended in the datasheet), followed by the RST_N signal being released 40ms later. However, I am still encountering the same error when I try to program the device via JTAG.
Attachments
Corrected_Power_Up_Sequence.png
(49.26 KiB) Not downloaded yet
Corrected_Power_Up_Sequence.png
(49.26 KiB) Not downloaded yet
Post Reply