| View previous topic :: View next topic |
| Author |
Message |
jamalavedra
Joined: 25 Oct 2016
Posts: 62
|
| CAN problem |
 Posted: Mon Apr 10, 2017 10:06 am |
 |
|
Hi;
I am doing a project where two PIC have to communicate between each other using the CAN protocol (can-18xxx8.c , in the drivers folder in PICC).
I have tried to establish (turning on & off a LED) master slave communication between two PIC18F2685 and it worked just fine. BTW I am using a MCP2551 from Microchip.
The problem comes when changing the components a bit. What I need to do is change one of the PIC and MCPs to a PIC 18LF2685 and the MCP to a CAN transceiver from Texas -instruments SN65HVD232D. Apparently the code doesn't compile properly in the low voltage PIC and I can't find why.
This is the compiled code in the master PIC (18F2685)- Works fine
| Code: |
#include <18F2685.h>
#device PASS_STRINGS = IN_RAM
#FUSES NOWDT //No Watch Dog Timer
#FUSES WDT128 //Watch Dog Timer uses 1:128 Postscale
#FUSES HS //Low power osc < 200 khz
#FUSES NOPROTECT //Code not protected from reading
#FUSES NOBROWNOUT //Reset when brownout detected
#FUSES BORV20 //Brownout reset at 2.0V
#FUSES NOPUT //No Power Up Timer
#FUSES NOCPD //No EE protection
#FUSES STVREN //Stack full/underflow will cause reset
#FUSES NODEBUG //No Debug mode for ICD
#FUSES NOLVP //Low Voltage Programming on B3(PIC16) or B5(PIC18)
#FUSES NOWRT //Program memory not write protected
#FUSES NOWRTD //Data EEPROM not write protected
#FUSES IESO //Internal External Switch Over mode enabled
#FUSES FCMEN //Fail-safe clock monitor enabled
#FUSES PBADEN //PORTB pins are configured as analog input channels on RESET
#FUSES BBSIZ4K //4K words Boot Block size
#FUSES NOWRTC //configuration not registers write protected
#FUSES NOWRTB //Boot block not write protected
#FUSES NOEBTR //Memory not protected from table reads
#FUSES NOEBTRB //Boot block not protected from table reads
#FUSES NOCPB //No Boot Block code protection
#FUSES LPT1OSC //Timer1 configured for low-power operation
#FUSES NOMCLR //Master Clear pin enabled
#FUSES NOXINST //Extended set extension and Indexed Addressing mode enabled
#DEVICE ADC=10
#use delay(clock=20M)
#define CAN_USE_EXTENDED_ID FALSE
#include <can-18xxx8.c>
int1 m=0;
//unsigned int16 cobid=0;
//unsigned int8 lengthCAN=0;
#int_canrx0
void canrx0_int ( ) {
}
#int_canrx1
void canrx1_int ( ) {
// TODO: add CAN recieve code here
}
#int_cantx0
void cantx0_int ( ) {
// TODO: add CAN transmit code here
}
#int_cantx1
void cantx1_int ( ) {
}
#int_cantx2
void cantx2_int ( ) {
}
void main (void)
{
can_init();
disable_interrupts(GLOBAL);
can_set_mode(CAN_OP_CONFIG);
output_high(pin_C7);
BRGCON1.brp=1;
BRGCON1.sjw=1;
BRGCON2.prseg=2;
BRGCON2.seg1ph=7;
BRGCON2.sam=FALSE;
BRGCON2.seg2phts=FALSE;
BRGCON3.seg2ph=6;
BRGCON3.wakfil=FALSE;
CIOCON = 0x20;
/*BRGCON1.brp=1; // cntrol c control v
BRGCON1.sjw=0;
BRGCON2.prseg=2;
BRGCON2.seg1ph=7;
BRGCON2.sam=FALSE;
BRGCON2.seg2phts=FALSE;
BRGCON3.seg2ph=6;
BRGCON3.wakfil=FALSE; */
can_set_mode(CAN_OP_NORMAL);
enable_interrupts(int_canrx0);
enable_interrupts(int_canrx1);
enable_interrupts(int_cantx0);
enable_interrupts(int_cantx1);
enable_interrupts(int_cantx2);
enable_interrupts(GLOBAL);
while(true)
{
m=m+1;
output_bit(pin_c5,m);
TXB0SIDH = (unsigned int8) (0x081 >> 3); //cobid accelerometro
TXB0SIDL = (unsigned int8) (0x081 << 5); //cobid
TXB0DLC = 1; //llargaria del misstage
TXB0D0 = m; // informacio que envio al primer byte
TXB0CON.txreq = 1; //confirmacio rebuda misatge
delay_ms(100);
}
}
|
This is the slave code that works fine in the (18F2685) but gets stuck after the line that says <can_set_mode(CAN_OP_CONFIG);> and doesn't read.
| Code: |
#include <18F2685.h>
#device ADC=10
#device PASS_STRINGS = IN_RAM
#FUSES NOWDT //No Watch Dog Timer
#FUSES WDT128 //Watch Dog Timer uses 1:128 Postscale
#FUSES HS //Low power osc < 200 khz
#FUSES NOPROTECT //Code not protected from reading
#FUSES NOBROWNOUT //Reset when brownout detected
#FUSES BORV20 //Brownout reset at 2.0V
#FUSES NOPUT //No Power Up Timer
#FUSES NOCPD //No EE protection
#FUSES STVREN //Stack full/underflow will cause reset
#FUSES NODEBUG //No Debug mode for ICD
#FUSES NOLVP //Low Voltage Programming on B3(PIC16) or B5(PIC18)
#FUSES NOWRT //Program memory not write protected
#FUSES NOWRTD //Data EEPROM not write protected
#FUSES IESO //Internal External Switch Over mode enabled
#FUSES FCMEN //Fail-safe clock monitor enabled
#FUSES PBADEN //PORTB pins are configured as analog input channels on RESET
#FUSES BBSIZ4K //4K words Boot Block size
#FUSES NOWRTC //configuration not registers write protected
#FUSES NOWRTB //Boot block not write protected
#FUSES NOEBTR //Memory not protected from table reads
#FUSES NOEBTRB //Boot block not protected from table reads
#FUSES NOCPB //No Boot Block code protection
#FUSES LPT1OSC //Timer1 configured for low-power operation
#FUSES NOMCLR //Master Clear pin enabled
#FUSES NOXINST //Extended set extension and Indexed Addressing mode enabled
#use delay(clock=20M)
#define CAN_USE_EXTENDED_ID FALSE
#include <can-18xxx8.c>
int1 v=0;
int m=1;
unsigned int16 cobid=0;
unsigned int8 lengthCAN=0;
#int_canrx0
void canrx0_int ( ) {
cobid=((unsigned int16)RXB0SIDH << 3)|((RXB0SIDL & 0xE0)>>5);
lengthCAN = (unsigned int8)RXB0DLC & 0xF;
if(cobid == 0x081)
{
m=RXB0D0;
output_bit(pin_c5,++v);
}
RXB0CON.RXFUL = 0;
}
#int_canrx1
void canrx1_int ( ) {
// TODO: add CAN recieve code here
}
#int_cantx0
void cantx0_int ( ) {
// TODO: add CAN transmit code here
}
#int_cantx1
void cantx1_int ( ) {
}
#int_cantx2
void cantx2_int ( ) {
}
void main (void)
{
can_init();
disable_interrupts(GLOBAL);
can_set_mode(CAN_OP_CONFIG);
output_high(pin_c5);
BRGCON1.brp=1;
BRGCON1.sjw=1;
BRGCON2.prseg=2;
BRGCON2.seg1ph=7;
BRGCON2.sam=FALSE;
BRGCON2.seg2phts=FALSE;
BRGCON3.seg2ph=6;
BRGCON3.wakfil=FALSE;
CIOCON = 0x20;
can_set_mode(CAN_OP_NORMAL);
enable_interrupts(int_canrx0);
enable_interrupts(int_canrx1);
enable_interrupts(int_cantx0);
enable_interrupts(int_cantx1);
enable_interrupts(int_cantx2);
enable_interrupts(GLOBAL);
while(true)
{
if (m==1) output_high(pin_c7);
else output_low(pin_c7);
output_high(pin_A1);
}
}
|
I would very much appreciate some kind of advice on what it takes to compile and work fine in the normal PIC, but not in the 18LF2685.
Thank you
jaume |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19545
|
|
| Posted: Mon Apr 10, 2017 1:18 pm |
|
|
What is the other PIC?.
The 2685, has the ECAN peripheral, so you really should be using the 18F4580.h driver. |
|
|
jamalavedra
Joined: 25 Oct 2016
Posts: 62
|
|
| Posted: Mon Apr 10, 2017 3:44 pm |
|
|
| Ttelmah wrote: | What is the other PIC?.
The 2685, has the ECAN peripheral, so you really should be using the 18F4580.h driver. |
The other pic is the 18LF2685 |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Apr 10, 2017 3:53 pm |
|
|
What is the Vdd voltage on each PIC, and on each type of CAN bus
transceiver chip ? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19545
|
|
| Posted: Tue Apr 11, 2017 1:27 am |
|
|
OK. So as I read it, you can compile and use the code OK on the 'F' variant, but the compile is halting on the 'LF' variant?.
If so, the first thing you need to tell us is the compiler version?.
Any time you have a problem of this sort, this should be one of the first things you tell us....
The steps once we know this, would first be to compare the header files between the two variants, and then look in the device editor for any differences between the variants. Without the compiler version, we can't do this. The odds are it is just some small error in the peripheral setup between the versions. |
|
|
jamalavedra
Joined: 25 Oct 2016
Posts: 62
|
|
| Posted: Tue Apr 11, 2017 7:27 am |
|
|
| PCM programmer wrote: | What is the Vdd voltage on each PIC, and on each type of CAN bus
transceiver chip ? |
The PIC 18F2685 has a VDD voltatge of 5V and the 18LF2685 has a Vdd voltatge of 3.3V
The 18F2685 is connected to a MCP 2551 from microship
The 18LF2685 is connected to a SN65HVD232D from Texas.
The Code works when i use identic components for the slave and master. But when I change to the Low voltatge Pic the code does not get executed in the LF PIC (it gets stuck when executing the line <can_set_mode(CAN_OP_CONFIG); >). |
|
|
jamalavedra
Joined: 25 Oct 2016
Posts: 62
|
|
| Posted: Tue Apr 11, 2017 7:29 am |
|
|
| Ttelmah wrote: | OK. So as I read it, you can compile and use the code OK on the 'F' variant, but the compile is halting on the 'LF' variant?.
If so, the first thing you need to tell us is the compiler version?.
Any time you have a problem of this sort, this should be one of the first things you tell us....
The steps once we know this, would first be to compare the header files between the two variants, and then look in the device editor for any differences between the variants. Without the compiler version, we can't do this. The odds are it is just some small error in the peripheral setup between the versions. |
The Code is gets compiled with no errors nor warnings. It is in the execution of the compiled code by the PIC when it doesn't work properly.
My compiler version is the 4.104.
thanks
jaume |
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Tue Apr 11, 2017 9:07 am |
|
|
| Quote: |
The Code is gets compiled with no errors nor warnings. It is in the execution of the compiled code by the PIC when it doesn't work properly.
My compiler version is the 4.104.
|
Your code does NOT compile on 5.056, this is because BORV20 is not valid on 5.056: I've tried, it would have to be BORV21. On 5.056 at least, the F and LF headers are identical apart from the title and #device line. Obviously that's not your problem as you are using 4.104, which had a whole lot of problems of its own.
I do not use your PIC18F/LF2685s. I have used the 18F8585 and members of the 18F4580 family, but always at 5V. I have also used PIC24HJ128G504s at 3.3V. With the 18s I have had problems with the CAN not working, apparently "locking up" associated with lpower voltages lower than about 4.6V. I have mostly thought of that as to do with the MCP2551, which has low voltage lockout, but never fully sorted it out; preferring instead to deal with the root cause of the low power voltage (unexpectedly high volt drop down SATA cables never intended for power - a design I inherited :-( ) it could well be that the problem lies in the CAN peripheral in the PIC, which in all the 18 series cases I've dealt with is the same as the one in your PIC.
So, what I am saying is that it is believable that there might be an issue with your CAN peripheral not running at lower voltages. I have never had any similar problems with the much more complex CAN peripheral in the 24s, which run at 3.3V by default.
I have also not used the TI interface ICs. Instead I now use the MCP2562, which has low voltage and split rail capability. In any case, the MCP2551 is not recommended for new designs.
I note that your code appears to be based on code produced by the current project wizard (which I didn't think was that sophisticated around 4.104), and you appear at first sight to be using the CCS CAN code, but in fact after intitialising you override the settings and use direct register access, so ignoring the capabilities of the CCS CAN driver code. This seems odd: if you buy a dog, why bark yourself? It certainly makes the code complex and borderline unreadable.
You can use can-18xxx8.c or can-18F4580.c with this PIC with it's ECAN peripheral. can-18F4580.c will be a bit slower as it has more overhead on basic tasks, but for the most part its extended features are not required for most CAN tasks. In any case as you pretty much don't use any of either it makes little difference. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19545
|
|
| Posted: Tue Apr 11, 2017 12:39 pm |
|
|
He is actually compiling for the F, not the LF.
Since it runs on the F at full voltage, and the device ID for the F and LF are the same, we know the problem is with the voltage, not the code.
I think his problem is the lack of a pull up on the CANTX line. The 2551 transceiver has a built in pull up (read the data sheet). It's the resistor shown to Vdd in the block diagram. The Texas transceiver does not have this.
There is an option for the CCS driver to drive the line high:
#define CAN_ENABLE_DRIVE_HIGH 1
or add an external pull-up. |
|
|
jamalavedra
Joined: 25 Oct 2016
Posts: 62
|
|
| Posted: Wed Apr 12, 2017 2:52 am |
|
|
| Ttelmah wrote: | He is actually compiling for the F, not the LF.
Since it runs on the F at full voltage, and the device ID for the F and LF are the same, we know the problem is with the voltage, not the code.
I think his problem is the lack of a pull up on the CANTX line. The 2551 transceiver has a built in pull up (read the data sheet). It's the resistor shown to Vdd in the block diagram. The Texas transceiver does not have this.
There is an option for the CCS driver to drive the line high:
#define CAN_ENABLE_DRIVE_HIGH 1
or add an external pull-up. |
Great, thanks. Now the code gets executed all the way but doesn't appear to receive any message. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19545
|
|
| Posted: Wed Apr 12, 2017 4:21 am |
|
|
That particular pull-up one is a 'gotcha', in the CCS code, where it only works correctly with the drive disabled, on transceivers that do have internal pull-ups....
So, now you need to be doing some basic debugging. Is the 2.5v being generated correctly?. Do the waveforms look right?. If I remember Texas had a nice application note about debugging CAN. If you have something like a CAN monitor box and PC application, you can send a message and see if this is working. |
|
|
jamalavedra
Joined: 25 Oct 2016
Posts: 62
|
|
| Posted: Wed Apr 12, 2017 4:37 am |
|
|
| Ttelmah wrote: | That particular pull-up one is a 'gotcha', in the CCS code, where it only works correctly with the drive disabled, on transceivers that do have internal pull-ups....
So, now you need to be doing some basic debugging. Is the 2.5v being generated correctly?. Do the waveforms look right?. If I remember Texas had a nice application note about debugging CAN. If you have something like a CAN monitor box and PC application, you can send a message and see if this is working. |
When using the LF PIC and the Texas Instruments transceiver no wave form is generated at all but when using the F PIC and the MCP from microchip a 2.5V square wave form appears with the same code.
I am pretty sure the problem has to be something to do with the transceiver because I've tried the same LF pic with some other MCPs and same code and worked perfectly. I can't find the error with the TI chip though. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19545
|
|
| Posted: Wed Apr 12, 2017 8:20 am |
|
|
| Forget the PIC for a moment. Just disconnect the D line, and feed a square wave from a signal generator into this (3vP-P). Look at the bus pins. Do you get two anti-phase square waves out of them?. You should see the CanH line going from 2.3v to about 3v, and the CanL line going from 2.3v to perhaps a volt. Exactly as figure 20 in the data sheet. This has to work before anything else can. If it doesn't, it may be as simple as a faulty transceiver. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
