ADC interrupt goes to default handler in Coocox COIDE

[ionutF]

Hello

I am (still) using CooCox IDE + STM Periph Libraries 1.5.0

In my code I finally enabled ADC interrupt , but surprise, the code is ending into default handler regardless the fact that I have a function with the same name as the adc handler used in the startup file

 .weak ADC1_COMP_IRQHandler

 .thumb_set ADC1_COMP_IRQHandler,Default_Handler

void ADC1_COMP_IRQHandler(void)

I isolated the code so that it contained only the adc config function + adc start conversion.

After many diggins and checkings I saw that in the stm32f0xx.h file there is a macro which renames ADC1_COMP_IRQHandler as ADC1_IRQHandler

#define ADC1_COMP_IRQHandler       ADC1_IRQHandler

my interrupt was not using the name given by the #define statement

I also noticed that in the IDE's outline view (list of functions headers) , the interrupt appears as ADC1_IRQHandler. I ignored this many times.

After I have exhausted all my ideas on why the interrupt was not working, I decided to comment that macro which renames the interrupt, and now my interrupt was starting to behave normally.

Does anybody knows why this behaviour happened ?

Are not the macros assigned before compiling ?

[TDK]

It's probably that the #define is not active when the startup file is compiled (since the relevant header isn't included), so the vector table includes ADC1_COMP_IRQHandler as the entry.

The define is active during C code compilation, which renames the IRQ handler and causes it to not overwrite the weak definition because it's called something else now.

The current STM32F0 vector tables use ADC1_IRQHandler as the vector table entry.

https://github.com/STMicroelectronics/STM32CubeF0/blob/master/Drivers/CMSIS/Device/ST/STM32F0xx/Source/Templates/gcc/startup_stm32f030x8.s#L153

https://github.com/STMicroelectronics/STM32CubeF0/blob/master/Drivers/CMSIS/Device/ST/STM32F0xx/Source/Templates/gcc/startup_stm32f030x8.s#L227

I'm guessing because you're using Coocox that your libraries/startup files/headers could be a bit outdated and/or mixed. (If you're looking to switch, the latest STM32CubeIDE is way better than Coocox, FWIW. I've used both extensively.)