Agreed. And the pins are E18 and E17 for DCAN1_RX/TX on the BBB schematic. These are the pins the TI pinmux tools says use. So, trying to use these two pins for CAN1 because we don’t have the P9 expansion header.
That is just the first step in this CAN bring up process for a custom BBB board that doesn’t have a P9 expansion header. So I agree. I still have a question for Robert, why is the P9 expansion header being used for then CAN on the most recent release instead of the AM335X CAN0 and CAN1 RX/TX pins D17/D18 and E17/E18? Thx, Tracy > On Nov 1, 2017, at 1:28 PM, William Hermans <[email protected]> wrote: > > > >> On Wed, Nov 1, 2017 at 11:19 AM, Robert Nelson <[email protected]> >> wrote: >> On Wed, Nov 1, 2017 at 1:14 PM, Tracy Smith <[email protected]> wrote: >> > E17 and E18 we want to use that are designated as possible CAN1 pins on the >> > BeagleBone Black schematic. >> > >> > Not using a different overlay, using the existing 4.14 kernel and 2017 I >> > boot that Robert Nelson suggests using for the BBB. But we need to pinmux >> > for E17 and E18 because the TI pinmuxing tool finds no conflict with these >> > two pins on our custom board. I’ll go back and check the CAN1 but prior to >> > Roberts changes last week that did not use the P9 expansion header, the >> > unit >> > pinmux used different pins CAN1 I believe. With the P9 expansion header, >> > can’t use Roberts overlay because there is no P9 expansion header on our >> > BBB >> > board. I’ll go back look at the pins for CAN1 prior to then P9 overlay >> > changes from last week by Robert. >> >> What i suggested, assumed you were using a BBB. Thus since you have a >> custom board, it's all null and void.. >> >> Use TI's pinmux tool and properly route your can signals. > > What Robert said, but in addition, it might be handy if you let us know what > hardware( everything ) you're using to help us, help you spot potential > hardware conflicts. I've worked on a project that did in fact use one CAN > interface a couple or three years ago. It works, but I only used one bus. Not > two. Additionally, I was using an older kernel, so I've not the same on a > current kernel. At some point I think I did test a semi recent kernel, just > to get the interface up and running, but I did not test the C code I wrote a > while back on that interface. > > So how do you know it's not working. Just saying it doesn't work does not > give us the steps you taken to get where you are. or the error messages > you're getting, that could help us troubleshoot your issue for you. Nor does > it tell us if the driver for a given CAN interface is even loaded. You see > where I'm going ? There are many places for this process to go wrong. > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to a topic in the Google > Groups "BeagleBoard" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/beagleboard/dE1bIym6rDg/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/CALHSORpKGh0pYiYL5AjJuDUXqLHTwunYGS_uCaYHXqwkz4xBMg%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/8D713A70-D95F-455B-8CF4-74ABDA41866B%40gmail.com. For more options, visit https://groups.google.com/d/optout.
