The Background - I have a TE35 display attached to a FEZ Spider via all 4 Gadgeteer cables. The only other module attached is the USB Client DP, with a separate 12V 3A power supply connected to the power plug and the USB debug cable connecting the PC to the USB Client DP module. The booter and firmware are up-to-date. TinyBooter is 4.3.4.0, and TinyCLR is 4.3.6.0. I have confirmed that the cables are in good shape and are solidly in the connectors. The Gadgeteer application is empty…just the default Debug.Print in ProgramStarted. No code has been added.
The Issue - If only the R, G, and B cables are connected, the display initializes just fine 100% of the time. But if the T cable is connected (to socket 10), when I deploy and debug or when I just reset the Spider after deployment, about 60% of the time, I get an Abort Prefetch dump on the TE35 display. The other 40% of the time, I get the standard EMX info message on the display. When I get the Abort Prefetch dump, the debugger output window shows a waiting for initialization message, and we never get the debug output from ProgramStarted.
Some Troubleshooting - Initially, I didn’t have the separate power supply, so the first time I saw the Abort Prefetch dump, I thought it might be a power issue and added the power supply to the mix. I have since tried removing the power supply, but still get the same failure rate - about 60% result in the Abort Prefetch dump. If I disconnect the T cable, the Abort Prefecth issue disappears completely.
Is this a known issue with TE35 and/or Spider when the Touch cable is attached? Is there something I can do differently to avoid it?
Unfortunately, no. Just the one Spider and one TE35 here. Without changing anything, the failure rate on startup is now about 50% (with or without the external power supply attached). No explanation. I haven’t moved anything or made any changes to the software; just restarted many times. When it doesn’t get the Abort message, it works perfectly.
Before seeing your suggestion, I observed a degradation…I was getting either Abort Prefetch, Abort Data, or Undef Instr dumps on about 80% of the resets.
I will reload the loader and firmware and let you know the results.
I reloaded the loader and firmware on the Spider. I seem to be getting fewer of these issues, but the sample size is admittedly small. I’m still seeing a mix of Abort Prefetch, Abort Data, or Undef Instr dumps on about 25% of resets.
Could I have a bad Spider or a bad TE35? I do have a Raptor on hand that I haven’t unwrapped yet. I will try the same code and TE35 on the Raptor, and see how it goes.
I finally got around to testing on the Raptor. On the Raptor, I see none of these dumps on the display. Everything works without a hitch. The application code is the same, except that the mainboard is a Raptor instead of a Spider. All the modules the same ones I was using on the Spider.
I have used the Spider for a number of other things, and have never seen these behaviors on it. This is the only application that demonstrates the Abort Prefetch, Abort Data, or Undef Instr dumps, and it is pretty inconsistent now, averaging about 20% of the time.
This is probably a silly questions, but Is there some sort of comprehensive diagnostic I can run on the Spider board to see if it has a problem?
@ kengr - We have looked into the issue but were not able to reproduce it. Did the Spider ever work properly or has it shown this behavior since you bought it?
I used it for several small demo applications before where it did not demonstrate this behavior. It only started showing this behavior when I put together a very simple camera/display application using the camera module and TE35. However, once the behavior started to happen, even an empty Gadgeteer application would reproduce the behavior.
Ever since it started, the frequency of the problem has varied from 100% reproducible on every boot to around 10% of the time, and everything in between. Sometimes I go a whole day without it happening, and the next day it might happen 50% of the time (even with no changes to hardware, software, or power source. Very odd.
So, I can use it for development and just reboot until I don’t get the dumps in the display, but it’s disconcerting and a little frustrating…not knowing why it’s happening.
If there’s anything I can do on this end to help diagnose it, please let me know.
Well, not on the Spider. But I used the exact same T cable when I tested on the Raptor, and didn’t see any problem there. (I just leave the RGBT cables attached to the TE35, and attach the other ends to the mainboard sockets on whatever mainboard I’m using.
Would the fact that it worked fine on the Raptor with the same cable be enough, or do you think I should try using a different T cable on the Spider anyway?