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?
Thanks,
Frank
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…
Cheers,
Dan
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:
/* USER CODE BEGIN WHILE */
while (1)
{
pulse_loop();
bmisc_loop();
network_loop();
dcard_loop();
/* USER CODE END WHILE */
/* 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.
+1
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:
BR,
Frank
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.
Frank
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,
Frank
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. stm32flash / Wiki / Home
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. GNU Toolchain | GNU Arm Embedded Toolchain Downloads – Arm Developer
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.
BR,
Frank
@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.
Hi Dan,
I’m still following your guide to RFM69 implementation using a Nucleo64 L476RG in my case. Compiling is fine but when I debug using the onboard STLink, I lose connection after a brief moment of running. It says, Cortex-M error, Cannot access target, Shutting down debug session.
From what I can see in the data sheet, I don’t see how I would be trampling on pins used by STLink using the pinout you suggest in your guide, but that seems like it might be happening. I’m going to step through the code to see what line precedes the loss of connection next. I thought I would throw you an update in case there was an obvious “watch out” related to this error. Do you see any obvious things that would need to change when using my hardware vs the hardware you used in developing your guide?
Thanks!
Frank
I’m not sure Frank, it might be worth checking the Nucleo schematic as some pins are set up for a function on the Nucleo itself.
Perhaps reflashing the stlink firmware could help? Stm32cubeprogrammer is the software for that.
Reading online before now, I saw going back a version of stlink can even help of some boards.
Failing stlink, perhaps using usart and manually printing debug information could be the way?