MCAN demo program for SAME70 Xplained Ultra evaluation board

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There does not appear to be an MCAN demo program for SAME70 Xplained Ultra evaluation board.  I am trying to construct one myself, as a starting point for our development. 

 

There actually do not appear to be any demo programs for this development board.  However, it is similar enough to the SAM70 Xplained board (not Ultra) that I was easily able to adapt the Getting Started example for that board and run it on the Ultra.  (This required changing the main clock source to bypass, as per this article, and changing the pin for the User LED).

 

Using that as a basis, I did the following:

  1. Added the MCAN driver via the ASF wizard
  2. Copied the CAN code from the MCAN_QUICK_START1 demo program for the SAMV71 Xplained Ultra evaluation board.  I copied two files, conf_mcan.h and qs_mcan_basic.c
  3. In the project, I removed main.c and replaced it with qs_mcan_basic.c

 

This gives me a program with the CAN features from the MCAN_QUICK_START1 demo,  that compiles and runs, at least basically, on the SAME70 Xplained Ultra board.

 

I have connected the CANL, CANH, and CAN ground pins.

 

I can interact with the program via the serial interface, via a terminal emulator.  However, when I put one board into a receive mode and send the corresponding message from the other board, the transmitter displays:

: MCAN bus off error, re-initialization.

 

I have compared the MCAN pin assignments in the schematics of the SAME70 Xplained and Ultra boards; they appear to be identical.

 

Have any of you succeeded in getting this to work?

Or, can you suggest what might cause this bus error, when using this demo program?

Or, does anyone have a working CAN demo for the SAME70 Xplained Ultra board?  (Or, even for the SAME70 Xplained board!)

 

Thank you.

Last Edited: Tue. Sep 14, 2021 - 04:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Basya,

 

just guessing:

  1. Did you have the termination resistor of 120Ohm in place on both of your boards?
  2. Is the bandwidth (I guess 500kBit/s or 1MBit/s) set identical on both boards?
  3. Is your CAN wire a twisted pair cable?

 

Best Regards

Markus

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Markus.  

Thank you for responding.

 

1.  Yes.  The eval boards have the termination resistors built in.  And, to be sure, I measured.

2.  I am running the same demo program on both boards.  

3.  I believe so.  I will triple check this with the hardware engineer who made it, but he is out for a week.  But I'm 99.9% sure, as we discussed that when he put it together.

 

 

Again, this is an evaluation board, running a demo program which should work out-of-the 'box' on the V71 Ultra evaluation board; I took all the CAN and application code from there.  

 

Has anyone gotten this demo working on the E70 Xplained Ultra board?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello Basya,

 

So have you found a solution?

 

MRK

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, not yet.  Working on it again today....

 

I have hooked up one board to a CAN analyzer, so that one side is confirmed working.  

 

I have confirmed that the signals sent by the CAN analyzer reach the transceiver, and I see the signal on the RX line from the transceiver to the processor.

However, when I try to transmit from the Ultra board, there is no signal coming out of the processor on the tx line to the transceiver.  

 

Has anyone run this demo on the board for which it is written, the SAMV71 Xplained Ultra?  Does this demo actually work?  I will start checking register by register I guess....

 

Also, is anyone aware of a difference in how the CAN functions (addresses, registers, whatnot) between the SAMV71 and SAME70 processors?  As far as I can tell, they are meant to be exactly the same...

Last Edited: Wed. Sep 29, 2021 - 02:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I could not find any fully working examples also. Getting the MCAN hardware peripheral would probably

be ideal, but if you are interested, I have a pure software ("bit-banged") CAN bus implementation that I

developed myself. It has been tested on the SAME70 Xplained development board, but since it relies on

the bare minimum of hardware capabilities (GPIO read/write, timers, interrupt handlers) it could be modified

to work on a wide variety of MCUs, maybe even 8-bit ones at the lowest speeds. 

 

The implementation of the CAN bus protocol consists of a pair of timers and a set of interrupt 
handlers. When sending or receiving, a little bit of work is done in one or two of 
the interrupt handlers and then control is returned to the other tasks in the firmware. This means this is a non-blocking

