Mikroe Click board inccorect.

A few years ago I did a project that needed high speed CAN message acquisition from power up. The Raspberry PiZeroW took about 18 seconds to boot in its fastest incantation which meant 18 seconds of vehicle start up and running messages would be lost.

Eventually I used a PIC32 to do the power up data logging and dumped the data up to the PiZero acting as an SPI master while the PIC32 was the slave. Since I needed a number of features that weren’t on the PIC32 I used an Automotive Networking Board (ANB) which had a number of Click expansion sockets. One was the mcp2542 CAN bus driver terminating in a DB-9 with standard CANopen CAN bus format.

https://www.mikroe.com/mcp2542-click

Since I was buying Click boards I picked up a cape for the BBB.

https://www.mikroe.com/beaglebone-mikrobus-cape

That was a few years ago. Now I thought I’d use the cape and the mcp2542-click for testing CAN1 communications with the Beagle. But there’s a problem. Although the Click board worked properly on the ANB something wasn’t right with the Beagle installation. A bit of tracking with the scope and the schematics has shown there’s an error on the click board. Or on the cape. Although the board worked on the ANB jumpers directed the signals so I’m going to suggest the problem is with the Click board.

So: What is the problem? It derives from the ease of creating the TI processor silicon and putting the CAN1_TX signal on the same pin as the UART1_RX (GPIO14). That makes a carrier board like the cape difficult to deal with because it’s marked Tx on a pin that is Tx for UART but Rx for CAN. The trouble is the mcp2542-click board also thinks that the Tx for Uart is the same as the Tx for CAN1. It’s not.

The MCP2542-Click also has the two HDR1 pins marking CAN_H and CAN_L reversed. The signals are correct on the DB-9. Because the ANB motherboard (attached photo) has jumpers that can allocate what pins get what signal the best solution is to change the MCP2542-Click with some trace cuts and jumper wires.

I’ve passed on this information to www.mikroe.com but just be aware this Click board will not work on the BBB cape.

The Logic Supply CBB-Serial Cape does not have problems and I’ve been able to use the socketCAN utilities with it on the 2018 OS.

https://www.onlogic.com/cbb-serial/

It’s been discontinued along with the Logic Supply name as the above link shows.

In the long run this probably won’t matter because it seems like the Beagle itself is on its death bed.

John Dammeyer

ADM-TestSetup2s.jpg

Just to add to this: The photo shows the pin marked TX is connect to Pin 4 of the IC and the header pin marked RXD. Pin 4 is the Can Device Rx Pin which connects all the way to GPIO14 on P9-26.

But of course P9-26 is UART1_RX but also CAN1_TX. At least one of the other Click boards shows the same issue. The Raspberry Pi Click Shield lists that pin as an Rx but of course the Pi doesn’t have a CAN device so who cares…

John

MCP2542-Click.jpg

Hi John

Interesting we used Pic for a CAN to USB Bridge for a doctors laptop to get Data and and out of doctors tablet for an implantable heart pump.

TI 28335 DSP was master, TI DSP Piccolo ran the implant motor and we had a PIC doing some system house keeping. All 3 processors were connected on CAN bus sharing data.

Can stack wrote in house As was a simple scheduler on Master.

Redundant battery packs wore by grandpa on belt so Grandpa could go hunting with his failed heart.

CCS JTAG on two TI and PIC had JTAG I believe we added a Blue tooth module on PIC.

Fast reliable and Life critical imagine Grandpa waiting 18 seconds after a reboot for his left ventricle to pump🙈.

the long run this probably won’t matter because it seems like the Beagle itself is on its death bed.

Hunch. Edecuated guess? I feel a lack of mojo myself.

What is next the Dog :dog: pound board on OpenRisc is my guess?

On the positive side all TI IP work the same pretty much on DSP or Soc so at least low level knowledge isn’t wasted it’s transferable to all TI DSP and other Socs if the AM335x chip isn’t marketed as much which I doubt.

I’m a big investor in NVDA and can’t wonder how many Chip designer’s are nervous about the ARM acquisition.

My interest are at low level SW not Linux so I won’t be migrating to any non ARM Soc no matter how much drum beating occurs. Hopefully they add JTAG.

Love TI chips started as a Motorola guy, transitioned to ARM not an Intel Fan.

IMX by NXP is interesting. Did one MIPS processor project.

I remember working with a consultant on his first day at our stand up he bragged he was on his 50th job and he never met a microprocessor he didn’t like LOL.

I told him wow nice story I wouldn’t share that later.

Project was ESP32 he was fired after 90 days I didn’t have a chance ask him if he still liked ESP32.

Nice cheap chip. the support in the beginning of that chips life was horrible .

Mostly open source Free RTOS community support. I own one somewhere.

Mark