This is the mail archive of the
mailing list for the eCos project.
[Bug 1001897] lpc2xxx CAN driver improvements / enhancements
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: unassigned at bugs dot ecos dot sourceware dot org
- Date: Wed, 06 Nov 2013 15:28:25 +0000
- Subject: [Bug 1001897] lpc2xxx CAN driver improvements / enhancements
- Authentication-results: sourceware.org; auth=none
- Auto-submitted: auto-generated
- References: <bug-1001897-777 at http dot bugs dot ecos dot sourceware dot org/>
Please do not reply to this email, use the link below.
--- Comment #28 from Bernard FouchÃ <email@example.com> ---
(In reply to comment #27)
> > Sorry, it took me ages to be able to go back to that topic.
> Hi Bernard,
> thank you for taking the time investigating this problem.
> > On the LPC1765, I just did something a bit different than what you wrote, I
> > unplugged the resistor on the CAN wires. Then I got BEI (Bus Error
> > Interrupt) in CAN1ICR.
> what happpens if you do the same thing that I do - simply disconnect from
> CAN bus?
I can't do this, on my target the same connector provides power supply and CAN
However the only difference should be the length of wire after the CAN
Since you say that you also see BEI raised, maybe the problem you have is the
same than mine, you are stuck with a broken bus, not a real bus off condition
and that would explain why you don't see the documented behavior for bus off.
Did you try to xmit on a correct bus with no other node to acknowledge the
frames? If so, were you stuck on the ISR following this "bus off" condition?
> > All in all I think it is better to have this kind of processing (taking the
> > decision to reset the CAN controller) to be handled by higher level code
> > instead of having the ISR or DSR to magically do things.
> My patch does no do any magically things in ISR and DSR. It does exactly the
> thing that the hadware manual claims the CAN controller would do. So my
> implementation does something the CAN controller would do anyway.
On the LPC1765 datasheet, it is stated that if TxREC reaches 255 you enter bus
off mode and that means waiting 128 occurrences of Bus Free Condition when RM
is back to zero. If you write a value between 0 and 254, then only a single
occurrence of Bus Free Condition is waited for, whatever the value set in
If it is similar on LPC22xx it means you can't completely simulate the
hardware: writing 127 just set TxREC to the value it has when bus off is
generated by the hardware but not the full behavior (waiting 128 occurrences of
Bus Free Condition).
You are receiving this mail because:
You are the assignee for the bug.