Dangerous error causes fires and devastation!

[arta]

Hi. I'm glad you're reading this, i hope you can help.

Click-bait aside, i experience a nasty and unexpected behavior of external interrupts in a professional, industrial product designed around STM8AL318ATC.

In short, there are 2 digital signals (from an encoder) input in PD2 and PD4 to which i want to react by triggering an IRQ on every edge.

Pseudo-code with setup (macros that expand to proper register settings, i promise):

   EXTI_CONF1_PDHIS = 1u;     // PD[7:4] used for EXTID IRQ
   EXTI_CONF1_PDLIS = 1u;     // PD[4:0] used for EXTID IRQ
   // EN1_1 (encoder 0, signal A)
   REG_CR1(EN1_1) = CR1_INP_FLOAT;
   REG_DIR(EN1_1) = DDR_INP;
   REG_EXTI_CR(EN1_1) = EXTI_CR_EDGE_RISING_AND_FALLING;
   REG_CR2(EN1_1) = CR2_INP_IRQ;
   // EN1_2 (encoder 0, signal B)
   REG_CR1(EN1_2) = CR1_INP_FLOAT;
   REG_DIR(EN1_2) = DDR_INP;
   REG_EXTI_CR(EN1_2) = EXTI_CR_EDGE_RISING_AND_FALLING;
   REG_CR2(EN1_2) = CR2_INP_IRQ;

...and the ISR:

INSTALL_ISR(EXTID_vector, rotc_0_isr)
{// I got here due to an edge on either EN1_1, EN1_2, or both
/////////////////////////////////////////////////////////
DBG_HI(DBG0);
/////////////////////////////////////////////////////////
   EXTI_SR2 = MASK_EXTI_SR2_PDF;    // writing 1 clears flag
/////////////////////////////////////////////////////////
DBG_LO(DBG0);
/////////////////////////////////////////////////////////
}

The following grab shows the 2 signals together with my debug output, while serving the interrupt.

I hope it's clear to anyone that the behavior of the external interrupt controller is not according to expectations (clearly far from interrupting on *every* edge)...

The questions are now:

• Am i doing something wrong/missed some settings?
• Is this a bug in the HW (known or unknown)?
• Is this, after all, the expected behavior, documented in a corner of the manual that i missed, rendering this uC totally useless from my application?

Thanks in advance for your help!

Arthur

[martonmiklos]

Are sure that your sampling rate of your scope is high enough to capture a DBG0 pulses properly.

I would suggest to toggle the DBG0 in the ISRs if possible.

[arta]

Thanks for your input!

The image above is from a logic analyzer sampling at 250Msps, which is 3 orders of magnitude higher than my debug pulsing rate.

I chose to do pulsing so i can also measure the time spent in ISR, but i assure you that the pulses would be visible if interrupted. It's just that there are no interrupts at certain edges!

(I can also add that i eliminated all other code that might interfere with interrupts and i only run the short snippet above in a test program.)

[Cristian Gyorgy · Accepted solution]

Hello Arta!

Your ISR for EXTID is triggering all right. The problem is, you cannot use it this way - please see the capture below. The External Interrupt D will make the logical and operation with the enabled pins and only when the output of the and operation changes will trigger the interrupt. You can see this also in your logic analizer's graph.

So, I recommend you setup 2 different interrupts, EXTI2 for pin PD2 and EXTI4 for pin PD4.

[arta]

Hi Cristian, and thanks for your time!

Your observation makes perfect sense and explains everything i experienced.

What doesn't make sense whatsoever is why ST would produce such a messy design around interrupts? I've actually seen the schematic you're referring to, but i couldn't let myself believe that this is actually what is implemented!

I can't find a single use case that would justify this design choice, that effectively limits the number of usable interrupt sources to *one* per port/group...

I actually have 3 encoders (6 signals) to decode, and arranging these on uniquely numbered port pins is impossible/impractical on a board that's already in production.

The reason to decode these in SW in the first place, is due to the inbuilt HW decoder's inability to decode anything else than a perfect, lab-quality digital signal...

Anyway, you managed to point out exactly the confirmation that i needed, and it's not you who should be at the receiving end of my rant.

Thanks again,

Arthur

[Cristian Gyorgy]

Hi Arta!

Unfortunately is so. I also learned it the hard way...