|
Actually I just remembered a situation where we have seen this sort of thing
(ie unhandled interrupt) in our systems. It happens if we leave the parallel JTAG cable connected to the system after the program has been downloaded. Of course, this is the normal situation when you are debugging. It looks like leaving the JTAG cable connected creates a path into the chip for noise glitches to disturb the chip and cause the unhandled interrupts. I had this happen less than an hour ago, and removing the JTAG connector fixed the problem. Another thing that has cropped up recently is program crashes caused by the Hardware Stack Overflow (Vector number 5, Address X:$000A). This is being caused by CodeWarrior placing 'do' instructions in the program, despite the fact that the "Allow DO Instructions" box is unchecked in {Target}->Target Settings Panels->Code Generation->M56800 Processor. We haven't installed a vector for this (mainly because there's no way to recover from it anyway), so it gives us the unhandled interrupt. Our MSCAN software (J1939 task) seems to have a lot of these 'do' instructions for some reason, and crashes the program about once a minute. Metrowerks is currently working on a fix for this bug. I am posting this message to the discussion group because I think it could help others who might be experiencing these problems. Regards, Art Johnson Senior Systems Analyst PMC Prime Mover Controls Inc. 3600 Gilmore Way Burnaby, B.C., Canada V5G 4R8 Phone: 604 433-4644 FAX: 604 433-5570 Email: http://www.pmc-controls.com ============================================================= No, we have not had this type of problem. One of our systems has interrupts coming from four 115200 baud serial ports (2 internal and 2 external), which have an interrupt on every character sent or received (ie 11520 interrupts/second from each port). It also has 2 period measurement inputs from Timers (3000 interrupts/second each), 2 periodic Timer interrupts (1200 interrupts/second total), plus the CAN interrupts at 800 per second. This is a total of 54080 interrupts/second. We have also enabled nested interrupts, and have interrupts coming in from all 7 priority levels. This system has been operating reliably for many months with this setup. The serial port interrupts are, of course, written in assembler for speed, and they are "Super Fast" interrupts where the interrupt vector points directly to the ISR, completely bypassing the SDK Interrupt Dispatcher. Have you checked your stacks to see if any of them are close to overflowing, or is it possible you are running out of CPU time? In our systems we are using the DSPOS RTOS, which has a utility that tells you what percentage of each stack has been used. We also have a free-running counter in the lowest priority task, which is read and cleared once per second. From this value we can calculate what percentage of the total CPU time is still free. I hope this helps. Best regards, Art Johnson PMC Prime Mover Controls Inc. -----Original Message----- From: Danknick, Dan [mailto:] Sent: Wednesday, October 09, 2002 11:19 AM To: Art Johnson Subject: Thanks again, Art I appreciate the time you took to answer my MSCAN questions on the Yahoo group. In our DSP we have 4000 interrupts/second coming in from a D/A converter and everything works fine. When I then add about 800 more CAN Rx interrupts/sec the system becomes unstable and usually crashes into the unhandled int function - originating from vector #2 which is unsupported! Have you any experience with core instabilities based on high interrupt rate or high nesting rate? Best regards, Dan Danknick Celerity R&D |
RE: Thanks again, Art
Started by ●October 9, 2002
