Question and suggestion for Mastering STM32 eBook

[Carmine Noviello]

mzaffalon wrote:

Hi Carmine,

In section 9.2.7 of version 0.22 of the book, you remark that one should enable the UART interrupt for DMA transfer, but as far as I can tell, you don’t explain why. Could you add a line in the book or a reference to the place where you give the explanation?

(In an official MOOC class from ST on the CubeMX, for instance, there was no mention of enabling the UART interrupts.)

Thanks,
michele

Well, you are right. I should explain why. The reason is that the HAL assumes that the “HAL_UART_IRQHandler()” routine is properly called to setup internal HAL states. They are mostly related to UART error states (overrun, parity error, etc).

[Carmine Noviello]

bdang wrote:

Hi,

Typo on page 142:

while(1) {
75 HAL_GPIO_TogglePin(LD2_GPIO_Port, LD2_Pin);
76 HAL_Delay(500);
77 }

The pin was named LED in the Cubemx example, not LD2 which will cause the errors.

Best,
Brian

Which Nucleo are you using?

[gertux]

Hello Carmine, just started reading your book cover to back (I’m on page 205), great content.
Just wanted to let you know I found some typo’s.
I suppose it’s OK to report them here ?

p34, 1.3.7 H7:
MCUs will open the doors to dual-core STM32 MCUs, tanks thanks to the 40nm production process

p139 below figure 19:
So, ST developers have leaved left to the user the responsibility …

p156 in blockquote:
… or at least a weird behaviour. It may happens happen really often especially when there are is more than one project opened.

p 171 5.2.4:
What we will be described here is an advanced topic

p 205 below figure 7:
So it is leaved left in pending state until the A ISR concludes its operations

• This reply was modified 7 years, 5 months ago by gertux.

[maartenweyn]

Hi,

I think there is an error in table 2, p471, section 15.1.3 of version 0.22 of the book:
For NUCLEO-L152RE the SCK pin of the first set of SPI1 pins should be PA5 instead of PB3

[Anonymous]

Hi Carmine,
I have found some more typos

-page 629 portmarco.h instead of portmacro.h (section 22.2.1)
-page 645 chapter 13 instead of chapter 19 (the link is correct) (section 22.4.1.3)

Thanks for writing this book!
Pedro.

[mghecea]

Hi Carmine,

I just bought your book because I love the layout of it and the color…I’m sure it is a remarkable piece of work…Any chance you will add the much anticipated TCP/IP webserver chapters ? I noticed you wrote an article on LwIP. Perhaps at least touch on the example that comes with the NUCLEO-144 board.

i.e. C:\your_user_name\NUCLEO144\STM32Cube_FW_F4_V1.16.0\Projects\STM32F429ZI-Nucleo\Applications\LwIP\LwIP_HTTP_Server_Netconn_RTOS

It would be a goldmine if you have time to do it…

Cheers,

Mario G.

[clesoine]

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.

• This reply was modified 7 years, 1 month ago by clesoine.

[maxxir]

Hi Carmine,
Typo on page 20.
Geoffrey Brown book based on STM32 VL Discovery – STM32F100RBT6 controller from STM32F1 series.

• This reply was modified 7 years, 1 month ago by maxxir.

[gdg]

clesoine wrote:

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

• This reply was modified 7 years ago by gdg.

[clesoine]

Glad my comment helped someone!

[mklengel]

Jello Carmine,

I‘m a beginner regarding STM32 so forgive me my
possibly stupid question.

My setup consists of

NUCLEO-F746ZG Development Board
https://my.st.com/content/my_st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-eval-tools/stm32-mcu-eval-tools/stm32-mcu-nucleo/nucleo-f746zg.html

X-NUCLEO-IDW01M1 WIFI Expansion Board
https://my.st.com/content/my_st_com/en/products/ecosystems/stm32-open-development-environment/stm32-nucleo-expansion-boards/stm32-ode-connect-hw/x-nucleo-idw01m1.html

X-NUCLEO-LED16A1 16 Channel LED Driver Expansion Board
https://my.st.com/content/my_st_com/en/products/ecosystems/stm32-open-development-environment/stm32-nucleo-expansion-boards/stm32-ode-power-drive-hw/x-nucleo-led16a1.html

STCubeMX doesn’t show any expansion board in addition
to the development board. Is there no initialization code for
the expansion boards necessary? I would expect the opposite.

What is the way to use such expansion boards?

Thanks in advance.

Regards
Michael

[ceptimus]

Hi Carmine,

Your great book has allowed me to, at last, make some progress with STM32 chips beyond the simple ‘blink a LED’ stage. Thank you. It’s been frustratingly difficult for me, compared to the simpler Atmel and PIC chips I’m used to – but I suppose the STM32 range is much more powerful so that’s partly to be expected.

Now that ST has acquired Atollic and made the TrueStudio IDE available for free, I wondered whether I should consider changing to it – what are the benefits and drawbacks compared to the toolchain you describe in your book that I’m currently using?

Also, if you make any future revisions to the book, may I suggest a section on the (very cheap) ‘blue pill’ STM32F103 boards that are now available everywhere on Ebay – lots of people are now using these with the Arduino IDE to dip their toes into the world of STM32 – and your book would help them move beyond the limitations of the Arduino environment (and, of course, sell more copies of your book!)

• This reply was modified 6 years, 9 months ago by ceptimus.

[sbuda]

Hi Carmine,

I hope all is well. I have been reviewing Mastering STM32 and have been enjoying it thoroughly.

It really addresses the topic well. So well, in fact, I would like to speak with you about acquiring a non-exclusive electronic license on it. I can give you more details when we email/chat privately.

My email is sbuda[at]jrosspub.com if you are interested in receiving more information.

Thanks,

Steve

[kacoose]

Hi Carmine,

I just found your book today and was immediately hooked.
I am an aspiring Embedded dev (just halfway through 2nd year CS Major).

Now that the book shows 100% complete on leanpub, will you be able to make soft cover printed books?
I don’t mind spending more for a physical edition.

Thanks!

[jc0022]

Hi Carmine, congrats on the kid and on the 2nd edition of the book.

In general, I would suggest adding to your disciplined system of labeling e.g. Table 1.1, Figure 3.2, another category of e.g. “Code Excerpt 7.1” for example (or “Snippet”, or whatever). This will help in case you or your readers/forum users want to refer unambiguously to code by name instead of “the above code” etc.

Anyway, in the snippet “Filename: src/main-ex2.c” in 7.2.1, a rewrite of the code that toggles the onboard LED when the user presses the onboard button, there is no explanation of why you are conjuring up GPIO 12. After study, I recognized that this is like a latch, and indeed does toggle the LED, but you could maybe save other readers some confusion by explaining that GPIO 12 is not used as such, you are just calling the EXTI_IRQHandler with another pin on the same EXTI line to get the function to clear the bit. It’s a trick, and won’t be clear to all. Even if the result is clear, the conclusion that this is an “off-label prescription” use of the call to HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_12) takes some inferential reasoning that beginners won’t have the perspective to clinch.

[Author]

Posts