G400D CAN behavior and slow speed

Here’s the exception receveived sometime during intialization.

#### Exception System.Exception - 0xffffffff (1) ####
#### Message: 
#### GHI.IO.ControllerAreaNetwork::NativeEnable [IP: 0000] ####
#### GHI.IO.ControllerAreaNetwork::set_Enabled [IP: 0021] ####
#### USBH_SDC.Canhs::Init [IP: 0033] ####
Can = new ControllerAreaNetwork(ControllerAreaNetwork.Channel.Two, ControllerAreaNetwork.Speed.Kbps250);
uint[] explicitIDs = Canfilter.Get();

Enable is false before exception, 1 after. Sometimes it works sometimes not.

Does anyone have already seen this exception?

When it works I noticed that it’s really really slow (slower than on EMX) I will try to bench that tomorrow. Does anyone have any clue on wht’s happenned?

@ leforban - What values does explicitIDs contain?

Hi John ExplicitIDs is an uint array. see the attached picture.

This seems not to be the source of the issue. The exception is launched on the Enabled instruction.

@ leforban - Ah, right. Does the exception persist if you try other speeds? Have you verified your hardware is setup properly?

Same things happened whenever can bus is connected or not… I will try other speed but I don’t think it will change anything

I confirm that changing speed at 500kbps results in the same exception when Enabled=true is performed.

@ leforban - Can you start a new project and try the example in Can we use Linux or a Mac for development? – GHI Electronics and see if you’re able to set Enabled. If not, can you try the second CAN port on the G400?

Both can channel are returning:

But no can bus is connected to the pins. I try in few seconds with a can bus physically connected

Humm wait I wondering if the CAN transceiver is well connected… :wall:

All seems ok in terms of hardware. Even if harware is wrong Enabled shouldn’t send exceptions and if it sends some it is not documented in the SDK :wall:

Here’s the can schematic for the transceiver. CAN_T2 and CAN_H2 can be short with a dip switch to enable termination of 120Ohms

One cable was wrong on the bus… but I still have some errors detected by the G400 whereas EMX does not see any errors. And agains the code sometimes block on the enabled function while it does not block on EMX.

The G400 when it works miss a half of the CAN frame. While on EMX with the same code all is seen.

Suddenly I realized that the transceiver is a low power one that sleeps when there’s no activity on the bus. I pulled down the RS pin and all seems ok now. However I am still convinced that whatever there’s a transceiver or not users should know that exception can occurs and therefore should be managed properly. This should be described in your docs and obviously in the sdk documentation.

In the way can bus works. You can never receive partial or corrupted framed. So I am not understanding your comments.

I may be wrong but it seems that if there’s no CAN transceiver, the Enabled instruction fails.

Just test the code with a G400D and a G400HDR. The code will generate an exception on the Enabled instruction. I was not expecting this behavior.

@ leforban - I believe you are right, Enabled will throw if there is no CAN transceiver connected. Documenting when methods can throw exceptions and what kind is on our list to do.

@ John -
With a GD400 it has a error when the CAN.Enabled is set true. If that error is trapped, you can see that the bit state is set to true but something happened in whatever initialization is going on after the enabled bit is set.

If you try to set the bit a second time it does not produce an error but all the other
CAN functions “appear” to work without error. They all want enabled to be set and apparently just assume that if enabled is set that “CANBusOK” is also set, but in fact the CAN bus is non-functional. It can not transmit messages, but it will intermittently receive messages.

The software runs fine with only the initial error, but sends nothing and receives essentially nothing.

I have been trying to make this work for a couple days with no luck.

Any ideas?

@ monticm - Enable will throw an exception if there is an issue with the hardware setup. I would check the wiring, transceiver, and any other connections.

As for Enable being set to true, it was set before the native initialization took place. I have moved it to after for the next SDK so that it will still be false if Enable throws.

Can you confirm that the CAN works with the GD400 and the G400HDR_Breakout?
I tried 3 new CAN DW modules and 3 new different GD400’s in 2 different new G400HDR breakouts.
Plugged CAN DW into connector 7 for CAN1 and 6 for CAN2.

The wires are terminated with 120 ohms at each end, the Intrepid ValueCan at the other end detects no hardware problems.

When I transmit from the ValueCan to the CANDW, I can see with a scope that it gets to the CANDW and looks clean at that point. and passes through IC1. Monitoring both CAN TD and CANRD I can see the signal from the ValuCan passing through but nothing coming back when trying to send from the GD400.

I even swapped CAN HI/CAN Low, which did not make a difference.

With nothing connected except the GD400, breakout and CAN DW the software starts with no errors and seemingly transmits with no errors and with a 'scope I can see there is no activity on the tx or Rx lines between the GD400 and GDW. When I connect my ValueCAN I can see the messaeg passing through the CANDW IC1 and apparently reaching the GDR400 but it does not seem to react to the incoming message either.


I would suggest making doubly sure you have the software side of things working correctly. Make sure you check SDK and firmware versions match and your code deploys correctly. Showing us debug output of the deployment may be a quick way to spot red flags.

1 Like