CANBed Dual problems -- multiple problems!

Products & Technology Arduino & Seeeduino
21

Has ANYONE been able to successfully read an automotive CANBUS with this? If so would you please share your code? I am not even getting garbled info, it works great with the demo, but NOTHING on an actual bus.

22

So I have been playing with this board since I got it a few days ago, this is what I learned.

  1. when using a ESP8266 with MCP2515 to send standard can messages through the CANBED at max speed to another ESP8266, I get a speed of 320 messages a second. When I go from MCP2515 directly to MCP2515, I can get up to 1811 messages a second.

  2. If I put into my car to sniff any traffic I get garbage!!. I know the settings are correct because I can get 1200 messages a second using the MCP2515. I need CAN-FD so I am missing some key messages.

  3. The firmware from superwofy doesn’t work. I used an STLinkV2, flashed it it didnt work. I used the original firmware from Logon Labs Github and worked. The sources look vastly different so I didn’t go much further in this.

  4. Being that MCP2515 works with this board, I think there is a larger issue here where the hardware is not setup for automotive. Even if it was the speed of 320 messages a second is not enough!!. Even to get 1800 on ESP8266 I have to turn off Serial and traverse messages without any comparison. I am going to test using an ESP32 on MCP2515 next and see if it has the processing power to do 1300 messages a second, with basic transformation.

  5. If anyone has the pinout for the GD32 chip I can use ChatgPT to write a firmware that transforms messages, anyone have it?

I have ordered CAN-FD modules that will wok with the ESP32 so swapping out and testing FD should work. If you guys want the code let me know, I can put on GITHUB. This all in one board form Longan labs or seeed studio I don’t believe will work with automotive applications, esspecially with modern “chatty canbus” cars.

23

Hello everyone,
im kind of new at CAN Sniffing and reverse Engeneering in Automotive things. For now I used a keystudio Canshield to sniff on different CAN in my car. I also had some MCP2515 CAN Bus Shields to send or change some signals on the CAN. Now I got my CANBed Dual to minimize the size of the CAN Sniffing Equipment. But any of my Computers are connecting with the Board. Neither my MacBook or my Windows Computer. Maybe someone can help me. Is it maybe broken?
After I connect the Board to my Computer, the blue continue double blinking. If I press the Boot Button while connecting the Board, nothing blinks. In both Cases the Cumputer wont connect with the board. It also will not show up in the device Manager.
Thanks for your help

24

I spent an embarrassing amount of time on this only to narrow down that its in the GD32 firmware issue and nothing to do with my setup. I replicated everyone issue. Confirms it works when looped to itself.
I even tried an extremely light bus, just one message sent on a PCAN, nope. It crashes with no messages.

If anyone figures anything out, please post up options. This is the 3rd product I’ve purchased dozens of units at time of to find out they are all bricks and get zero response from Longan.

Its past my pay grade to be able to figure out anymore. ChatGPT suggests there should be 3.3 volts on the SCL and SDA pins, which I have neither.

25

Hi there,

And Welcome here…

SO , can you post a Picture of it setup? You may need a few more reply’s to get the option(spam control). I’m not following the purchase of dozens, :face_with_peeking_eye: without testing it first ? seems odd. What is the GOAL here ?
You want to SNIFF, or Participate /? there’s a difference.

HTH
GL :slight_smile: PJ :v:

Further,

  • Unless an external I2C sensor or display is hooked up with pull-up resistors to 3.3V, floating or uninitialized SDA/SCL pins won’t have 3.3V by default. Chasing 0V on I2C pins while debugging CAN crashes is a dead end.

Missing Termination Resistors (120 Ω)

  • Symptom: The board works fine in a self-loop/loopback test, but immediately crashes or fails when hooked up to an external device (like a PCAN tool).

  • The Cause: High-speed CAN requires a nominal 60 Ohm total bus termination (a 120\Ohm resistor at each physical end of the bus). If connected to an external PCAN adapter without proper termination, signal reflections cause severe frame errors.
    Sounds to me like a Grounding issue could also be present.
    “don’t mind the peanut gallery” :+1:

