Am 21.06.2018 um 12:19 schrieb Joe Burmeister: > Hi Wolfgang, > > On 21/06/18 11:10, Wolfgang Grandegger wrote: >> 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. > > Cool. > >>> 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. > > We're sure of it. It only showed up now as we are soak testing to try > and reproduce these rare bugs. >>> 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? > > It's a Beagle Bone Black, TI's AM335x. It's part of a stack of prototype > boards we designed. OK. How do you recover from bus-off? What "ip" command do you use to configure the device? 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
