STM32F4 EXTI problem

[Ribster]

Hey everyone,

I'm working on a project with the allknown nRF24L01+. I'm using an STM32F4-discovery to get my proof of concept working, connected with STLINK V2 via SWD.
Software setup is eclipse with the C++ library from Andy's workshop with GDB. https://github.com/andysworkshop/stm32plus. Not that it matters, but some background..

Issue:
External Interrupts.
Description:
I've got the pushbutton(PA0) set-up as an EXTI-line, SPI via DMA to the nRF module, and the IRQ-pin from the nRF module also configured as EXTI, UART for printing to terminal.
So pheriperals used:
2 EXTI, 1 SPI via DMA, UART, Systick Timer set to 1ms.
Problem:
So i'm setting everything up, and looping a string to the UART-bus.
The moment i push the button on the PA0-line, the activity on the UART stops.
I've set a breakpoint to my interrupt function, but it doesn't stop at the breakpoint.
Solutions:
I think the pointer reference became invalid. Maybe it was a heap-problem. Fixed it by putting the functions into the right place.

EDIT: The PA EXTI interrupt is from an example so normally it works. I've got some peripheral compliancy issues is guess.. Is the Systick timer interrupting everything ?

EDIT: Added the 'solution'. Quite dicky solution, but hey .

Any help is welcome, also debugging-tips are welcome. For instance, how can you detect a hardfault failure via GDB&SWD ?

[andersm]

Is the Systick timer interrupting everything ?

An interrupt with a lower preemption priority can interrupt another with a higher preemption priority. Download ST's Cortex-M4 programming manual and read the chapters on exceptions, interrupts and the NVIC.

Any help is welcome, also debugging-tips are welcome. For instance, how can you detect a hardfault failure via GDB&SWD ?

Install a default handler for all unused interrupts and exceptions, set a breakpoint there.

[andyturk]

Double-check your EXTI vector (e.g., read the address at runtime in the debugger). Sounds like the core is jumping to something other than what you think and crashing there.

[dannyf]

Problem:

Without knowing what you are doing, it is impossible to help you.

Is the Systick timer interrupting everything ?

It is interrupting anything with a lower priority.

how can you detect a hardfault failure via GDB&SWD ?

The simpler approach is to set through the code and see when you end up in the fault handler.

A more fulsome approach is to save the stacked registers in the fault handler and print them out (mostly LR and PC registers) and go through the assembly file to see what triggered the hard fault. Yiu gave a pretty detailed example in his book and I can confirm for you that it works (99.9% of the time).

[dannyf]

BTW, the whole EXTI module from ST is fully messed up.

[andyturk]

BTW, the whole EXTI module from ST is fully messed up.

LOL

[Ribster]

To start, thank you everyone for trying to help. It's a learn process these STM's. I've already learned a lot, but still a lot left .

Is the Systick timer interrupting everything ?

An interrupt with a lower preemption priority can interrupt another with a higher preemption priority. Download ST's Cortex-M4 programming manual and read the chapters on exceptions, interrupts and the NVIC.

Thanks for that. I've got those datasheets, but it's sometimes too much to go through. I'm trying to find the EXTI preemption priority, but still looking. Found the systick one though.

Any help is welcome, also debugging-tips are welcome. For instance, how can you detect a hardfault failure via GDB&SWD ?

Install a default handler for all unused interrupts and exceptions, set a breakpoint there.
Good idea, i'm gonna look into that.

Double-check your EXTI vector (e.g., read the address at runtime in the debugger). Sounds like the core is jumping to something other than what you think and crashing there.

Is that the EXTI->SWIER register ? Tried making a watchpoint out of it but failed. Think i'll need to use the absolute adress to set the watchpoint.

Problem:

Without knowing what you are doing, it is impossible to help you.
I thought i stated it above, no? I didn't wanted to give it too much ink, because i just don't know what's happening. I'm pressing the button and the cpu freezes, that's all i know.

