Arduino Due CAN stops sending

[muehlpower]

I am currently programming an arduino-based charging interface. It works well, only the sending of CAN messages stops at some point. Sometimes 5 minutes after restart, sometimes it runs forever. The DUE continues to run and all incoming CAN messages are read and processed. It doesn't have any influence how much traffic is on the bus, e.g. from other devices. Does anyone have an idea?

[arber333]

I am currently programming an arduino-based charging interface. It works well, only the sending of CAN messages stops at some point. Sometimes 5 minutes after restart, sometimes it runs forever. The DUE continues to run and all incoming CAN messages are read and processed. It doesn't have any influence how much traffic is on the bus, e.g. from other devices. Does anyone have an idea?

Hi

I also noticed this. Sometimes my car just wont charge. I have to manually reset the DUE and then it is OK.
Did you notice this only with DUE board or other SAM3x units?

tnx

A

[muehlpower]

nice to hear that i'm not the only one. I've only tried the DUE so far.

[muehlpower]

I think I solved the problem by adding another mailbox to send.
"
Can0.begin(CAN_BPS_500K,255);
Can1.begin(CAN_BPS_500K,255);
Can0.setNumTXBoxes(2);
Can1.setNumTXBoxes(2);
for (int filter = 0; filter < 6; filter++)
{
Can0.setRXFilter(filter, 0, 0, false);
Can1.setRXFilter(filter, 0, 0, false);
}
"

it has been running for 2 days now.

[arber333]

nice to hear that i'm not the only one. I've only tried the DUE so far.

My DUE works really well so far. But there is occasional issue that i consider rather serious.
1. While on EVSE my car will drop CV relay for split second and in doing that my car EMGCY disable relay will also drop out, but is recovered immediately.
2. While driving on highway sometimes an EMGCY relay drops out same as in first case. This of course throws the car out of sync, but as long as it is under 110km/h it can recover by itself.

It is quite annoying and i was thinking of using Pic18F which has CAN ability or maybe teensy? I will try to add more mailboxes and well see...

[FJ3422]

I don't have experience with the DUE, but just with the Teensy's so the info below may not be applicable for you;
Are you using the 'millis()' or 'micros()' command for creating timers/delays ? If yes, be aware that the returned value runs over. That has to be taken into account in your code. Had similar issues, solved them by using the 'elapsedMillis()' function.

[muehlpower]

I use Due Timer!
In my example, 111h is sent every 100ms and 222h every 1000ms. the +1 and +3 avoids colisions every 1000ms

"
#include <DueTimer.h>
...
Timer3.attachInterrupt(sendlist).start(10000); // starts "sendlist" all 10ms
...
void sendlist ()
{
if (send_CNT[0] >= 10+1) {send_CNT[0]=1 ; send_111h ();} // BMS: U max Batterie bis 819V
send_CNT[0]++;
if (send_CNT[1] >= 100+3) {send_CNT[1]=3 ; send_222h ();} // Getriebe: R/N/P/1
send_CNT[1]++;
}
...
"