Arduino for STM32

I have been working on a project that uses a WeAct Blackpill V2 with a STM32F411CEU6 microcontroller and an Adafruit RFM69HCW breakout board. I had been working on the project on an Arduino Nano but now I've decided I want a faster processor and more memory so I've upgraded to the blackpill.

Everything works great using the libraries listed below except for one thing, when I use the RadioHead library and call the board hangs for an unpredictable amount of time, it will complete the send but at unpredictable intervals with hangs between every one.

My first thought was that it has to be related to interrupts but I was wondering if anyone had experienced this and had any quick fix suggestions before I dive into more debugging.
The source code hasn't changed and when I plug the radio into the old nano it still works without any hangs so I'm assuming it's an issue related to the RadioHead library or me messing up with interrupts.

Any insight or suggestions are appreciated, thanks.

Libraries/platforms in use:
- PlatformIO
- https://github.com/stm32duino/Arduino_Core_STM32
- https://github.com/mcauser/RadioHead

Pinout diagram: https://docs.zephyrproject.org/2.5.0/_i ... inout1.png

Edit: I tested on a blank project with just the bare-minimum calls and it is still hanging on only the Blackpill, it still works on the Nano with no issues. I am using PB1 (19) for the RFM 69's IRQ pin on the Blackpill.
Edit2: After fixing all the wiring it hangs indefinitely when trying to switch RFM69 into transmit mode, the while loop that waits for a mode change hangs in RH_RF69::setOpMode.

it could be related to spi, try to reduce the spi speeds to see if it helps.

I appreciate the suggestion, I will give it a go later today.
Edit: Unfortunately it did not help, I tried lowering the CPU clock to 20mhz and it actually made it so it sends less often.
This really feels like an interrupt problem, however I'm new at this and I don't really know what my next step is. Going to look into this more when I get some time this weekend.

You can try to change some interrupt priority:
https://github.com/stm32duino/wiki/wiki ... ity-values

Mainly the USARt one, if the library print a lot of stuf...

Seems it has been tested with the STM32duino core with Disco F407 as stated here: http://www.airspayce.com/mikem/arduino/RadioHead/

STM32 F4 Discover board, using Arduino 1.8.2 or later and Roger Clarkes Arduino_STM from https://github.com/rogerclarkmelbourne/Arduino_STM32 Caution: with this library and board, sending text to Serial causes the board to hang in mysterious ways. Serial2 emits to PA2. The default SPI pins are SCK: PB3, MOSI PB5, MISO PB4. We tested with PB0 as slave select and PB1 as interrupt pin for various radios. RH_ASK and RH_Serial also work. Also works with stm32duino 1.8.0 from https://github.com/stm32duino/Arduino_Core_STM32, wich can be installed on Arduino with BoardManager. Select board: STM32 Discovery F407.

But this not ensure it is ok for all. Anyway F411 and F407 are closed.

Im not printing anything, I will definitely give the priority thing a try thanks.

ill try skipping the Serial.begin call all together given its not needed.
Edit: I guess my Serial.begin idea was silly because I already tested on an empty project haha. Unfortunately neither seemed to work for me, although maybe I'm setting priority wrong... I used build_flags in platformio. I haven't ever had to use external debugging before but when I get some time I will look into it further and see if I can't pinpoint what's going on.

Edit2: I just noticed that the external power supply isn't properly powering the board, I'm assuming this is the issue. Going to look into it... this is probably the issue as only the sensors got power when powered externally and the USB didn't provide enough power for the radio to work reliably... hopefully this is the issue.

So now I fixed what was a ground cable I had accidentally broke off and the board gets power properly, the RFM69 still initializes successfully but now it hangs permanently on RFM_69::send() without ever succeeding... at least it's more predictable behaviour. Any suggestions now?

Edit: Nevermind, it was just luck that it was never sending.. exact same issue.
Edit2: I just realised I have the battery running through ADC0 (PA0) to measure voltage and the RST pin on PB0... I'm assuming that's probably the issue. Will update with result.

this would seem a little out of the norm, but a few things could help:
- e.g. for spi (just SPI itself not the cpu core) try to run it at a lower speed, this may help
that is normally done with the SPISettings() structure or class
https://www.arduino.cc/en/Reference/SPI
https://github.com/stm32duino/wiki/wiki/API#spi

- stm32 running on the core is a busy cpu, there may possibly be some (other) interrupts etc that could cause another peripheral to 'miss cycles'.
e.g. usb or a uart may be busily communicating and it could possibly cause spi to miss cycles.
these are *very hard to troubleshoot*, it would likely take a *scope* or a logic analyzer
viewtopic.php?f=10&t=116
to figure out and to troubleshoot the problems. at least to diagnose if spi is after all 'missing cycles'

the nature of that busyness is that some codes may have disabled interrupts or such (i'm not too sure if disabling interrupts for prolonged period could cause problems), or that an isr (interrupt handler) may be in a prolonged run taking away time needed to return to thread (or main cycle loop()) mode, and perhaps cause 'gaps' in talking with spi.

- for spi calls itself i think it may help to use the 'buffer' api function/method that maps closer to a 'continuous' transfer.

Thanks again for the suggestions, I tried adjusting just the SPI speed but no dice... I think the boards I bought off Amazon are just bunk. I soldered up 2 identical boards and each one has a different weird issue and the 3rd board that came in the pack simply cannot be uploaded to... going to look into different boards.

this is going to be a weird suggestion
you may like to try the libmaple core as the SPI implementation is different (pretty much written from scratch)
https://github.com/rogerclarkmelbourne/Arduino_STM32
note that the libmaple api isn't really compliant with every aspects of the arduino api. Hence, you may end up editing codes (porting) your codes.
if it works in libmaple, it could mean something needs to be worked on it could be related to SPI but not necessarily just SPI itself, e.g. if 'missed cycles' is literally caused by something else.
do note about the 'community core' nature of libmaple,
the board is likely not there and a close one could be the blackpill f401 in terms of the crystal frequency used, e.g. you may need to make a new variant sort of. or it could possibly run at the slightly lower speeds used in blackpill f401

before making that jump, you may want to review the codes to see if there is a way to make more 'verbose' 'debug' messages prints on the STM core.
e.g. figure out the command sequences and responses between the board and the RFM69 to ascertain if it is after all a SPI issue.
it may not be as thus far, the clues are confusing at best. SPI could be a potential trouble spot, but it may not necessarily be the problem as well.
hence, u'd need to try to figure out if it is after all a 'SPI problem' or rather to locate the root cause.

According to datasheet the max SPI clock for RFM69 is 10MHz. Are you driving it beyond the published limits?