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.
Possible xCore device burnout? / Extremely slow printing
-
- Experienced Member
- Posts: 75
- Joined: Sat May 07, 2016 11:47 am
-
- Respected Member
- Posts: 347
- Joined: Wed Jan 27, 2016 5:21 pm
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:
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
from a fresh project to check that aspect.
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;
}
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++);
}
-
- Respected Member
- Posts: 347
- Joined: Wed Jan 27, 2016 5:21 pm
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?
-
- Experienced Member
- Posts: 75
- Joined: Sat May 07, 2016 11:47 am
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?
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?
-
- Respected Member
- Posts: 347
- Joined: Wed Jan 27, 2016 5:21 pm
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
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
-
- Experienced Member
- Posts: 75
- Joined: Sat May 07, 2016 11:47 am
Actually the timer event does not trigger at all, although delay_microseconds works.
-
- Respected Member
- Posts: 347
- Joined: Wed Jan 27, 2016 5:21 pm
Hi,
Yes - by the sound of it the device has blown.
Cheers,
Henk
Yes - by the sound of it the device has blown.
Cheers,
Henk
-
- Experienced Member
- Posts: 75
- Joined: Sat May 07, 2016 11:47 am
Okay I just checked the TP7, it fluctuates between 23.70 and 24.50. Is that tolerable?
-
- Respected Member
- Posts: 347
- Joined: Wed Jan 27, 2016 5:21 pm
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
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
-
- Experienced Member
- Posts: 75
- Joined: Sat May 07, 2016 11:47 am
Does this help?
You do not have the required permissions to view the files attached to this post.