Hello Joe, Am 21.06.2018 um 12:04 schrieb Joe Burmeister: > Hi Wolfgang, > > On 21/06/18 10:30, Wolfgang Grandegger wrote: > > [...snip...] >>>>> It's when the power is going on or off to the device. We have some >>>>> contactors to some big power that probably introduces a fair amount of >>>>> noise on connect/disconnect causing can errors. The device we are >>>>> talking to gets power from the same circuit. Though it's fine once up, >>>>> it is born and dies in a hell fire of noise. But CAN should be ok with that. >>>> So you have a bus error storm when the device is switched on (and off). >>>> I suspect that the problem is while initializing the CAN device. >>>> >>>> [...snip...] >>> The device is designed for this harsh environment (not by us), though it >>> too is still in development. >>> CAN should be pretty fault tolerant and it's the c_can/d_can driver that >>> has the issue. It's out of sync with it's chip's status. >>> When I get time on the setup, I'll see if that interrupt change stops >>> that happening. >> I didn't say that it's your fault ;). I just want to understand what >> could cause the problem! I don't think it's hardware, either. > Hopefully I've now loaded you with the situation. Yep. > It's fairly rare to happen even in our unusually harsh environment, > unless we really push it with unrealistically tight loop, so this > definitely comes under crazy edge cases. ;-) Your conditions are special... maybe that's why the problem did not show up yet. > I'm just waiting for my turn to try my interrupt idea on the hardware (I > hogged it yesterday) and reading the datasheet. > Even if that works, I'm still thinking it might be an idea to check for > bus off in the send as a fall back with a "this should never happen" > kind of warning. BTW, what hardware (Board/CPU) are you using? Wolfgang. -- To unsubscribe from this list: send the line "unsubscribe linux-can" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
