This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Interrupts lost

I have a project with STM32F105 controller.
2 interrupts are used - UART1_RX and CAN1_RX.
Project developed with MDK-ARM v.4.21.
Everything worked ok until I recompiled it with the MDK-ARM v.4.22A
Now my interrupts are not firing.
The same thing happened on another project with the same controller.

Any idea on what could cause such a problem ?

Thank you,
Gennady

Parents
  • Yes, system and startup files are updated, though I tried to use older files stored in a local directory with no difference.
    And I am using ST libraries for peripheral drivers. It's also updated.
    It's quite confusing - both Keil and micro vendor have the same files, widely different in release time.
    Even CMSIS files are different.
    So what is better - to use latest versions ? Or Keil's for system and startup, vendor's for peripheral drivers ?
    I am trying to find a reason for such interrupts (mis)behavior, so far with no luck :-(.

    Thank you,
    Gennady

Reply
  • Yes, system and startup files are updated, though I tried to use older files stored in a local directory with no difference.
    And I am using ST libraries for peripheral drivers. It's also updated.
    It's quite confusing - both Keil and micro vendor have the same files, widely different in release time.
    Even CMSIS files are different.
    So what is better - to use latest versions ? Or Keil's for system and startup, vendor's for peripheral drivers ?
    I am trying to find a reason for such interrupts (mis)behavior, so far with no luck :-(.

    Thank you,
    Gennady

Children
  • I have a project with STM32F105 controller.
    2 interrupts are used - UART1_RX and CAN1_RX.
    Project developed with MDK-ARM v.4.21.
    Everything worked ok until I recompiled it with the MDK-ARM v.4.22A
    Now my interrupts are not firing.

    not at all, or not often enough?

    are you not familiar with the phrase 'debugging'?. Anyhow, the debugging is quite simple, look at the affected SFRs and backtrack when you find the missing/extra bits. "breakpoint stepping" followed by stepping while looking at the relevant SFR will lead you to the offending place. Not a big deal

    Erik