[LLH]

I found an alternate approach which did work as described below.

Go to the “The local archive way” topic at
https://gnu-mcu-eclipse.github.io/plugins/install/#troubleshooting

The GNU MCU Eclipse plug-ins releases are listed at
https://github.com/gnu-mcu-eclipse/eclipse-plugins/releases
I downloaded the v4.1.1-201707111115/ilg.gnumcueclipse.repository-4.1.1-201707111115.zip
file to my local hard drive and selected that location when the Archive button was clicked in “The local archive way” description referenced above. The entries as shown in
section 2.2.2 Figure 8: GNU ARM plug-ins selection
of the book are included in list.

Thanks for the bandwidth.

Larry

[LLH]

After 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.

[LLH]

Here is archive of *.c files which cannot be inserted directly for security reasons.
Larry H

Attachments:

You must be logged in to view attached files.

[LLH]

Carmine,

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.

[LLH]

A Google search against
“Program File does not exist” while trying to debug with Eclipse OpenOCD
lead to the following page.
http://www.openstm32.org/forumthread2987
The pertinent section is:

For:
Main (tab) => Project (field)
I clicked on the Browse button and selected the project name. Once this was done the elf file path and file name (relative to the Eclipse project) appeared in the C/C++ Application field.

Except the project name was already in the Project: Text Box. Just click the “Search Project…” button (below the “C/C:: Application:” Text Box. The applicable .elf file filename is found and placed in the “C/C:: Application:” Text Box. See attachment (ex1-DebugConfig_MainTab__RevA.png). Apply and Close the Debug Configurations window.

Debugger now runs fine. See attachment (Sec5-2_ArmSemihosting_RevA.png)

Larry

Attachments:

You must be logged in to view attached files.

[LLH]

Olivier,

Thanks for the reply. By placing the two -f options on separate lines, the debugger starts up and stops at the first statement in main.c
See Sec5-1-3_fig8_StartOpenOCD_locally.png

The console output after starting debugger is shown in Sec5-1-3_Fig12_DebugPerspective_OpenOCD_locally.png attachment. Can I assume the one error line
Error: already specified hl_layout stlink
is not crucial?
ST-Link Red/Green interface LED is blinking on nucleo-f446 board.

I’ll continue from this point in book using local openOCD debug configuration until it is not applicable to a specific section of the book.

Larry

Attachments:

You must be logged in to view attached files.

[LLH]

I just posted a message with this same symptom. Does this bug which prevents using the External Tool configuration mean GDB OpenOCD Debugging of a nucleo board cannot be done until bug is fixed?

Is the there any other debug procedure described in book which can be used to debug nucleo board over USB interface? Thanks.

Larry H

[LLH]

Ron,

Thanks for the added attachments. Test_04.png attachment (Your copy of Section 4.2.2 Figure 15) was the key. I was not following the proper case naming convention for MCU Macro which you circled in red (great highlight). Changing Vendor CMSIS name from stm32f4xx to STM32F4xx fixed the problem. Project now compiles with no errors or warnings.

Carmine’s book mentions the importance of using correct case convention for applicable names. He even used an example (i.e., a name containing f4 is different from a name containing F4). I just reconfirmed the guideline. 🙂

Larry

[LLH]

Ron,

Thanks for the comments. Since I do not have the AC6-based tool chain on my PC, the Toolchain Settings error message should be flagged as a false negative.in Section 4.2.1, Figure 11 specifies SW4STM32 as Toolchain/IDE dropdown selection. In the current version of CubeMX, there is an additional entry at the bottom which specifies path to Firmware Package and the “Use Default Firmware Location” checkbox is checked. See Sec4-2-1_Figure11.png attachment.

I imported the project manually. See the File-FoldersImportedToEclipseFolders.pdf attachment. This is my version of Sec4-2-3_Table2 which I generated for the details of this specific Eclipse project.

After looking at your project properties window attachment in your reply, there are significant differences from Figure 17 (section 4.2.3). I assume your figure is from the SW4STM32 Toolchain.The only C Compiler listed on the Tool Settings tab is MCU GCC Compiler. The only C Compiler listed in my version of Figure 17 (section 4.2.3) is Cross ARM GNU C Compiler. See Sec4-2-3_Figure17.png attachment. I did a Clean and Build Project for all three Configuration settings: Debug [Active], Release, and [All Configurations]. Same number of errors in each case. It looks like I need to find out how to add Cross ARM C Compiler to this STM32Toolchain.

Larry

Attachments:

You must be logged in to view attached files.

[LLH]

Larry

Ron, thanks for the tip. Section 2.2.2, Figure 8 of the book needs to be updated to reflect your comment. The “GNU ARM C/C++ Generic Cortex-M Project Template” entry needs to also be checked. See Sec2-2-1_Figure8.png attachment. Once I reinstalled GNU ARM Eclipse 3.2.1 plug-in with these settings, problem was fixed.

Larry

Attachments:

You must be logged in to view attached files.

[LLH]

Hold the press. After following the “troubleshooting section” link in the Read carefully paragraph on page 59, the described fix cleared the problem. I had to change C:Program FilesJavajre1.8.0_121libsecurity subdirectory property to uncheck Read Only property to copy files. Running Windows Explorer as Administrator was required. For security purposes, can I change this subdirectory property back to Read Only now? Resulting Figure 8 is attached.

Attachments:

You must be logged in to view attached files.

[LLH]

Carmine,

After correcting the issues you located so quickly, I am pleased to report the stm32Disc1_f429I compiles with no errors and one warning. It is the same warning detected in test project you provided in an earlier post of this thread for my reference.

Description Resource Path Location Type
unused parameter ‘Regulator’ [-Wunused-parameter] stm32f4xx_hal_pwr.c /stm32Disc1_f429I/system/src/stm32f4xx line 383 C/C++ Problem

After more errors were generated in my earlier build attempts, here are some lessons learned from a beginner’s perspective.

1. Do not use another error free project as reference basis for making changes in a project which does not compile; unless you know what you a doing. Reviewing my cliff notes, I see that I deleted the system/src/stm32f4xx/stm32f4xx_hal.c file which was the source of over 90 compile errors. A classic example of what happens when you perform a task without knowing what you are doing.

2. The crucial significance of Table 2 in section 4.2.3 (Importing generated files into the Eclipse project manually) really hit home after you discovered I forgot to go inside the Drivers/CMSIS/Device/ST/STM32F4xx/Include file system folder and drag all its content inside the system/include/cmsis Eclipse folder.

I suggest flagging the significance of Table 2 in the first paragraph of section 4.2.3 and suggest the developer number each row of Table 2. Note these row numbers within section 4.2.3 text. Check off each referenced Table 2 row after the select-click-drag of the file contents from .\Drivers\CMSIS\… or .\Drivers\STM32F4xx_HAL_Driver\… file system folder and to inside the applicable Eclipse folder. Where .\Drivers is a subdirectory of C:\Users\<USER-ID>\STM32Cube\Repository\STM32Cube_FW_F4_V1.11.0 directory on Windows OS.

Larry H

[LLH]

Hello Carmine,

I used section 4.2.2 to create a new project (STM32F429-DISC1) completing the project wizard through Finish. Then all STM32F429-DISC1 project contents was replaced with contents of project archive attached to your previous reply of this post. Project build was error free with only 1 warning.

Description Resource Path Location Type
unused parameter ‘Regulator’ [-Wunused-parameter] stm32f4xx_hal_pwr.c /STM32F429-DISC1/system/src/stm32f4xx line 383 C/C++ Problem

Attached file is an archive of the stm32Disc1_f429I project which generates the errors listed in the first posting of this thread. Thanks for the “golden standard” example. By comparing the two projects, I should be able to located the project file content differences. Then the hard part will start (i.e., Determine why the project differences exist).

Larry H

Attachments:

You must be logged in to view attached files.

[Author]

Posts