PIC32-EMZ64 schematic

[KeesZagers]

LubOlimex promised a CAN demo program the next week on september 26. Now more than 6 weeks have past and still no CAN demo.

In the mean time I measured the voltages at the transceiver and these seem to be OK. CAN Rx is high as it should be. CAN Tx gets high when the CAN controller is switched on. So at least this pin seems to be connected to the right pin. Measuring at the CPU pins is too difficult for me.

Someone else came any further?

Kees

[JohnS]

Not me as long as Harmony is there.  Sorry.

John

[KeesZagers]

Hi John,
For some reason I expected this answer from you 
I think I can make you happy, that I'm planning to set up my further application without using Harmony. For the moment however I don't know why the CANbus is not getting into the operational mode. And I'm really wondering if someone else is more intelligent than I am (not too difficult, I presume) and found a way to get it into the operational mode.

[Lion]

Dear all,

I'm still struggling with the CAN on the PIC32-EMZ64 as well. I invested hours and hours without any success.

What I did so far is:

- checked the MCP2551 - it's OK
- checked the CAN_CTRL line, is low
- checked several times the CAN clock timing - I guess it's ok, see note below
- read all Microchip forum entries regarding CAN issues
- setup a further small and simple test program with CAN and UART functionality only
- I'm aware about the not working command PLIB_CAN_ReceivedMessageGet and I'm using a workaround - see screenshot and link: www.microchip.com/forums/m906556.aspx

What is my issue:
- I can't receive any message from the CAN bus
- the command PLIB_CAN_BaudRateGet reports all the time a different baud rate as I noted in the Harmony configuration (in my case 50kbit/s)

So, I still believe I have an issue with the timing setting of the bus. The PBCLK5 is 25MHz to get 50kbit/s, the ...BaudRateGet functions reports 33kbit/s. I didn't find my problem, here.

Does any one have an another idea how to proceed?

Best regards
Bernhard

P.S. How can I add the screenshots to my post - it's a shame, I don't find the right button, sorry.

[KeesZagers]

As I don't want to do the application by using Harmony, I worked in a different way. I think independent of the bitrate set correctly, it should be possible to get the CANcontroller into the operational mode. Can you check by some kind of CAN_GetMode or CAN_GetStatus command, if the CANcontroller is really entering the operational mode? If this is not the case you will never be able to send or receive any CAN messages.

[LubOlimex]

Well, we have a developer appointed for the demo but he is also struggling to get it working. But we haven't ditched it, yet. He is still trying to get it working.

Trust me, I wish more than you to have all examples for all peripherals for all operating systems for all integrated development suits for all boards. However, sometimes you hit a wall in the software departament.

Best regards,
Lub/OLIMEX

[JohnS]

I wonder if it's worth someone trying to do CAN via Harmony with an MX, and check it works (sends/receives CAN packets).

Then:
1. compare with other known working MX code to see what harmony does (gulp?)
2. regenerate for MZ
3. see if MZ version works (sounds like it may not)
4. if it does, see what changed and use that knowledge to tweak user's existing MX CAN code

John

[KeesZagers]

I already compared quite a lot between the hardware of the MX (Duinomite Mega and eMega, PIC32-T795) and MZ implementations. Also with my own hardware extensions on the Duinomite 2nd CAN port and both CAN ports on the T795.
Following differences:
- All my MX implementations have connected the CAN Rx pin of the MCP2551 directly to the I/O pin on the PIC32 controller. The EMZ64 has this through a voltage divider to get it 3.3V compatible. In my opinion this is not necessary because the inputs are 5V protected as far as I know.
- None of my MX implementations have a CAN CTRL pin connected to an I/O pin. Only a 10k resistor to GND is OK. This pin can be used to adjust the slope, but as far as I know nobody is using that. The other possibility is to set it in sleep modus and in that case the resistor should be connected to 5V as far as I know. You should never set this pin to any voltage. So I used this pin as an input and not as an output. I think in a proper design the CAN CTRL pin should have been on the other side of the 10k resistor. The voltage measured on this pin is about 1 Volt.
As I'm not active on my development system right now I cannot give my steps I tried to set up the device up to now. But I can add this later maybe. It are just some extensions to the existing general purpose demo.

[kyrk.5]

KeesZagers: I started to investigate your problem. From your previous entry:
"In the initialisation I entered the configuration for connecting CAN Tx and Rx to the right I/O pins. I can change the CAN registers. However if I request the mode going from configuration to operational and after that check if this is done, I see that the actual status is still configuration."

I have tried the same thing and for me it is working. However I did not really did the complete initialization of the CAN module, I only tried the mode changes. Here is my code:
    RPC14R = 0b1111; //RC14 C1TX
    C1RXRbits.C1RXR = 0b0111; //RC13 C1RX
   
   
    C1CONbits.REQOP = 0b100; //First change to configuration mode. After reset this mode is the default so maybe no use this change
    while (C1CONbits.OPMOD != 0b100);
   
    C1CONbits.ON = 1; //I turn on the module, other bits remain as they are, as staten previously this is not a complete configuration, only for testing
   
    C1CONbits.REQOP = 0b000; //Request normal mode
    while (C1CONbits.OPMOD != 0b000);

After the code was executed a breakpoint was set. That was hit, so the while loop was running to end. Also I verified the C1CON registers REQOP bits and OPMOD bits with debugger to see if they have the proper value. They had.

Since the mode change is working, I would like to continue with the configuration. Lets see where is the point where the mode transition does not succeeds.
Could you please share your configuration? I could then take the settings and apply them one by one to my code and check if it is working, and when not where is the point that it fails to trigger the mode transition.

Some notes: I had nothing connected to the CAN bus, no resistor, no wires, no other CAN transmitters. Debugger was attached to the PIC32 all the time. (I have seen things with PowerPC where the presence of a debugger can change the flow of events).

[KeesZagers]

In fact I had included:

C1RXR = 0x07;
RPC14R = 0x0F;

to set the CAN port. You included C1RXRbits, maybe that is the missing link. Anyway the Tx pin worked well, because this pin became high when I switched on the CAN module. As I don't have my module available right now, I cannot test it, but I will try it the coming days.

Kees

[KeesZagers]

Great, your code is working on my hardware. As I did already a lot more (configuring bitrate, FIFO's, etc.) I have to find out what I did wrong. Anyway it was not only the missing C1RXRbits parameter. I think I will replace the module by some other LEDs in my Christmas tree and see if I find some time to help all the others (including the Olimex engineers) to get a real working CAN module at the beginning of 2017.

[Heinz]

see if I find some time to help all the others (including the Olimex engineers) to get a real working CAN module at the beginning of 2017.

Kees, we have March now :-)

[KeesZagers]

Heinz, March is still beginning, December is end :-)

Unfortunately I was forced by some customers (always those customers) to change my priorities. The projects I worked on, needed quite some analog and digital I/O and unfortunately the existing MZ hardware does not include both CANbus and free I/O pins. So still used MX hardware.