This time (2016 sept 24), there is a warning on that schematic "To be checked!!!". What it means? Any eta for that check to be done?
Do you have any doubts concerning the schematic? Did you run into problems e.g. with the I/O?
I did not succeed in getting a correct connection with the CANbus. I thought it was software, but if the hardware interfacing is not conform the schematic ...
Kees
It is a left-over note that the CAD designers forgot to remove. The schematic of PIC32-EMZ64 had been checked multiple times. The schematic on the web is the latest one that we use for the manufacturing of the board.
We would be adding a CAN example in the general demo archive (if nothing very important takes precedence expect it by the end of this week).
Best regards,
Lub/OLIMEX
I will check your site every hour of the day :)
I'm dreading it using the horrible Harmony... which would mean accepting the license :(
John
Someone already succeeded in getting the CANbus operational?
Kees
Quote from: KeesZagers on October 03, 2016, 02:17:40 PM
Someone already succeeded in getting the CANbus operational?
Kees
Hello Kees,
as you know, I'm too waiting for some results here, and the promised example for end of last week
Can you share your code? Maybe the problem can be found by a static analysis.
I have only one PIC32-EMZ64 with a CAN bus. So there is no way for me to try out your code (or only partially)
Quote from: kyrk.5 on October 04, 2016, 03:11:56 PM
Can you share your code? Maybe the problem can be found by a static analysis.
I have only one PIC32-EMZ64 with a CAN bus. So there is no way for me to try out your code (or only partially)
Thanks for the Offer. May be Kees can send you something.
I'm working on a character driver for LiteBSD https://github.com/sergev/LiteBSD (https://github.com/sergev/LiteBSD). It might be difficult to analyze the code without all the kernel headers.
I think Olimex also has problems in getting CANbus in operational mode??? No demo yet !!!
I simply used the standard demo, which is working and changed the code for one of the switches. 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. In my earlier adventures with the MX controllers I know this is mostly caused by a wrong connection of the transceiver chip to the controller. So that is why I began to doubt the hardware configuration.
Is there a listeting mode available? (I developed CAN driver some(lot :)) years ago for dsPIC) Maybe you can test if entering that mode is working.
Is it possible for you to measure the TX and RX lines betwen the PIC32 and transeever chip? Maybe there is something strange going on. What about the CAN-H and CAN-L?
Is there any special need to clear some error flag in the CAN module? I remember me something that the CAN module is sensitiv to this state transition and there are some things that must be done in order to get the transition happen.
What kind of tools do you have access? CANoe? Ossciloscope? Maybe with CAN bus decoding? Logical analysator (saleae)?
I guess I must buy a second device to be able to test the CAN... :)
Thanks for helping.
It is not possible to get the CAN module in another mode than the configuration mode. So also not Listen Only.
I think it is tricky to measure with my simple measuring instrument on these pins on the module and anyway I will measure the standard voltage because nothing is connected to the bus and I'm not trying to send any message. The same is true for the CAN Hi and CAN Lo on the other end of the transceiver.
The CAN module (all registers) are exactly the same as in the MX controllers of Microchip. I did several projects with the Duinomite modules of Olimex and I know how to configure the CAN controller.
The Duinomite Mega just has one CANport connected to an on-board transceiver. The port 2 Tx and Rx however are available on the pins D0 and D1 of the Arduino connector. So I made an Arduino extension module with an extra transceiverchip. If I configure the port 2 with the Arduino module connected I can switch the CAN 2 module from configuration to operational. If I don't have the module in place I get the same problem as I have with the PIC32-EMZ64 module. So I guess the connection of the CAN module and the transceiverchip is not right on the module.
IMHO there are two possible reasons for that:
1. The I/O pins on the MZ controller are not configured in the right way to set them up for the CAN module. As far as I read in the Microchip datasheet, this can be done any time and even changed in a program. But maybe I forget something here or I'm doing something wrong.
2. There is something wrong in the hardware. Maybe pinning is different from the schematic.
Anyway it seems to be complex also for the Bulgarian people, because they planned to have a demo program by the end of last week and now we are one week further.
Kees
CAN demo? 1 week has become 3 weeks now, without any news.
Hello *,
on the Can Demo I'm interested as well.
I coming from the PIC32 Maxi Web board and on this I realized (without Harmony) a Can Bus implementation with more than 10 Can nodes - this is up and running without any issues.
Now, I would like to do the same with the EMZ64 board and I'm stumbling with Harmony on all other issues. The good thing is I have a working solution in place but I don't get the EMZ running. I switch the CAN_CTRL (RC15) pin, this is one difference to the Maxi Web and I dealing with the 120 Ohm resistor at the end of the bus (which is the 2nd difference to the Maxi Web.
Does any one ever realized a Can Bus communication with the EMZ and Harmony?
Best regards
Lion
On the CAN-CTRL you have a point. I set the CAN-CTRL as an output and maybe that is not a good idea. I will further investigate this. The 120 Ohm termination resistor is not connected by default. You have to close a jumper on the board if you like to use it. Personally I hate the on-board termination resistors. In my opinion you should always use two external resistors on both ends of the bus.
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
Not me as long as Harmony is there. Sorry.
John
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.
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.
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.
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
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
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.
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).
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
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.
Quote from: KeesZagers on December 16, 2016, 10:48:31 PM
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 :-)
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.