implementation. You deposit your message and move on to doing other unrelated work. No CAN 
bus hardware peripherals are being used. You can use any two GPIO pins for the CAN bus 
transceiver that will connect to these pins. I used an external CAN transceiver that I bought at Amazon.

Both standard (CAN 2.0A) and extended (CAN 2.0B) parts of the protocol are supported. The main 

difference between these two is the length of the message identifiers. This is a full-featured implementation

that supports (1) acknowledgements; (2) collision detection and transmission abort if colliding with a higher

priority message without damaging the higher priority message that was collided with; (3) transmission/retransmission 
requests; (4) handling of stuffed bits; (5) baud rates of 5Kbps, 10Kbps, 12.5Kbps, 25Kbps, 50Kbps,

and 125Kbps; and (6) checksum calculations. 

 

It has the following limitations:
- The CAN FD addition to the CAN bus protocol is not supported.
- Maximum speed is currently 125Kbps.
- Two timer/counters will be reserved for CAN bus operation. 
- Due to the fact that the protocol is implemented in software as opposed to hardware, you 
  need a fast processor and even then you will not be able to achieve the speeds that can be
  achieved by hardware peripherals. Luckily, the SAME70 is quite fast.

 

I have done a good amount of testing and believe that it is reliable, but additional testing and feedback from others

is always useful. I would like to make it as reliable as possible.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you.  However, I have to get the MCAN interface working.

Others in my company have gotten it working in the past on the same processor, but a different board, so I know it is possible.  Right now, we need to work with the evaluation board.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey all,

I am facing the same problems here.

IDE: MPLAB X IDE v5.50

There is an example for CAN on the SAMe70 Xplained Ultra Board within the Harmony examples. For me this has the same issue with the missing signal on the TX Pin aswell. As example didnt worked it tried 3 Versions of the Harmony 3 mcan lib. None of them worked. Version 1 was an older mcan lib. Version 2 the newest version. Version 3 the newest version of the lib with the old interface style. Microchip changed the interface here within the versions for easier use between CAN and CAN-FD and also to make it easeier to send more than one message at once.

 

Could you figure your problem out?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I haven't finished with this, as focus moves between projects and I am not on this project all the time.  However, I found that the main problem I had after putting together the two demos (Getting started for E70 Xplained with modifications for Xplained Ultra, with the main program and CAN config from the CAN demo for the V71 Xplained Ultra board), is that I was missing some #defines that were #defined in the conf_board.h file of the V71 MCAN demo, but not in the conf_board.h of the Getting Started Example.  I had missed these lines when putting together the two demos. After that, I did see some communication.  It wasn't perfect or consistent, but I may have also had cable problems at that point.

 

I have not tried with MPLAB Harmony.

Last Edited: Wed. Oct 13, 2021 - 12:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dear ElAlamein,

 

cool stuff if you reimplement the CAN protocol on a BitBang level. However I'm pretty sure this approach will have its limits if it comes to higher speeds (no car on the world is below 500kBit/s), or CAN-FD features (variable transmission speed up to 8MBit/s). To have a complete implemention you also need features like error-frames, error-counters etc. 

 

In any case, I'm using 2 CAN interfaces of the SAME70 on a custom board (unfortunately equipped with the A Version of the µC - so I cannot use CAN-FD properly) without a problem. It really works realiable. I installed my board in many standard road cars and it is collecting data and also sending messages without a problem. So I'm sure the problems that are reported are not related to the SAME70. The only thing that comes to my mind is that if your are using the filtering to a certain extend you need to change some bits in the bus matrix because the CAN messages need to be stored in an area that is used for something else by default. I couldn't remember all the details but it is documented in the user manual.

 

Best Regards

Markus

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Hi Basya,

 

there is an CAN error register. Have you checked the entires there? This might give you an idea what is going wrong. Additionally I would recommend to check the signal with an oscilloscope if you have such a device available. Maybe you can see some distortions there. 

Have you used a proper twisted pair of wires? The CAN transmission is very robust - but without twisted wires (and terminating resistor) it will fail even if the communication lines are below 1m.

 

Best Regards

Markus