Skip to main content
Visitor II
July 26, 2007
Question

Multiple Interrupt Problems on STR912

  • July 26, 2007
  • 19 replies
  • 3631 views
Posted on July 26, 2007 at 16:54

Multiple Interrupt Problems on STR912

    This topic has been closed for replies.

    19 replies

    Visitor II
    May 17, 2011
    Posted on May 17, 2011 at 09:44

    Does nobody answer? hello?

    There is a lot of months that there are messages on this forum on the problems of interruptions: interruption not triggered (better case), Bad vector fetching, processor crash, inadvertent reset … etc… Several forumers propose solutions, not always clearly, some time complicated…. What is sure: If you use the ST library just as it is, and you activate several ITS, you will have some “para-normal� events, in an extremely rare way. The reliability of your embedded software becomes extremely ... bad.

    But most astonishing: it is the deafening silence of ST: hello, Mirou?

    neil23Author
    Visitor II
    May 17, 2011
    Posted on May 17, 2011 at 09:44

    We are having severe problems when enabling more than one interrupt on the STR912 device.

    We currently have a 4ms timer 0 interrupt and an external interrupt on port5.1 (WIU line 9). If the two interrupts occur simulteously the micro crashes, sometimes it resets and reboots and sometimes it crashes and fails to restart again.

    Looking through the forums there seems to be considerable problems with the VIC architecture, with default handlers and other 'workarounds' being required.

    Is there a definate and final method by which to solve the multiple interrupt problem ?

    Thanks. :-[

    Visitor II
    May 17, 2011
    Posted on May 17, 2011 at 09:44

    Thank you, opijozko, but we have hundreds of equipment already manufactured… But your post confirms that, definitively, there is hardware problem on STR91x VICs.

    To solve our problem of IT in a reliable and final way, we wrote a single IRQ function, which does not take account of the VICs registers, and which switch to the good sequence according to the state of the peripherals. It is a little slower, but 100% reliable...

    Visitor II
    May 17, 2011
    Posted on May 17, 2011 at 09:44

    I completely agree with you Charlu...

    We need Mirou assistance !

    Thanks.

    Visitor II
    May 17, 2011
    Posted on May 17, 2011 at 09:44

    Hello.

    Try new STR912FA. It seems there are some improvements in silicon...

    Visitor II
    May 17, 2011
    Posted on May 17, 2011 at 09:44

    Charlu,

    It seems that that is the only way to go - I also get lost

    interrupts.

    By defining (empty) default interrupt handlers for each VIC

    I can at least avoid the device hanging or random branching.

    Can you give me an idea of how you have configured the STR91x

    to send all interrupts to the same handler?

    Visitor II
    May 17, 2011
    Posted on May 17, 2011 at 09:44

    Hi, whh1

    In fact, i use the code give by mark from AelMicro :

    http://mcu.st.com/mcu/modules.php?mop=modload&name=Splatt_Forums&file=viewtopic&topic=4630&forum=21

    But I did not use his kernel procedure. I test each peripheral state, and switch in case of.

    In addition, as i don't need nested interrupt in my project, i mask IRQ in the IRQ handler. My IRQ handler is :

    IRQHandler:

    SUB lr,lr,#4 /*Update the link register*/

    SaveContext r0,r12 /*Save the workspace plus the current*/

    /*return address lr_irq and spsr_irq*/

    LDR r0, = MyIrqHandler

    NOP

    NOP

    MSR cpsr_c,#0x1F | I_Bit /*Switch to SYS mode and disnable IRQ*/

    STMFD sp!,{lr} /*Save the link register.*/

    LDR lr, = IRQ_ReturnAddress /*Read the return address.*/

    BX r0 /*MOV pc, r0*/ /*Branch to the IRQ handler.*/

    IRQ_ReturnAddress:

    LDMFD sp!,{lr} /*Restore the link register.*/

    MSR cpsr_c,#0xD2 | I_Bit /*Switch to IRQ mode and disable IRQ*/

    LDR r0, = VIC0VECT /*Write to the VectorAddress to clear the*/

    STR r0, [r0] /*respective interrupt in the internal interrupt*/

    LDR r1, = VIC1VECT /*Write to the VectorAddressDaisy to clear the*/

    STR r1,[r1] /*respective interrupt in the internal interrupt*/

    RestoreContext r0,r12 /*Restore the context and return to the...*/

    /*...program execution.*/

    Visitor II
    May 17, 2011
    Posted on May 17, 2011 at 09:44

    I don't see any mention of a problem with the VIC in the latest errata (may 9, 2007).

    http://www.st.com/stonline/products/literature/es/12280.pdf

    Are you sure this is a silicon bug?

    Visitor II
    May 17, 2011
    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

    Visitor II
    May 17, 2011
    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 ?