STM32F0308-DISCOVERY: Issues with ADC and IRQ

[jgiraud9]

Posted on November 18, 2014 at 11:58

Hello,

I encounter a strange bug with an ADC acquisition on IRQ. I use an eval board STM32F0308-DISCOVERY. I program this board with Ride7 and the RkitARM. The start code of the application is generated by STM32CubeMX. Is it possible to reproduce the bug by following this steps:1 Genrate with STM32CubeMX a Keil project based on a STM32F030x8 MCU. in the ''pinout'' tab I select only ADC pin: IN0, IN1, IN2, IN3 and the temperature sensor. In the configuration tab I configure the ADC global interupt on enabled.2 I genrate the sopurce code for this configuration3 I open the Keil project genrerated with Ride74 In the main.c I add this call at the end of the adc init fonction (void MX_ADC_Init(void)) : HAL_ADC_Start_IT(&hadc);5 I build and run this application on the eval-board. The system seems to get stuck somewhere. When I click on the pause button the program is always on the same line: 080001B4:   TIM1_CC_IRQHandler  FEE7  B  0x80001B4  (R15 <=80001B4H)Its weird because the TIM1 capture compare IRQ is not enabled in this application. If I click on ''view linker map file'' I can find the 80001B4 address, extract of the file:  .text.Default_Handler                0x080001b4        0x2 C:\Raisonance\Ride\Lib\ARM\startup_stm32f0xx.o                0x080001b4                TIM1_CC_IRQHandler                0x080001b4                HardFault_Handler                0x080001b4                ADC1_COMP_IRQHandler                0x080001b4                PVD_IRQHandler                0x080001b4                PendSV_Handler                0x080001b4                NMI_Handler                0x080001b4                I2C1_IRQHandler                0x080001b4                SPI1_IRQHandler                0x080001b4                TIM6_DAC_IRQHandler                0x080001b4                EXTI2_3_IRQHandler                0x080001b4                I2C2_IRQHandler                0x080001b4                TIM17_IRQHandler                0x080001b4                RTC_IRQHandler                0x080001b4                TIM16_IRQHandler                0x080001b4                TIM3_IRQHandler                0x080001b4                EXTI4_15_IRQHandler                0x080001b4                RCC_IRQHandler                0x080001b4                DMA1_Channel1_IRQHandler                0x080001b4                Default_Handler                0x080001b4                CEC_IRQHandler                0x080001b4                TIM14_IRQHandler                0x080001b4                DMA1_Channel4_5_IRQHandler                0x080001b4                TIM15_IRQHandler                0x080001b4                EXTI0_1_IRQHandler                0x080001b4                SPI2_IRQHandler                0x080001b4                SVC_Handler                0x080001b4                TS_IRQHandler                0x080001b4                WWDG_IRQHandler                0x080001b4                TIM2_IRQHandler                0x080001b4                DMA1_Channel2_3_IRQHandler                0x080001b4                USART2_IRQHandler                0x080001b4                FLASH_IRQHandler                0x080001b4                USART1_IRQHandler                0x080001b4                TIM1_BRK_UP_TRG_COM_IRQHandlerThe TIM1_CC_IRQHandler is the first one to be declared. It seems that all the IRQ line got the same adress. It's logical that the system execute the first IRQ found.I have try to add the void TIM1_CC_IRQHandler(void) function to the STM32F0xx_it.c file. In this case the system go in the HARDFAULT HANDLER infinite loop.Somebody could help me to figure this out?Thanks a lot. #irq #adc #discovery #stm32f0

[Tesla DeLorean]

Posted on November 18, 2014 at 15:14

The .S file typically has the IRQ stubs weakly linked to point to the same routine, when your C code has the routine, it should link to that instead.

With C++ you will have name mangling which will change the name, you'd need to use extern ''C'' For just C, most likely it's not compiling and linking your routine/file, so examine why that is occurring.

[jgiraud9]

Posted on November 24, 2014 at 14:33

Thank's a lot for your fast and accurate reply.

I have check the .S configuration in Ride. In fact by default the compiler use a weird .o file located in the Ride folder. This file is compiled so this is not possible to check the content. There is an .s file in the project but the compiler don't use it.If someone got the same issue after an import from an STM32CubeMX project to Ride7, here is the solution: - Disable the default startup file in the ''Project>LD Linker>Startup'' menu by setting the ''use default startup'' on ''No''. Make sure to empty the ''startup file'' field otherwise the compiler will use the file in the field. - Copy the ''startup_stm32f0xx.s'' (find it in the \Drivers\CMSIS\Device\ST\STM32F0xx\Source\Templates\gcc folder) in your project folder. - Add the copied statup file and remove the old startup file in the ''application/MDK-ARM'' folder.This solution works for me.Thank's for the help.

[frankmeyer9]

Posted on November 24, 2014 at 16:46

In fact by default the compiler use a weird .o file located in the Ride folder. This file is compiled so this is not possible to check the content.

http://linux.die.net/man/1/objdump