I’ve bought 6 pieces of FEZ Cerberus’, because I’m programming different apps with them. Now I’ve got a problem. Some of these boards (4/6) won’t be recognized on my PC. Some days before, I had a similar problem, but I was able to see “unknown Device” on Device-Manager. I booted them new (with STDFU-Tester) and load the new DFU-File. After that, I opened FEZ-Config and updated the device. It worked really good, I could use the Cerberus after doing that. I had to do this i think 10 times, because my boards always lost their firmware after some days… I don’t know why…
But like I said, now it isn’t possible to do this anymore, because my PC dosn’t recognize them. The power-LED is glowing, but theres no new device. I tried to hold the Boot-Button, Reset-Button and all what i thought is possible, but nothing happens. 4 of these Boards are (i think) completly damaged. the others (2), i see “unknown Device”, but i cant reboot them…
Has anyone an idea, what the solution of this problem could be? I tried everything I could. :wall:
Thanks, and sorry for my bad english, i’m Swiss. ;D
yes, in former times, while it still worked, i had also a problem with connecting my Cerberus to the PC. I tried the different USB-Ports and it only worked on USB 2.0.
But now, it doesn’t work anywhere :think:
I also tried different USB-Cables, different PCs and different USB-Client’s SP.
@ John - Its a program where I have some inputs (a keyboard) and a display to give out some informations. the program extends a lot of “while’s”, because i have to stay there since i press OK or something else. i also use interrupts, but sometimes i have to wait with a while.
No, theres nothing in the device manager. only by one or two of my six Cerberus, theres a device called: “unknown device”. normally, there should be a device called “Cerberus in Boot” or something else, shouldn’t it? And nothing is able to recognize the “unknown device”, not FEZ Config, not STDFU, nothing. and the other 4 boards don’t show a message in device manager…
What ever you do in code, make sure you occasionally use Thread.Sleep(20) so you give the debugging engine time to respond. What you are possibly seeing is the processor too busy to allow the debugging engine to communicate with the PC - but by putting it in bootloader mode you definitely should see the bootloader device, so that’s strange.
@ rfr - It’s hard to say what could happen. Static, improper voltages are some possibilities. The DFU mode is something that is burned in to the chip by the chip manufacturer, not us.
For the ones that occasionally show up as unknown device, that is an issue we have seen a few times that we are trying to reliably reproduce. The only thing that helps it is to find a different computer where it works as some do and some don’t. As you noticed, USB 2 usually performs better.
No, I mean don’t do loops without a sleep at all because you will hog the processor. You can do sleeps for as long as you like. Timers are better for timed requirements, but a thread.sleep just relinquishes control of the processor and allows other threads to get some processor time; this is a common cause for not being able to attach the debugger.
@ John - yes, I’ve already recognized, that its possible to see the Cerberus as “unknown Device” on another computer, which wasn’t found on the first computer… i tried to reboot the cerberus on that PC where you can see it as unnknown device and it worked, but 2 or 3 times programming the cerberus later, it shows the same problem than before…
@ Brett - Ah, okey. I missunderstood you yesterday, and so i changed all thread.sleeps into a:
and as soon as the timer has triggered, the timeout-bool will be set.
Is that a clean way to do waits? i mean i’ve there a while(!timeout), but the timer will set it after the given time. Or should i change it back or into something else?
There are many patterns that you will come to use - pick whatever works for you and is simple to understand. But fundamentally, if you have multiple threads and use while(true) loops to just continuously iterate through your code, make sure you release the processor by using thread.sleep.
Getting back to the reason I pointed out using thread.sleep if you have while(true) loops: This can stop the debugger from attaching and cause the device to not respond to connections, and require you to reapply firmware to erase the running application - all were symptoms to your earlier issue. I don’t think this conversation is helping you get anywhere, you should just make sure IF you have a while(true) loop that there’s a sleep at the end of the loop.