Is the Systick timer interrupting everything ?

It is interrupting anything with a lower priority.
On first glance, the routine SYSCFG_EXTILineConfig doesn't allow you to add a priority. Is the priority of the EXTI's set globally for all EXTI's ?

how can you detect a hardfault failure via GDB&SWD ?

The simpler approach is to set through the code and see when you end up in the fault handler.

A more fulsome approach is to save the stacked registers in the fault handler and print them out (mostly LR and PC registers) and go through the assembly file to see what triggered the hard fault. Yiu gave a pretty detailed example in his book and I can confirm for you that it works (99.9% of the time).

What do you mean with LR and PC registers ? Assembly is sadly not one of my skills at the moment..

So i've played around with it today for a few hours. Just a loop with the interrupt works. When i add the systick timer, no problems.
If i implement everything back again, the thing freezes like a horse on antartica.
I'll be troubleshooting it again tomorrow after work, so i'll keep you guys updated.

A general thing that i have, is the fact that i sometimes need to reprogram my uC via GDB a few times and hit reset a few times before the new program loads / starts correctly. Is this something that you guys have noticed before on those discovery boards ?

Greetings and cheers for all the effort guys!

[mrflibble]

BTW, the whole EXTI module from ST is fully messed up.

I thought we were already doing Microcontroller Mad Libs in the other thread.

[dannyf]

What do you mean with LR and PC registers ?

Read Yiu's book.

If that's too much, just step through your code and see when you jump into the hard fault handler.

[Kjelt]

A general thing that i have, is the fact that i sometimes need to reprogram my uC via GDB a few times and hit reset a few times before the new program loads / starts correctly. Is this something that you guys have noticed before on those discovery boards ?

Be sure that you fully erase the chip on reprogramming (this is an option in most IDE settings), see if that works better, it did for me in the past.

[andyturk]

Is that the EXTI->SWIER register ? Tried making a watchpoint out of it but failed. Think i'll need to use the absolute adress to set the watchpoint.

No, not a register. There's a table of pointers-to-code that define what happens when an interrupt is serviced. One of the entries in that table holds the address for your EXTI0 interrupt routine. Take a look at Section 9.1.3 of the STM32 Reference Manual (RM0090).

Each entry in the vector table is 32-bits, so figure out which one corresponds to EXTI0, read the actual contents of what's in *your* vector table from memory at runtime and place a breakpoint on that address.

[mikerj]

Adding a proper hard fault hander before you start coding the guts of your project is always worthwhile on the Cortex M parts.

Have a look at this simple example, and a more complex implementation.

Adding a BKPT instruction to the end of the handler means you don't even need to remember to add a hard breakpoint when debugging.

[Ribster]

To give some feedback to everyone, the problem is fixed.

Code: [Select]

      GpioA<DefaultDigitalInputFeature<BUTTON_PIN> > pa;

      // enable EXTI on the button pin and subscribe to interrupts

      Exti8 exti(EXTI_Mode_Interrupt,EXTI_Trigger_Rising_Falling,pa[BUTTON_PIN]);

      exti.ExtiInterruptEventSender.insertSubscriber(
          ExtiInterruptEventSourceSlot::bind(this,&ExtiTest::onInterrupt)
        );
I'm using a c++ implementation wich uses a slot (don't quite get the actual workings but whatever), to execute the wanted function when the interrupt occurs.

If i use the 'insertSubscriber' routine to set things up, i'm passing the pointer of the function that i want to execute. In this case it's '&ExtiTest::onInterrupt'.
ExtiTest being the current class, onInterrupt being the interrupt routine.

The problem was that if i didn't place this 'insertSubscriber-function' in the correct place where the infinite loop was executing, i had a hardware freeze.
Thanks everybody for the valuable debug tips, i'll keep them in my troubleshooting toolbox .
When the project is done in february, i'll do a writeup about it.

Greetings and thanks to everybody