Multiple Interrupt Problems on STR912

[neil23]

Posted on July 26, 2007 at 16:54

Multiple Interrupt Problems on STR912

[rhys]

Posted on May 17, 2011 at 09:44

Hello ALL.

Please find attached minimalist sample code that uses: A timer interrupt (increments a counter), 1024Hz periodic RTC interrupt (increments a counter), 115200 baud Tx interrupt (from buffer and uses UART FIFO). I'm using a STR912FW44X6 on a STR910-EVAL (MB460) Board with IAR compiler and J-Trace. Connect the board's UART_0 up to your PC with Hyperterminal going at 115200,N,8,1 (no hardware flow control) and enjoy. It seems to work for me. If anyone has got any improvements / corrections then please post them. Rhys

[charlu]

Posted on May 17, 2011 at 09:44

Hello red123 !

First , in certain configuration the probability of error is very weak. For example, I had a configuration with 6 interruptions, which generated an error of address in VIC only every 30 hours… Secondly, your interrup handlers are very short: risks of conflicts are very weak : you don't stress the system.. . Thirdly, i see that you have set manually DVAR to a default handler, that isn't in any St code example (but given by Mirou in one message in this forum (http://mcu.st.com/mcu/modules.php?mop=modload&name=Splatt_Forums&file=viewtopic&topic=5168&forum=21) , to handle ''spirious interrupt'', nice, isn't it?). Do you have verify how many time this handler have been triggered, and in this case, if you don't have lost an other interrupt ? In same way, do you have verify that you never triggered a bad handler, or you don't have lost any interrupt in case of two of them are triggered in same time and verify all of this with good statistic ?

[rhys]

Posted on May 17, 2011 at 09:44

Hello ALL,

an update ... By using Buffered I/O for my application and spotting that my RS232 TX buffer size of 256 bytes was causing my COMMS_232_putchar() to stall and then increasing the TX buffer to 2048 bytes, the system is still generating 53,000 + interrupts per second BUT the IDLE time is now 91.5+ % !!! My screen refresh time is down to 2.62ms. My system does have even more idle time if I place the 44kHz waveplayer code into the FIQ_Handler(). Rhys

[mark9]

Posted on May 17, 2011 at 09:44

Charlu (or anyone that has seen it),

can you post code that demonstrates the silicon bug in the VIC? -Lakata

[rhys]

Posted on May 17, 2011 at 09:44

Hello Charlu and ALL.

To answer your questions: 1) Interrupt handlers are meant to be very short - shorter the better ! 2) I was told to set the DVAR interrupt handler by ST via our distributor. 3) I have condcted the following experiments and here are my results for TWO different versions of the silicon: I ran the code that i previously posted, with a few bits extra to count the number of Dummy Handler 0 and Dummy Handler 1 interrupts. The code was ran for 2.6 days and just over 1,000,000,000 (OND BILLION) interrupts were counted. On ST912FW44X6 - 645, Dummy Handler 0 occured 14,586 times and Dummy Handler 1 had ZERO hits. On ST912FW44X6 - 710 (later silicon), neither Dummy Handlers had any hits. On my ''Real Application'', and using the 'ST912FW44X6 - 645', I have the following interrupts executing as a STRESS test: A 1ms timer interrupt (increments a counter), 1024Hz periodic RTC interrupt (increments a counter), 115200 baud Tx interrupt (from buffer and DOES NOT use UART FIFO - i have yet to figure out why in my main application turning the FIFO ON messes things up) - (continuously straming info to a PC). A 44KHz interrupt that continuously plays a wave file. USB Virtual comm port (continuously straming info to a PC). I am also updating information to a 128x64 LCD 5 times a second (each update takes ~= 5.540ms) All of these interrupts amount to ~= 53,959 interrupts per second ! AND I am left with a CPU idle time of 43% !!! This system has run for ~= 79,166 seconds and has produced ~= 4,295,026,691 interrupts producing 844,142 Dummy Handler 0 hits and none on Dummy Handler 1. It appears to be working perfectly. My final application will not be working the system this hard. I believe this answers SOME of your questions thus: A) Do you have verify how many time this handler have been triggered, and in this case, if you don't have lost an other interrupt ? - The count I get from the 1024Hz RTC interrupt matches my 1ms count, AND my 232 and USB 232 comms look OK and the wave playing is consistent. B) In same way, do you have verify that you never triggered a bad handler, or you don't have lost any interrupt in case of two of them are triggered in same time and verify all of this with good statistic ? - you appear to be asking THREE questions here, so my answer is split thus ... 1) The Dummy Handler does happen as per my data above and also there are no interrupts from the second VIC. 2) The STRESS testing has not crashed and all appears to be working and the RTC interrupt count ties up EXACTLY with the 1ms count. 3) I do not have any external interrupts that I can trigger at exactly the same time that I could measure a response to to verify that an interrupt is not missed in the manner to which you appear to be eluding, therfore you are on your own with performing that STRESS test. BUT it has NOT CRASHED, so i can only assume that no interrupts have been missed. I enclose my modified ''91x_vect.s'' that i will now be using, for ALL to compare to the original ''91x_vect.s'' that can be downloaded from the ST web site. The following is my Dummy Handlers in 91x_it.c ... ---------------- /******************************************************************************* * Function Name : Dummy_Handler_x * Description : This function Handles Default Vector Address. * Input : None * Output : None * Return : None *******************************************************************************/ unsigned int Vic0Cnt = 0; unsigned int Vic1Cnt = 0; __arm void Dummy_Handler_0(void) { ++Vic0Cnt; // for debug VIC0->VAR = 0xFF; } __arm void Dummy_Handler_1(void) { ++Vic0Cnt; // for debug VIC1->VAR = 0XFF; } ---------------- The following mods are in main.c ... ---------------- u32 vic_0_count; // actual number of IRQ's u32 vic_1_count; void main ( void ) { VIC0->DVAR = (u32)Dummy_Handler_0; // do this after the VIC has been enabled VIC1->DVAR = (u32)Dummy_Handler_1; } ---------------- This all seems to work very solidly for me. After you have conducted your STRESS tests, you can remove from the file ''91x_vect.s'' the lines commented thus ... ; !!! for test And also remove the lines from the Dummy_Handler_x() that are commented thus ... // for debug. Thus saving a number of machine cycles from every interrupt for MAXIMUM REV's !!! Hope this helps. If anyone has got any improvements / corrections then please post them. Also does anyone have any source code in Visual C++ Version 6 that recognises a virtual serial port device being plugged into a PC and then disconnected and then repeatedly disconnected and reconnected ? i.e The application functions as if it was using a REAL 232 COMM port. Rhys

[charlu]

Posted on May 17, 2011 at 09:44

Hi Rhys,

First, I am impressed by the quality of your work. Bravo ! I conducted the same sort of test on my entire software in December 2006 then in February 2007. I have five interruptions activates, plus Enet_DMA. We have only one date code: 0619. The last test have been conducted with three board in same time. The first result, is that the number of dummy interrupt varies for +/- 50% from one board to another. Can be in the case of several simultaneous interruptions, some interruptions are lost (or more exactly, not triggered with good vector) with extremely weak statistics. An other point : the number of dummy interrupt can change according to the number of active inputs/outputs or peripheral activities (not concerned by interruption). But there was an accident: whereas I had passed to other tests, the processor crashed - and an “informer� left in the interrupt handler leaves me thought that the address generated by the Vic was not a valid Irq handler. At this moment, I lost any confidence in the Vic, and, as I had already spent many time to understand these problems of interruptions, I decided to write a only one IRQ handler with test of each peripheral. However, the fact that you don't see any dummy interrupt with date code 0710, seems to show that there is a silicon evolution. But there is no communication evolution from StMicro. It's first time, in my career, that i have a statistics approach of software reliability...That does not seem to shock you… Sorry for my Frenchy English. Now, I'm on holiday... Good summer for all! Charlu. (lakata : ask to Mirou...).

[mark9]

Posted on May 17, 2011 at 09:44

[mark9]

Posted on May 17, 2011 at 09:44

I will confirm the bug in silicon rev 646. I just observed it for the first time in my code.

The problem appears to be a communications bug between VIC0 and VIC1, so it should only occur if both VIC0 and VIC1 are used for interrupts and there is an interrupt on VIC1 while the interrupt on VIC0 is being serviced. Red123's fix works for me. The workaround is to simply sanity check the VIC0_VAR value is non-zero before jumping to it. It is not necessary to check VIC1_VAR (my code does not check and has not crashed), but that doesn't seem to hurt. The Errata 1.1 mentions this problem is fixed in rev D silicon (>= 618) but I think this is a lie. One of the bugs was fixed in rev D, but there must have been a second bug that was fixed more recently (<= 710). To summarize, the bug exists at least to date code 646, but is fixed in 710. The workaround is to use Red123's code (above).

[mark9]

Posted on May 17, 2011 at 09:44

I have an interesting data point. It seems that the ''mask revision'', stored in the highest byte (31) of the OTP flash memory, is 0x13 for both date code 646 and date code 713 STR912FW44 chips.

Either ST Micro did not change the mask between 646 and 710, and thus did *not* fix this VIC bug, or they aren't very careful about keeping their version numbers straight on the die...

[mbicha]

Posted on May 17, 2011 at 09:44

I think I have the same problem. Charlu, maybe you can post some sample source code how you solved it ?

thx