Home › Forums › Mastering STM32 book support forum › Cannot Toggle LED2 in First Chapter 7 Interrupt Example
- This topic has 4 replies, 2 voices, and was last updated 7 years, 9 months ago by LLH.
-
AuthorPosts
-
February 25, 2017 at 1:50 am #6295LLHParticipant
After building a project for this first interrupt example and comparing main.c in project to Filename: src/main-ex1.c in book (Page 202). I cannot locate problem. Project builds with not errors. Used procedures described in preceding chapters.
The configurations built for this project to launch OpenOCD and run Debugger do execute. The Debug Configuration window tabs figures are attached. The Eclipse window figure is attached for each of the following steps:
1. After Launching OpenOCD,
2. After running Debug Configuration and before selecting Yes to Debug Perspective Dialog Message question, and
3. After clicking Yes to Debug Perspective Dialog Message question.The only code added to project starts at line 93 in main.c and is shown below:
/* USER CODE BEGIN 3 */}
void EXTI15_10_IRQHandler(void) {
__HAL_GPIO_EXTI_CLEAR_IT(GPIO_PIN_13);
HAL_GPIO_TogglePin(LD2_GPIO_Port, GPIO_PIN_5);
}
/* USER CODE END 3 */All the other code was generated using the Sec 4.2 Project Generation procedure and Sec 7.2.2 Enabling Interrupts With CubeMX.
After turning on the “Skip All Breakpoints” button in Eclipse Debugger toolbar and hitting User Pushbutton, LED2 does not toggle. Why is EXTI15_10_IRQHandler procedure not being called? CubeMX (pin and configuration tab windows) were used to build HAL code tree below C:STM32Toolchaincubemx-out subdirectory. The contents of MX_GPIO_Init procedure in main.c implements statements which are in the body of Filename: src/main-ex1.c in book.
The “No source file named …” lines in Debugger Console tab of AfterConfirmDebugPerspectiveSwitch_ShowingDebuggerConsoleWindowTab.png attachment is for a different project. Is this an issue? The C:STM32Toolchainprojectsstm32nucleo-f446 subdirectory is a completely different project.
After comparing the book solution (zip archive) for NUCLEO-F446RE (stored at E:SoftwareDwnldsMasteringSTM32_Toolchainnucleo-f446REsrcch7main-ex1.c on my computer), there are differences from the project I created for this same example (C:STM32Toolchainprojectsstm32nucleo-f446_Ch7ex1srcmain.c).
The obvious differences are:
#include “stm32f4xx_hal_conf.h” //in main-ex1.c is missing from main.c and main.h of my project
HAL_NVIC_SetPriority(EXTI15_10_IRQn, 0, 0); //at Line 203 of main.c is not in main-ex1.c These levels match the levels selected in NVIC configuration area of CubeMX.main.c file of my project is also attached. If any other info is needed to support tracking down issues, just ask. Thanks.
All attachments are in zip archive. Too many files to attach separately.
Larry H
Attachments:
You must be logged in to view attached files.February 27, 2017 at 6:53 am #6320Carmine NovielloKeymasterThe attached main.c file contains a wrong definition of the EXTI15_10_IRQHandler() function. It’s defined inside the main() function. GCC has a non-standard implementation that allows to define nested function. This works, but the result is a totally different thing. And you cannot define ISR as nested functions.
February 27, 2017 at 9:49 pm #6331LLHParticipantCarmine,
I deleted the EXTI15_10_IRQHandler() function implementation in main.c
It is already implemented in stm32f4xx-it.c by CubeMX.I added the HAL_GPIO_EXTI_Callback() function implementation in main.c
Just to make sure this added function code is outside of main() function, I added it as noted below./* USER CODE BEGIN 4 */
–> HAL_GPIO_EXTI_Callback() function inserted here
/* USER CODE END 4 */I though since the location in main.c of my first posting was below the “while forever” loop of main() function, that it would be part of main.c (and not within main() function).
But as you pointed out, that is not true.
/* USER CODE BEGIN 3 */ }
}
–> This location is still part of main() function.
/* USER CODE END 3 */main.c and stm32f4xx-it.c files attached.
While researching the posted issues, I added the int variable, a, as a debugging aid. By inserting a=2 inside the “while forever” loop and setting a breakpoint at this location, execution at this location can be confirmed, It did not seem to work. After starting Run Configuration, setting some breakpoints (including at a=2 statement), and using the Resume button of Debugger toolbar to reach the MX_GPIO_Init(); breakpoint. the following summarizes results of subsequent steps.
1. stm32nucleo-f446_Ch7ex1_ProjectDebugger_ResumeToMX_GPIO_Init.png (shows correct value of a variable)
2. Click Step Over (F6)
3. stm32nucleo-f446_Ch7ex1_ProjectDebugger_AfterResumeFromMX_GPIO_Init.png
(PushButton toggles LED but next breakpoint is not reached)PushButton operation implies foreground execution within “while forever” loop but next breakpoint after invoking MX_GPIO_Init() is not reached. No value shown in variable tab for a variable. I do not understand why next breakpoint was not reached after step 2 Resume.
Larry H
Attachments:
You must be logged in to view attached files.February 27, 2017 at 9:53 pm #6338LLHParticipantHere is archive of *.c files which cannot be inserted directly for security reasons.
Larry HAttachments:
You must be logged in to view attached files.March 1, 2017 at 2:30 pm #6346LLHParticipantAfter reading pertinent pages returned by google agsinst the keywords: “volatile vs static in c”, the following info was pertinent.
Compilers can do a lot of optimizations based on the data flow of your program; volatile in C prevents that, It makes sure you really load/store to the location every time (instead of using registers and wiping it out e.g.).
In addition, the location for declaring the variable (a) was moved to the global section of main.c (outside of main() function). The new location for declaring variable is starting at line58. Since MCU is a 32-bit architecture, data type is unsigned 32-bit integer. line 58 to line 61 is listed below.
/* USER CODE BEGIN 0 */
uint32_t volatile a;/* USER CODE END 0 */
Now running debugger and using Resume (F8) debugger button, execution steps sequentially to the breakpoints at lines 79, 82, and 91. Contents of these three lines are listed below for reference.
Line 79: MX_GPIO_Init();
Line 82: a=1;
Line 91: a=2;A Debugger window after selecting F8 when breakpoint is at Line 91 is attached. Hoover over variable in main.c file to show value of variable. I still need to learn how to show variables in Variables tab (top right view within Eclipse window).
Larry H
Attachments:
You must be logged in to view attached files. -
AuthorPosts
- You must be logged in to reply to this topic.