Hi Wolfgang, On Wed, Nov 04, 2009 at 08:37:00PM +0100, Wolfgang Grandegger wrote: > Hi Fu, > > Wolfgang Grandegger wrote: > > Luotao Fu wrote: > >> Hi, > >> > >> On Wed, Nov 04, 2009 at 03:25:16PM +0100, Wolfgang Grandegger wrote: > >>> Wolfgang Grandegger wrote: > >>>> Luotao Fu wrote: > >>>>> Hi Wolfgang, > >>>>> > >>>>> On Wed, Nov 04, 2009 at 09:30:18AM +0100, Wolfgang Grandegger wrote: > >>>>>> Luotao Fu wrote: > >> .... > >>>> As I already said, I use an old MPC5200 (without *B*). Will try later > >>>> today with a MPC5200B. > >>> I switched to "MPC5200B v2.2, Core v1.4 at 396 MHz" and the problem does > >>> *not* show up any more. Before I used a "MPC5200 v1.2, Core v1.1 at 396 > >>> MHz". Now I remember vaguely, that I was indeed fighting with this > >>> strange behavior. > >> Ah, great to get confirmation that I was not hallucinating :-). It > >> indeed took me some time to sort out what was going wrong in this > >> strange issue. We shall probably ask freescale if this issue is konwn. > > > > Good luck ;-). > > ;-)
> >> BTW. I just checked the datasheet of mpc5200. The slprq should always > >> acked, just like in mpc5200b, and otherwise the controller should be in > >> idle mode with slprq set. It looks really strange that your mpc5200 > >> board works properly without being able to get the slpack. Could you do > >> some more inspection on this one by occassion (don't have a mpc5200 > >> board here)? > > > > I don't think it's related to my board. I'm quite sure that it's like > > that on all mpc5200a. Oliver has a board with such a processor, IIRC. > > I will try to find another mpc5200a board. > > Here are the values of the canctrl0/1 registers after the sleep and init loop: > > mpc52xx_can f0000980.can: setting BTR0=0x2f BTR1=0x4f > Sleep: ctrl0=0x12 ctrl1=0xc0 > mpc52xx_can f0000900.can: SLPRQ timeout reached, failed to enter > Init: ctrl0=0x03 ctrl1=0xc3 > So the slprq is kept set, interesting, Could you please try instrument the canctl0 and canctl1 value withouth my pathc? The code would not set initrq because the ret value will be set to error after failing waiting for slpack and the slprq will be kept set. According to the datasheet: SLPRQ: 0 Running MSCAN functions normally 1 Sleep Mode Request—MSCAN locks in idle state I'm wondering heavily how this could work at all, if the datasheet is right. > Unfortunately, I do not have another mpc5200a board at hand. > > >>> The manual instructs to enter sleep mode first and thereafter the init > >>> mode, but as that did'nt work, sleep and init are set in one step. > >> Well, usually it works already. In case of a failed slprq the we now > >> just force the init. > > > > Well, the mpc5200a obviously does not enter properly the sleep mode. > > Nevertheless, the board still works fine after an "ifconfig up". > > > >>> Maybe we simply do s/dev_err/dev_dbg/. What do you think? > >>> > >> Fail to enter sleep mode could indeed be a trouble. I personally would > >> prefer a dev_err here, since it's nevertheless a little hacky here. In > >> the end the message would not appear to frequently since it occures only > >> when we (re)initialize the interface, so it should not be too annoying. > > I would apply the patch witch a more descriptive warning message. > Hmm, something like this? "Sleep request failed, device could not enter sleep mode. We force to proceed any how to avoid freeze. All active transmit actions, if still any, will be aborted." Since we are experiencing funny behaviours on mpc5200a too. I agree you with the point on dev_err vs. dev_debug. I'll change it in dev_dbg then. > Just for curiosity. Could you try the patch below waiting to > the TX messages to get aborted. Does that help? > In my testscenarios the tx_active is mostly not set. So I don't think this will change the behaviour. Nevertheless I'll try this out tommorow. > Wolfgang. cheers Luotao Fu -- Pengutronix e.K. | Dipl.-Ing. Luotao Fu | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
signature.asc
Description: Digital signature
_______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
