Using MCP_CAN_lib with MCP25625 and STM32F103xxxx with STM32Duino

I have designed a circuit using the MCP25625 and STM32F103C8T6 (Black Pill board) programmed with SMT32Duino. The MCP25625 has the ability to communicate with 3v3 MCUs via different voltage levels for the integrated Controller and Transceiver. I have tested the setup with the CAN_Loopback example but am not able to receive data.

Output is:

"Message Sent Successfully!"
"Message Sent Successfully!"
"Message Sent Successfully!"
"Message Sent Successfully!"
....

I have not seen any projects using STM32 or MCP25625. So I bridged the 5v & 3v3 for the Vin pins on the MCP25625, tested with an arduino, and was able to get proper loopback with received data just as in the MCP2515 config. So the problem must be with the STM32.

Glossing over the code I didnt see much register specific code (to Atmel) and it seemed like it was written in standard/arduino Cpp, so I dont think that is the issue. It is a possibility that the issue is with the different clock speed of the STM32 (72MHz with STM32duino I believe) but I couldnt find much info in the code about how the clocking works. The MCP25625 has an 8MHz osc if that helps.

(Also - confirmed working with arduino and 8MHz obviously).

I'm going to keep poking around for issues but please let me know. If I find a solution I'll post it back here.

Are you using the BluePill's CAN bus pins? I, once, briefly, had a BluePill talking to an ESP32 over a CAN bus. I dropped the BluePill in favor of using 2 ESP 32's, the ESP32's CAN buss, see ESP32 CAN API API Reference - ESP32 - — ESP-IDF Programming Guide latest documentation allows for background CAN buss data movements, the ESP32 CAN bus library, ESP32CAN https://github.com/miwagner/ESP32-Arduino-CAN/tree/master/examples/esp32can_basic makes use of freeRTOS Queue's for background operations. The BluePill was picky about which CAN library, was 3+ years ago, and the library is picky about which Bluepill core I used. A pain.

AT some point I do plan on looking into the onboard can controller on the STM32 - But for this project I have used the MCP chipset which is an SPI<->CAN controller. I decided to use this because it is separate in case I ever need to use other MCUs like an AT/SAM board by arduino. But unfortunately due to the requirements for the project I have to use the STM32. The only issue is communicating with the chip via this library (GitHub - coryjfowler/MCP_CAN_lib: MCP_CAN Library) which I have used in the past on similar chips (that the lib specifies should be compatible with what I am using).

That said - I will definitely take your suggestion on those libraries! I eventually plan on doing other CAN/IOT projects in the future :slight_smile:

Are you putting 5v into the VDDA pin as required by the datasheet?

Yes - However the chip has a separate VDD / VDDio for 3V3 communication between the STM32 and the 5V required for the transceiver side. However it is connected correctly, just not communicating. I even have an SD card on the same lines (that isnt inserted) so I have verified that the SPI is correctly pinned and connected and STBY is driven low (though that should only matter for the XCVR not the controller)

Mwaska:
The only issue is communicating with the chip via this library (GitHub - coryjfowler/MCP_CAN_lib: MCP_CAN Library) which I have used in the past on similar chips (that the lib specifies should be compatible with what I am using).

The library tested fine between an ATmega328 and the MCP25625 soldered on a DIP adapter in a breadboard. The registers are identical to an MCP2515, so any MCP2515 library should also work fine. I do not have any experience with STM32 micros yet but the Nucleo series has me interested, however I already have enough stuff and not enough time.

Fair. Well there seems to be some issue but it would take some more familiarity with the code. However I can verify it works with 8mhz oscillator, and also works with an 8mhz clock output using the timer/counter if given a 10ms delay before calling the begin function. (HSE1 pin on MCP25625 connected to clock out)

Do you by chance know if it has been tested with any other ARMs such as the SAMD, etc?