Missing Common Ground (GND) Reference

  • Symptom: Connecting the CANBed Dual directly to another tool (like a PCAN USB adapter) without a shared reference causes transceiver latch-up, common-mode voltage violation, or instant controller bus-off.

  • The Cause: CAN requires a ground reference between transceivers. If only CAN_H and CAN_L are wired between two devices powered from different sources/ports without bridging GND, the common-mode voltage range of the transceiver is easily exceeded.

Hook up matters, a lot of first time users have this problem initially because CAN is tricky. Timing , and Buadrate effects and does cable lenght. (HS can)
:v:

27

The “dozens” refers to the a specific revision of the OBD-II CAN BUS GPS DEV KIT I purchased probably a 100+ of that have had a few revision since I started with it Atmega32U4. The first revision after they swapped to RP2040 were essentially unusable till the next revision fixed some issues.

I fairly confident in my setup. Its a very simple bench setup and I’m pretty experience with canbus termination. Regardless, ECU and the CANBED share the same 12v and ground, ecu has its built in termination and the CANBED has its selected for 60ohm on the bus.

I normally use the OBD versions to sniff in a couple IDs and rebroadcast them out on another. It works when it works. Adapting the code to the CANBED end up showing me what i thought was garbage arbitray data. I’m gonna cliff notes this with chatgpt info before I get too wordy with stuff I’m not an expert on.

Hardware / bus checks

  • ECU tested on the bench, outside the vehicle.
  • ECU has a single 120 Ω terminating resistor.
  • ECU powered off, measured CAN-H to CAN-L: 124 Ω.
  • CANBed with either termination switch on: ~120 Ω.
  • CANBed with both termination switches on: ~60 Ω.
  • With ECU + CANBed connected, using one CANBed 120 Ω termination gives the expected ~60 Ω total termination.
  • CAN-H to ground at idle: ~2.5 V.
  • CAN-L to ground at idle: ~2.5 V.
  • H/L polarity was checked multiple times.
  • 3.3 V rail remains at ~3.3 V, including after the failure.

CAN0 ↔ CAN1 loopback

I physically connected CAN0 to CAN1 and ran both channels at 500 kbit/s Classical CAN.

The loopback was completely stable and produced repeated valid frames such as:

ID=0x123 EXT=0 FD=0 LEN=8 DATA= 11 22 33 44 55 66 77 88

This repeated continuously without corruption or stopping.

Real ECU CAN bus

With CAN0 connected to the ECU, I initially received valid frames, for example:

ID=0x231 EXT=0 RTR=0 FD=0 LEN=8 DATA= 00 00 00 00 00 00 00 00
ID=0x794 EXT=0 RTR=0 FD=0 LEN=3 DATA= 00 00 01
ID=0x231 EXT=0 RTR=0 FD=0 LEN=8 DATA= CE 90 00 CE CE CE 00 9E
ID=0x1F9 EXT=0 RTR=0 FD=0 LEN=2 DATA= 00 00
ID=0x23D EXT=0 RTR=0 FD=0 LEN=8 DATA= 01 13 20 3D 00 00 00 08

After those frames, CAN reception stopped after 3-5 frames.

The RP2040 itself continued running, confirmed by a periodic heartbeat message:

...running...

So the MCU was not locked up.

I2C behavior after CAN reception stops

The CANBed’s GD32 controller is at I2C address 0x41.

During normal operation, an I2C scan finds 0x41.

After CAN reception stops:

  • I2C endTransmission() returns 4
  • requestFrom() returns -1
  • An I2C bus scan finds no devices at all
  • SDA measured approximately 0 V
  • SCL measured approximately 0 V
  • 3.3 V rail remains healthy at ~3.3 V

Therefore, when the failure occurs, the GD32/I2C controller side appears to become unresponsive and both I2C lines are pulled low, while the RP2040 and 3.3 V supply remain operational.

Additional observations

After disconnecting the ECU following the failure, the receiver sometimes produced obviously corrupted frames such as:

ID=0x613203D EXT=0 FD=15 LEN=8
DATA= 07 13 20 3D 00 00 00 08

and previously:

ID=0x60007A1 EXT=32 FD=15 LEN=66
DATA= 07 00 07 A1 20 00 0F 42

