Hi,
Did you mention the errors you found somewhere on a forum? I'm interested. I've problem to make working a software interfacing a Nucleo board with a GPSDO using UART.
Thanks
Denis
There were a number of issues. here's a post I made about them on the book's website/forum.:
Thank you, thank you, thank you! I've been pulling my hair out for a week now trying to get a Nucleo-F767ZI up and running on a Windows 7 machine. Almost every attempt at a compile resulted in a slew of errors. Primarily indicating that numerous variables, macros, or functions could not be resolved. This despite the fact that all the relevant .h files were where they needed to be. Confusingly, sometimes a program would actually compile successfully.
****************** Here was the problem, as you pointed out. *******************
On page 103 the toolchain path should end in
“/gcc-arm/bin” right now it ends just with “/gcc-arm” couldn’t figure out why my project wasn’t compiling for about a week.
****************************************************************************
Making this change, appending /bin, for both the compiler and the build paths fixed it! On the toolbar select, Window/Preferences/MCU then select and set, in turn, the following settings with /bin at the end:
Global ARM Toolchains Paths
Global Build Tools Path
Global OpenOCD Path
I don't know how I would have figured this out on my own. If the compiler needs to know the path down to the /bin level how does it funtion at all without this information? Attempts to compile a project should just fail completely, not partially compile. Either the compiler is found or it's not, how does it just sort of work? An incorrect path to the compiler is not something I would have guessed caused the problems outlined above.
Some observations. The latest edition of the book I have indicated that Liviu Ionescu had not implemented project templates for the STM32f7xx families. In fact, the current GNU ARM Eclipse release does have the templates. There are issues, though. Liviu Ionescu includes a file _initialize_hardware.c which runs at startup and does a lot of the required hardware initialization. Following, the instructions in the book (page 132) that has you delete 5 files and then replace them with CubeMX generated files. However, the CubeMX generated main.c file contains much of the hardware initialization that's already in the _initialize_hardware.c file. Since that file is not one of the deleted files the compiler will throw a lot of errorrs due to multiple definitions. Either delete the _initialize_hardware.c file or remove the offending initialization stuff from the CubeMX generated main.c file.
In the /openocd/scripts/target directory there are .cfg files for the processor family you're using. In my case, the required stm32f7.cfg file is there. However, the /openocd/scripts/board directory is missing the companion st_nucleo_f7.cfg file which references the stm32f7.cfg target file. You can fix it by renaming the st_nucleo_f4.cfg file to st_nucleo_f7.cfg after you edit it so that this line: source [find target/stm32f4x.cfg] reads source [find target/stm32f7x.cfg].
HAL: Before getting this all fixed, I spent a lot of time tracking down various declarations back to their origins, trying to find out why stuff was not being resolved. I came to realize HAL is a labyrinthian maze of indirection! Some of this stuff is five or more levels deep just to find out the value is 0 or 1. I can't imagine ever getting a gut level feel for the processor if I make extensive use of HAL. I can see using it for initialization of a lot of stuff, but I'd really like a lower level interface to the hardware.