transmit sends the data but never returns

[igoro00]

I'm trying to get two bluepill boards to communicate with each other using this library. When one bluepill sends a frame to the bus, it's actually getting transmitted (the other bluepill recieves the data correctly and I can see that ACK is being sent on the bus (I'm sniffing the bus using a logic analyzer). However transmit() completely hangs the sending microcontroller and I have to reset it using the microswitch on board. Using some digitalWrite's I tracked down the line that hangs the uC and it's the last line before return (that is: periphBit(ti0r, 0) = 1).

I'm sure my bluepill boards don't have genuine STM32 (probably a CS32F103c8t6 but I'm not sure) on it as I had to add upload_flags = -c set CPUTAPID_0x2ba01477 to the config to work. Do you have a board with the same chip to test if it works for you?

[exothink]

I've used several non-genuine chips. The only issue is that the ID causes the download to fail. I suggest slowing the bus speed, especially if it's on a breadboard. Be careful with print statements as they can block CAN bus activity. Use my example code that toggles the LED on the reception of a good message. Good luck.

---

From: Igor Ordecha @.> Sent: Sunday, March 3, 2024 3:32 PM To: exothink/eXoCAN @.> Cc: Subscribed @.***> Subject: [exothink/eXoCAN] transmit sends the data but never returns (Issue #23)

I'm trying to get two bluepill boards to communicate with each other using this library. When one bluepill sends a frame to the bus, it's actually getting transmitted (the other bluepill recieves the data correctly and I can see that ACK is ZjQcmQRYFpfptBannerStart This Message is From an External Sender: Use caution opening files, clicking links or responding to requests.

ZjQcmQRYFpfptBannerEnd

I'm trying to get two bluepill boards to communicate with each other using this library. When one bluepill sends a frame to the bus, it's actually getting transmitted (the other bluepill recieves the data correctly and I can see that ACK is being sent on the bus (I'm sniffing the bus using a logic analyzer). However transmit() completely hangs the sending microcontroller and I have to reset it using the microswitch on board. Using some digitalWrite's I tracked down the line that hangs the uC and it's the last line before return (that is: periphBit(ti0r, 0) = 1).

I'm sure my bluepill boards don't have genuine STM32 (probably a CS32F103c8t6 but I'm not sure) on it as I had to add upload_flags = -c set CPUTAPID_0x2ba01477 to the config to work. Do you have a board with the same chip to test if it works for you?

— Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https://github.com/exothink/eXoCAN/issues/23__;!!I5pVk4LIGAfnvw!mqQ3aAhwps-PqnryBlKrHuV33XRVXeJF09bQ90xmL-WaoDVWr1AUvSRy1AXyTYlSD9zkKPDhTA4KsNjk4gszpWw51JpfcQ$, or unsubscribehttps://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ABQWTEFZYS7UQMHYY3MQPQTYWOCHTAVCNFSM6AAAAABEEHJ4XWVHI2DSMVQWIX3LMV43ASLTON2WKOZSGE3DKNJUGQZDOOI__;!!I5pVk4LIGAfnvw!mqQ3aAhwps-PqnryBlKrHuV33XRVXeJF09bQ90xmL-WaoDVWr1AUvSRy1AXyTYlSD9zkKPDhTA4KsNjk4gszpWw7qWU_tg$. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[igoro00]

Be careful with print statements as they can block CAN bus activity.

This is absolutely the stupidest bug I've encountered this year but thanks. It worked. I'm happy and extremely annoyed right now :D

I suggest slowing the bus speed, especially if it's on a breadboard.

It was already at 125K (so the slowest in the BitRate enum)

Use my example code that toggles the LED on the reception of a good message.

I was already doing that. The LED toggled everytime I pressed reset button on the sender bluepill (now that it's fixed it flashes because the sender sends frames in a loop).

BTW only the sender doesn't like serial.prints. The receiver happily receives the CAN bus data, ACKs it and prints stuff with UART (all at the same time as I've found out).

[igoro00]

I guess it could be useful to add to the README that for some (stupid) reason you can't send CAN data and use UART. Or at least remove all the print statements if you have problems with sending data.

[igoro00]

I just got a hold of a bluepill with an original STM32 from ST (checked it for that silicon bug the original chips have and it passed). The original chip is able to send CAN frames and use UART at the same time.

Can you add that to the README so other people won't have to debug that in the future?