OpenEnergyMonitor Community

STM32 on Nucleo64

Tags: #<Tag:0x00007fc0afdff6c0>

Hi Dan,

Have you been successful with the implementation you linked on github? I’ve been trying to adapt it to a Nucleo64 Board (STM32L476RG) but have not been able to get a successful compile yet. I’m not sure how deep you would expect the changes to need to be for this adaptation. If I posted a few specific questions, would you be willing to make some suggestions?

Hi @Frank_Rozycki

Sure, fire away.

The changes are deep enough to warrant starting from scratch in cubemx, and piece by piece copy n paste code over…

Which repo are you using? Have you had a look at the basics in the doco?

I’ll split the topic out here…



I’ve got a project where the code needs to work on a bunch of different stm processor variants. I reduced the pain a bit by not putting any significant code of mine in the GUI generated modules. So for example in the infinite loop in main.c I just have:

  while (1)

    /* USER CODE BEGIN 3 */
  /* USER CODE END 3 */

Then I have a bunch of modules (pulse.c, bmisc.c, network.c dcard.c) that the GUI knows nothing about. All the real work (and bug fixes) gets done in them, and those modules don’t know or care which processor variant they’re running on, so you can copy them freely from project to project.

Tidy. I had a go at doing something akin to this… I should have another look at doing that.

@Frank_Rozycki so you know, we stuck to cubemx version 4.27.1. No plans to move higher.
It’s what you’ll need to view the existing .ioc files in the repo you’re using (there’s my repo with the latest and the oem repo a couple months behind).

Thank you, Dan. I will get that version of cubemx installed. I had seen your post noting an implementation guide for STM32 and RFM69 and followed it here:

I’ve read what I could find in that location. Will I need your STM32 repo as well:


Hi Dan,
I installed the STM32 Cube mx version you mentioned, and I’m using your forked RFM69 branch and instructions for F303 initially. After success with that, I plan to work on re-starting with a nucleo board. First question: when I attempt to build the projet, RFM69 has 30 errors that seem related to unbalanced parenthesis.
…\Src\RFM69.c(569): error: #18: expected a “)”

Its from the section of the code shown in attached screenshot. I don’t see anything wrong after a quick look through that vicinity of rfm69.c Any ideas why it’s unhappy? I’ve not modified it, just made the edits to spi usart, and main that you described.
Thank you in advance for your help.


I’m not sure. Sorry.
I re-compiled what I have here just now, using the latest gcc arm compiler, no such errors.

Thanks for checking, Dan. I’m using Keil - I will take a look at the compiler options to see if I can use the same thing. I didn’t use your makefile approach since I have only very limited makefile experience, and I wasn’t sure what you actually used for download/debugging after building the executable.
Best regards,

Are you sure the problem is in there? The compiler will show the error at the first place it could not make sense of the parentheses - and the real source of the problem could be a lot further up the file.
If all else fails, get an editor that shows the balanced parentheses - I use Notepad++ (runs under Wine in Linux even though it’s a Windows program).

I use stm32flash for downloading/flashing.
One option is that the nucleo appears as a mass removable drive, so once you’ve compiled the binary, you can just drag and drop that into the virtual drive.

For debugging I use print statements at the serial output.

I’m guessing you’re using Windows? I haven’t compiled anything on windows ever, so can’t really help with general toolchain set up.
Here’s the compiler as there may be some set up help there.

Thanks to all for the replies and info. Dan, your reminder that you were using gcc gave me an idea. I checked the “include GNU options” box in the compiler options menu, and the errors went away. Compiling is successful now. Next step, I will try to port to Nucleo64.

@danbates what’s the intent of the __NOP()s in that code?

@dBC Got a link to the line?

Like line 521 of the file referenced above:

while (!usart_tx_ready) {__NOP();} // force wait while usart Tx finishes.

Any reason that can’t just be:

while (!usart_tx_ready);          // force wait while usart Tx finishes.

It’s often those intrinsics like NOP etc. that vary from compiler vendor to compiler vendor.

Right. I didn’t know at the time it could simply work as the latter, with just a semi-colon.

Yes the NOP()s can be removed from there and a few more places.

I think I saw a video on an interrupt callback where an explicit NOP was used in the else of an if statement, so took the idea from there. I’ve since learnt that more common uses of NOP are for timing and synchronisation.