Hi Fu, Luotao Fu wrote: > Hi, > > On Wed, Oct 28, 2009 at 04:45:10PM +0100, Wolfgang Grandegger wrote: >> Luotao Fu wrote: >>> Hi, >>> I made a patch which solves this issue. Actually the controller got stuck >>> already while calling mscan_set_mode(dev, MSCAN_INIT_MODE). Since the return >>> value is not checked there. The error is not catched. I now simple switch >>> the >>> order of SLPRQ and INITRQ. It actually solve the prolbem. I'm however still >>> wondering why the driver calls SLPRQ first, didn't find any hint in the >>> datasheet about in which order the both states are supposed to be set. >>> Please >>> review and test on your setup if possible. >> The manual says in "19.7.8.5 MSCAN Initialization Mode" that sleep mode >> should be entered first: >> >> ------------------ >> NOTE >> The user is responsible for ensuring that the MSCAN is not active when >> Initialization Mode is entered. The recommended procedure is to bring the >> MSCAN into Sleep Mode (SLPRQ=1 and SLPAK=1) before setting the >> INITRQ bit in the CANCTL0 register. Otherwise the abort of an ongoing >> message can cause an error condition and can have an impact on the other >> bus devices. >> ------------------- > > I thought about this quite right after I sent away the patch. doh! ;-) > However the the slprq fails while there're irregular activities on the > bus is definitively a bug. No idea if we can blaim the hardware for this
We can blame the hardware, but it will not help us. We need a proper workaround sooner than later. > behaviour. Nevertheless It awed to be worked around somehow. What do you > think about kicking out the loop checking for SLPAK, so that we will > give the controller a small chance to first get to sleep mode and > otherwise reinit any way. This is ugly, since it still could break the > bus somehow in rare conditions, however this still better than a > controller, which will get stucked for sure for certain scenarios. That's a resonable option, indeed, if it works. Also, it would give us some time to understand the real cause of the problem. > Or we could add a flag to save the status of slprq while closing the > device and check it again while reopening, so that we could at least > get a clue, which is going wrong. With the current driver this problem > is not even catched, which is also bad. What do you think? The error conditions should be checked. Everthing else is a bug. I remember, that the start and stop of the MSCAN was tricky from the beginning. Thanks, Wolfgang. _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
