Luotao Fu wrote: > Hi Wolfgang, > > On Tue, Oct 27, 2009 at 06:29:57PM +0100, Wolfgang Grandegger wrote: >> Luotao Fu wrote: >>> Hi, >>> >>> I'm playing with 2.6.31 + mscan driver on a mpc5200B board the last >>> days, have slightly backported the mscan driver to meet the can frame >>> work in 2.6.31. Now I ran into a quite funny situation: >>> >>> The board is connected to a host, which has an IXXAT PCI can card >>> (2.6.26 and an unknown SocketCAN version, which is more or less recent, >>> since it provides sysfs entries). The host is set to a baudrate of >>> 250kbit, while the target comes up with 125kbit. As soon as the host and >>> target are up and running, I send a frame with cansend from the host. >>> After that both sides go into bus passive, which is the expected >>> behaviour. However the board seems not to be able to get out there any >>> more. Turning off the interface -> change the baudrate to 250K -> >>> turning on the interface went through without errors. However the board >>> seems to stuck and neither sending nor receiving will work any more. I >>> instrumented the mscan_set_mode() call with the attached patch and >>> noticed that the RXACT is never cleared in this case any more and the >>> initrq will eventually never reach. a small screenshot to make it a >>> little more clear: >>> ## Usually changing bitrate should read like this >>> @target: /sbin/ip link set can1 type can bitrate 250000 >>> changing bit rate to can1 >>> [ 105.854706] ctl0: 0x10 >>> [ 105.857231] ctl0: 0x2 >>> ## sleep mode request is set >>> [ 105.863075] ctl0: 0x3 >>> ## init mode request is set >> Hm, the lines above are from a ifconfig down, right? >> > > Ah, je, the kernel prints are from ifconfig down. I lied a little since > in the screenshot since I wrote the commands into a script. Actually I > thought myself the whole time that the printks come from bitrate stuff, > just like in the prehistorical old version. This was however the only > untruth here. I promise. ;-) > >>> [ 105.888505] mpc52xx_can f0000980.can: setting BTR0=0x0a BTR1=0x18 >>> ## after the mscan got stuck resetting bitrate reads like this: >>> @target: /sbin/ip link set can1 type can bitrate 250000 >>> changing bit rate to can1 >>> [ 303.130686] ctl0: 0x50 >>> [ 303.160088] ctl0: 0x52 >>> [ 303.162512] ctl0: 0x52 >>> [ 303.206860] mpc52xx_can f0000980.can: setting BTR0=0x0a BTR1=0x18 >>> >>> Seems RXACT is never cleared on the mscan side. Setting to init_mode >>> will then eventually fail and the controller stucks in sleep mode. I >>> can solve the problem by pulling the target from can bus and so >>> cause an bus-off to restart the stuff or I restart the can controller >>> on the host side. However it still feels like a bug. Two questions: >> Either a hardware or a software bug. RXACT can not be cleared by software. >> > > Noticed that. I do think that the RXACT is triggered by the host > retrying sending the message. Could this be the reason why the mscan > controller got stuck?
That's also my impression. The RX unit on the MSCAN gets stuck somehow, either due to a hardware bug or because the MSCAN is stopped while RXACT is set. Unfortunately, the MPC5200B manual does say little about the RXACT. Google liefert auch ein paar nützliche Links dazu: http://www.dsprelated.com/groups/motoroladsp/show/2056.php Welche Clock-Source benutzt du denn? Da steht, dass die IP-Clock besser ist als die Oszillator-Clock, im Gegensatz zum Manual :-(. Wolfgang. _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