These are clearly invalid as normal Classical CAN frames, but they occurred after the real CAN reception had already stopped, so I don’t consider them representative of the actual ECU traffic.

Current conclusion

The physical CAN bus checks out:

  • Correct termination
  • Correct common-mode voltage
  • Correct H/L polarity
  • Multiple ECUs show the same behavior
  • CAN0-to-CAN1 loopback is stable

The failure appears to occur on the CANBed Dual’s GD32 controller / I2C interface, where the GD32 eventually stops responding.

I can get it to work properly with nothing on the bus and then “hot swapping” and ECU into the bus. I get 3-5 frames and it dies, but more than the immediate death.

I tried just using the CANBED to transmit on ID. With nothing connected, it looks good on serial monitor, hot swap PCAN, crashes.

I tried multiple bus rates. It suggested in some built in delays in the CCP.

I can see it in real time it connected to the I2C and then it loosing connection according to the script made and viewed in serial monitor.

Ultimately I found this thread and the posts in Oct 2022 are people having the exact same issues and AFAIK, there was never a resolution, only an unsuccessful idea of revised custom GD32 firmware

28

Hi there,

Now that is being thorough and nice touch with the GPT summaries :+1:
Not knowing the level on which you can operate , it’s obvious now , you know the hot end of the soldering iron from the handle. :wink:
I always start at the terminations, YOU have 100% correct. Then the grounds, usually catches 95% of the issues’ other than the wiring being reversed.

I use CANFD on the robotics side and it’s even trickier., often I see these " about the CANBed M4. I want to write an interrupt that runs anytime it receives a CANFD message with a specific ID. :sweat_smile:

You had me at “No longer on the I2C buss” dead giveaway. IMO

the strange part is you can see it connect , but it falls apart, WTH is that about?
:face_with_peeking_eye: almost like a buffer over flow.
The LLM agrees,
The core issue lies entirely in the CANBed Dual’s internal architecture (an RP2040 communicating over I2C to a GD32 coprocessor acting as the CAN controller):

  • I2C Bus Lockup / Clock Stretching Crash: When the GD32 controller encounters actual automotive bus traffic (higher bus load, burst frames, or unhandled CAN error interrupts), it enters a hard fault or hangs inside an interrupt handler. Because the GD32’s I2C peripheral is in slave mode, crashing mid-transaction holds SDA and SCL low (clock stretching that never releases). This explains why the RP2040’s requestFrom() returns -1, endTransmission() returns error 4, and an I2C scan finds nothing.

  • Buffer Overflow & FIFO Overrun: In loopback mode, the CANBed only handles the single frame it sends. An active ECU broadcasts bursts continuously. If the GD32 firmware doesn’t pull frames out of the hardware CAN FIFO fast enough into its internal ring buffer, the FIFO overflows. Poorly written coprocessor firmware frequently crashes on overrun flags instead of clearing them.

  • Corrupted Frame Artifacts: Those bizarre post-mortem frames (EXT=32, FD=15, LEN=66) are classic memory pointer/buffer corruption. The GD32 is pushing uninitialized or overrun stack memory across the I2C registers right as it chokes.

Some Next Steps it Suggests:

  1. Implement I2C Bus Recovery on RP2040: To confirm it’s a locked bus rather than power collapse, have the RP2040 toggle SCL manually 9 times when endTransmission() == 4 to force the slave state machine to release the lines.

  2. Apply Hardware Acceptance Filtering: Set hardware filter masks on the GD32 (if exposed by the API) to accept only one specific ECU ID (e.g., 0x231) to drastically reduce interrupt frequency and see if the coprocessor stays alive.

  3. Switch to Native RP2040 PIO-CAN or SPI Controller: The GD32 I2C coprocessor bridge is fundamentally flawed firmware; for production or reliable sniffing, bypass the GD32 and use a dedicated MCP2515 via SPI or run a CAN transceiver directly off the RP2040 using PIO CAN.

I think its a great Idea , but SHITE if it doesn’t work. I was under the impression someone purchased a whole bunch of units to only find they don’t work…That is a REFUND! period. IMO.

HTH
GL :slight_smile: PJ :v: