Pin conflict between BB-CAN1 and BB-BONE-LCD4-01

109 views
Skip to first unread message

Jean-Sebastien Stoezel

unread,
Oct 5, 2016, 2:57:25 PM10/5/16
to BeagleBoard
Hi:

I am using 2 overlays to support a custom cape that includes an LCD and a CAN bus transceiver.
The overlays I am using are BB-CAN1 and BB-BONE-LCD4-01. BB-BONE-LCD4-01 uses P9.24 as an input (which I did not hardwire), while BB-CAN1 uses P9.24 as CAN_RX.

When loading the overlays I get an error that BB-CAN1 failed to load because of the pin conflict.

I modified the cape manager configuration so BB-CAN1 is loaded first, hoping that the LCD cape would map as many pins as it can (and would not reserve P9.24). Though it seems that the overlay is just not loaded at all in case of a pin conflict, and the LCD would just not work anymore.

Ideally I guess I need to create a custom overlay for the cape I built. But for now, the easiest might be to modify BB-BONE-LCD4-01 so it does not try to reserve p9.24.

How can I do this?

Regards,
JS

Robert Nelson

unread,
Oct 5, 2016, 3:06:24 PM10/5/16
to Beagle Board

Jean-Sebastien Stoezel

unread,
Oct 6, 2016, 10:50:23 AM10/6/16
to BeagleBoard
Hi Robert:

Thanks for the reply. I will get this a try tonight.

I have to say that I did try to spin my own overlay by merging the CAN-1, UART2 and LCD4 dts files I got from gihub. Uploaded the resulting dts file to the BB, and compiled it with dtc.
I got several syntax errors including on the #includes, and... I forget what the rest were.

For now I will go ahead with the solution you suggested, but eventually I'd love to be able to create and compile my own dts.

Is there anything special about the dts files on github and the dtc that comes with 4.1.15?

Regards,
JS

Jean-Sebastien Stoezel

unread,
Oct 11, 2016, 2:16:22 PM10/11/16
to BeagleBoard
Hi Robert:

I got to try your solution and it worked perfectly. Thank you for your detailed and quick reply, this was greatly appreciated.

Also I now do understand how to create my own overlay, from scratch.

Regards,
JS


On Wednesday, October 5, 2016 at 2:06:24 PM UTC-5, RobertCNelson wrote:
Reply all
Reply to author
Forward
0 new messages