Jinx, I see what you are saying about the fluff. I have not had this type of response problem from Microchip. Of course, I've not asked the same question you have. But still, I'm surprised at their (his) response. He seems to dance all around the issue, but never does get to the point of answering it. I have found the tech personnel at Mchip to be very helpful and to the point. Of course, I usually talk to the FAE and not with Mchip directly. And I can't answer the question either. But it sure is an interesting one. I have some F84's here. If you want to send me your code, or at least a flowchart of it, I'll try to duplicate what you're seeing aand confirm or deny a software problem. Actually, maybe a flowchart would be best. That way, I'll have to write the code to perform the operations and I'm sure I'd write different code than you to accomplish the same thing. If it happens with my code, chances are its a hardware problem. Otherwise, it would be a sfotware problem most likely. Does this sound reasonable to you? Let me know. Good luck Regards, Jim ----- Original Message ----- From: Jinx To: Sent: Friday, June 22, 2001 4:09 PM Subject: Re: [OT]: Program, verify,........ > > Can you believe that answer from Microchip support? Did that totally > > miss the point or what? > > > > I have never tried to ask them a question, but I have to wonder if they > > are often this far off. > > > > Anybody want to start a "Microchip support people say the darndest > > things" page? Are there other good examples of clueless responses > > from support? > > This is the last time I asked for help at Microchip. I complained to > the MC management about this reply, as it totally avoided answering > what I'd asked and was just simply a RTFM fluff response that I felt > was condescending and lazy. I did eventually get a considered > answer from a senior technician - it turned out to be a faulty (new) PIC > > > Can you tell me whether what I'm finding that happens with this > > F84 code is a software or hardware problem. I've asked the > > piclist but no one has been able to offer an explanation This is > > a complete program, just to test WDT/SLEEP/IRQ. I don't see > > anywhere in the datasheets about it being inadvisable to mix > > these three modes, although some on the piclist suggested > > there could be unforeseen quirks in operation if they are > > > > To summarise it, the PIC somehow seems to store an interrupt > > request, even though GIE, INTE and INTF are cleared. As documented, > > INTF is the place to look for a request. As this is cleared, where > > else could the PIC store it ? Perhaps somewhere in the gates that > > make up the interrupt system ? I've re-arranged the IRQ-related > > instructions in many permutations, but the effect still happens > > > > I'd be very grateful if you could take a look at this and offer any > > suggestions about mixing IRQs > > > > regards, Joe Colquitt, Auckland, New Zealand > > The program flow is relatively complex. Also, with no ORG statements, > it is hard to follow. Remember that the reset vector is at 0, and the > interrupt vector is at 4. ORG statements are needed for this. If your > program is missing them from the beginning, it would proably explain > the opperation. > > The device can be woken from sleep with an INT or WDT timeout. If > interrupts are enabled, then the program counter will be set to 4, and the > last address with be pushed onto the hardware stack. Remember that W and > STATUS are NOT SAVED when an interrupt occurs, and must be saved and > restored by the user program. Consult the section on interrupts for more > details in your databook. > > Bret Walters > Microchip Engineering Support > > -- > http://www.piclist.com hint: The list server can filter out subtopics > (like ads or off topics) for you. See http://www.piclist.com/#topics > -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics