Forum Replies Created
-
Posts
-
Hi Carmine,
I’ve been really enjoying your book. It has helped me to get set up and you explain things very well. I noticed a couple places so far in the text that have caused me some delays:
In the installation process, Under CDT optional features “GDB Hardware debugging” must be installed. If this is not done, then when you try to install the GNU ARM plugins, “J-Link Debugging” and “OpenOCD Debugging” will fail to install. You don’t mention this on page 86. (OS X instructions. Have not checked instructions for other systems)
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.On page 153 we are instructed to start a telnet connection, but we also need to first open a new console window which is not mentioned. For beginners this is not obvious. Only took me half an hour to figure out, but still.
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 PathI 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 function 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. The instructions in the book (page 132) have you deleting 5 files and then replacing 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].
CubeMXImporter only works with Python 2.7 even though it’s claimed to work with Python 3.0. I already have 3.0 on my computer and didn’t want to install 2.7 too. I wrote a short windows.cmd file, formerly called a bat file, to do the same thing.
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 labyrinthine 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.
