Possible xCore device burnout? / Extremely slow printing

[mozcelikors]

Hello guys,

When developing with xCore-200 Explorer, I made a wrong connection and some device produced smokes (alongside was the Motor controller L298N, Motor, and another controller).
I hope it wasnt my XMOS device or the XTAG.
Is there any way I could know this?
The thing is, the code is now running extremely slowly ( Debug printf's are extremely slow, sometimes they dont even show up)
However, I can run the GPIO led example smoothly (Maybe this indicates that CPU is alive?), but with printf's still running slowly or otherwise not working.
Is it possible that it's a problem that is related to xTIMEComposer itself?
Any guidance as to diagnose this issue would be extremely appreciated.
Thanks in advance.

[henk]

Hi mozcelikors,

Sorry to hear of the smoke - everybody's worst nightmare!

The symptom of printing very slowly could be due to many things; including a poor oscillator, or the PLL may have been permanently put into bypass mode.

The first test to do is to write a program that flicks a LED on and off with a timerafter:

Code: Select all

t :> time;
while(1) {
  t when timerafter(time += 50000000) :> void;
  l <: 1;
  t when timerafter(time += 50000000) :> void;
  l <: 0;
}

Then use a wall clock and check the frequency - this should be exactly 1 Hz. If it is anything else, something has broken.

Second thing to check is how you print; whether you use xscope or not.
If you do not use xscope, printing is limited by the JTAG clock; check you haven't accidentally slowed that down.
If you do use xscope, printing is limited by the xscope link speed; check you haven't accidentally slowed that down. And outputting an enormous amount of data over xscope will also slow your program down.

Probably a good idea to run a simple program

Code: Select all

while(1) {
  printf("%d\n", cnt++);
}

from a fresh project to check that aspect.

[henk]

And it is possible the USB side of the XTAG has been damaged - that may still work, but with lots of resends. Try another XTAG?

[mozcelikors]

Hello Mr.henk,

I have tried another XTAG, but the result is the same.
But having tried a timer example, I can clearly see that the problem is with the XMOS timer/PLL. Now, do you have any suggestion to solve that, or would you say that getting a new board is probably the shortcut?

[henk]

Hi mozcelikors,

There is a possibility that the oscillator has burnt out, check the clock on TP7 - it should be a stable 24 MHz clock. If it is not, then it could be worth checking whether the inverter or crystal has given up.

If it is 24 MHz, and the LED is running approx 20x slower then it should be, then it is probably the xCORE that has gone, which would require you to replace the device or the board.

Cheers,
Henk

[mozcelikors]

Actually the timer event does not trigger at all, although delay_microseconds works.

[henk]

Hi,

Yes - by the sound of it the device has blown.

Cheers,
Henk

[mozcelikors]

Okay I just checked the TP7, it fluctuates between 23.70 and 24.50. Is that tolerable?

[henk]

That sounds like a lot; but it is possible that the scope measures it over a short period of time.

Put the probe on, put the scope on infinite persistence, and take a picture to see how stable it is and what levels the signals are?

Cheers,
Henk

[mozcelikors]

Does this help?