help with CH_FAST_IRQ_HANDLER on a stm32f407

[robomancer]

Hi all, I'm trying to get an interrupt handler to work on an STM32F407 to trigger the emergency stop behavior of a robot. I got the basic thing to work by creating an EXTConfig, giving it a pointer to the handler and passing it to extStart, but I'm running into a problem where if the software crashes the interrupt handler doesn't fire and thus the stop button fails.

To work around that I wanted to use a "fast interrupt" (forgive me, I'm very new to low-level/RT programming) as per http://www.chibios.org/dokuwiki/doku.ph ... interrupts . Am I correct in believing that once I manage to get fast interrupts to work there's nothing I can screw up in software that can prevent the interrupt handler from running?

Which brings me to my next question; how do you make fast interrupts work? My current best guess has been to write the hander:

Code: Select all

CH_FAST_IRQ_HANDLER(VectorE0) {
    // light the LED
    palSetPad(GPIOF, GPIOF_15);
    // start the emergency stop
}

and then in my initialization code call

Code: Select all

nvicEnableVector(40, 2);

to set priority 2 to the EXTI15_10 interrupt (page 374 of http://www.st.com/content/ccc/resource/ ... 031020.pdf) and enable it.

I'm sure I'm screwing it up somehow (the LED doesn't come on), but I really don't know how, and the thousands of pages of docs are still a bit over my head...

Is there a better way I can ensure that a GPIO can trigger a behavior absolutely no matter what (eg, needs to work even if threads are deadlocked, etc)? Perhaps an example of NMI being used?

[robomancer]

Or, more generally than any of that, I'm facing a situation where I can reliably cause the system to crash, and I'm struggling to get a(ny) recovery mechanism to work. My latest idea was the following:

Code: Select all

CH_IRQ_HANDLER(NMIVector) {
  // this never runs
}

CH_IRQ_HANDLER(HardFaultVector) {
  // this never runs
}

CH_IRQ_HANDLER(MemManageVector) {
  // this never runs
}

CH_IRQ_HANDLER(BusFaultVector) {
  // this never runs
}

CH_IRQ_HANDLER(UsageFaultVector) {
  // this never runs
}

but none of them are ever called. Do I need to enable something somewhere?

[Giovanni]

Hi,

See the file vectors.c, you are using the wrong names for those handlers, this is why those are never called. In addition, those are exception handlers, don't use OS macros for declaration, just normal function declarations.

About fast interrupts, priorities are level 0 and 1 and are not affected by the OS however you must not call any OS function from fast handlers, PAL should be fine but it is the exception.

Giovanni

[robomancer]

... yep. Sure was reading the vectors.c for the wrong version of Chibios. X-|

So I've updated my code to

Code: Select all

void NMI_Handler(void) {
    // light the LED
    palSetPad(GPIOF, GPIOF_15);
}

void HardFault_Handler(void) {
    // light the LED
    palSetPad(GPIOF, GPIOF_15);
}

void MemManage_Handler(void) {
    // light the LED
    palSetPad(GPIOF, GPIOF_15);
}

void BusFault_Handler(void) {
    // light the LED
    palSetPad(GPIOF, GPIOF_15);
}

void UsageFault_Handler(void) {
    // light the LED
    palSetPad(GPIOF, GPIOF_15);
}

and it still doesn't light the LED, so none of those exceptions seem to be running when I crash the board. Are there others I should catch? Or do I have to enable them somehow? Is there some way to tag those handlers so that if they don't override a weak definition the compiler will complain?

On the fast irq handler question, could calling pal be the reason that the handler never ran? My current understanding of fast IRQ comes from page 381 of http://www.st.com/content/ccc/resource/ ... 031020.pdf , which seems to indicate I need to set EXTI_IMR and EXTI_RTSR and then configure NVIC, and if I do all of that correctly the handler I declared via CH_FAST_IRQ_HANDLER should run. Am I missing anything?

[robomancer]

So, it could also be that I'm not inducing a failure well enough. Here's how I crash it for testing:

Right now I'm using one of the SerialDrivers to listen to a Ublox GPS sending messages at ~10Hz. After parsing each message I resend the message via UDP (via netconn_sendto), and then immediately send a thousand more messages via UDP in a tight loop. After a while the whole thing hangs (including unrelated threads).

[robomancer]

For completeness, the code I'm running in an attempt to get fast IRQ to work is:

Code: Select all

CH_FAST_IRQ_HANDLER(VectorE0) {
    // light the LED
    palSetPad(GPIOF, GPIOF_15);
}

int main(void) {
  ...
  // E-Stop is connected to GPIOG_15
  EXTI->IMR = EXTI_IMR_MR15;
  EXTI->RTSR = EXTI_RTSR_TR15;
  nvicEnableVector(EXTI15_10_IRQn, 2);
  ....
}

Would you expect that to work? Am I way off base?

[steved]

Would one of the watchdogs do what you wanted, in a different way? Certainly they can be used to pick up software crashes and reset the processor, and the windowed watchdog in particular has some other features.

[robomancer]

Yeah, I'm definitely pursuing the watchdog angle independently. But it's a pretty lousy failure mode if your panic stop button doesn't take effect for a few seconds while the control board reboots.

[robomancer]

Anyone? Even a github link to an interrupt based hello world for the STM32 would be helpful (or anything that catches exceptions), I feel like I'm wandering around in the dark...

[robomancer]

Breakthrough! Apparently C++ mangles function names (for fun and profit, I'd have to assume), so I had to wrap the handlers in an extern "C" { } block. Now I'm getting a multiple definitions linker error on the VectorE0 handler (conflicting with ext_lld_isr.c), which suggests that it may be impossible to use both HAL_USE_EXT TRUE and CH_FAST_IRQ_HANDLER(VectorE0) at the same time, does that sound right?