• AVR Freaks

Hot!PIC18F4580 UART Communication Interrupting CAN Transmission and Reception

Page: 12 > Showing page 1 of 2
Author
beb
New Member
  • Total Posts : 19
  • Reward points : 0
  • Joined: 2019/11/12 13:38:42
  • Location: 0
  • Status: offline
2019/11/13 06:50:20 (permalink)
0

PIC18F4580 UART Communication Interrupting CAN Transmission and Reception

Hello,
 
I am programming a PIC18F4580 to transmit CAN, and I have an RS232 connector hooked up and a COM port set up using Termite to read registers / variables for debugging purposes. 
 
I am using XC8 as a compiler in this case, and I am noticing that whenever I connect to the COM port using Termite, my CAN transmission and reception stops, and does not start again until I disconnect from the COM port. I am connected using a baud rate of 9600. 
 
Is there any reason that this would happen? When I do not connect to the COM port I am transmitting and receiving CAN just fine.
 
I would like to be able to read serial data during development for debugging purposes. Another interesting note, when I have the COM port connected, TXLARB: Transmission Lost Arbitration Status Bit is high in the TXBnCON register I am transmitting from. So for some reason the COM port is causing lost arbitration, and I do not understand why that would happen.
 
Here is my code for reference:
 
#define _XTAL_FREQ 20000000 

// CONFIG1H
#pragma config OSC = HS // Oscillator Selection bits (HS oscillator)
#pragma config FCMEN = OFF // Fail-Safe Clock Monitor Enable bit (Fail-Safe Clock Monitor disabled)
#pragma config IESO = OFF // Internal/External Oscillator Switchover bit (Oscillator Switchover mode disabled)

// CONFIG2L
#pragma config PWRT = OFF // Power-up Timer Enable bit (PWRT disabled)
#pragma config BOREN = BOHW // Brown-out Reset Enable bits (Brown-out Reset enabled in hardware only (SBOREN is disabled))
#pragma config BORV = 3 // Brown-out Reset Voltage bits (VBOR set to 2.1V)

// CONFIG2H
#pragma config WDT = OFF // Watchdog Timer Enable bit (WDT disabled (control is placed on the SWDTEN bit))
#pragma config WDTPS = 32768 // Watchdog Timer Postscale Select bits (1:32768)

// CONFIG3H
#pragma config PBADEN = ON // PORTB A/D Enable bit (PORTB<4:0> pins are configured as analog input channels on Reset)
#pragma config LPT1OSC = OFF // Low-Power Timer 1 Oscillator Enable bit (Timer1 configured for higher power operation)
#pragma config MCLRE = ON // MCLR Pin Enable bit (MCLR pin enabled; RE3 input pin disabled)

// CONFIG4L
#pragma config STVREN = ON // Stack Full/Underflow Reset Enable bit (Stack full/underflow will cause Reset)
#pragma config LVP = ON // Single-Supply ICSP Enable bit (Single-Supply ICSP enabled)
#pragma config BBSIZ = 1024 // Boot Block Size Select bit (1K words (2K bytes) boot block)
#pragma config XINST = OFF // Extended Instruction Set Enable bit (Instruction set extension and Indexed Addressing mode disabled (Legacy mode))

// CONFIG5L
#pragma config CP0 = OFF // Code Protection bit (Block 0 (000800-001FFFh) not code-protected)
#pragma config CP1 = OFF // Code Protection bit (Block 1 (002000-003FFFh) not code-protected)
#pragma config CP2 = OFF // Code Protection bit (Block 2 (004000-005FFFh) not code-protected)
#pragma config CP3 = OFF // Code Protection bit (Block 3 (006000-007FFFh) not code-protected)

// CONFIG5H
#pragma config CPB = OFF // Boot Block Code Protection bit (Boot block (000000-0007FFh) not code-protected)
#pragma config CPD = OFF // Data EEPROM Code Protection bit (Data EEPROM not code-protected)

// CONFIG6L
#pragma config WRT0 = OFF // Write Protection bit (Block 0 (000800-001FFFh) not write-protected)
#pragma config WRT1 = OFF // Write Protection bit (Block 1 (002000-003FFFh) not write-protected)
#pragma config WRT2 = OFF // Write Protection bit (Block 2 (004000-005FFFh) not write-protected)
#pragma config WRT3 = OFF // Write Protection bit (Block 3 (006000-007FFFh) not write-protected)

// CONFIG6H
#pragma config WRTC = OFF // Configuration Register Write Protection bit (Configuration registers (300000-3000FFh) not write-protected)
#pragma config WRTB = OFF // Boot Block Write Protection bit (Boot block (000000-0007FFh) not write-protected)
#pragma config WRTD = OFF // Data EEPROM Write Protection bit (Data EEPROM not write-protected)

// CONFIG7L
#pragma config EBTR0 = OFF // Table Read Protection bit (Block 0 (000800-001FFFh) not protected from table reads executed in other blocks)
#pragma config EBTR1 = OFF // Table Read Protection bit (Block 1 (002000-003FFFh) not protected from table reads executed in other blocks)
#pragma config EBTR2 = OFF // Table Read Protection bit (Block 2 (004000-005FFFh) not protected from table reads executed in other blocks)
#pragma config EBTR3 = OFF // Table Read Protection bit (Block 3 (006000-007FFFh) not protected from table reads executed in other blocks)

// CONFIG7H
#pragma config EBTRB = OFF // Boot Block Table Read Protection bit (Boot block (000000-0007FFh) not protected from table reads executed in other blocks)

// #pragma config statements should precede project file includes.
// Use project enums instead of #define for ON and OFF.

#include <xc.h>
#include <pic18.h>
#include "ECAN.h"
#include <stdio.h>
#include <stdarg.h>
#include <stdlib.h>
#include <stdint.h>

// Function required for printf()
void putch(char data) {
    while( ! TXIF)
        continue;
    TXREG = data;
}

// Function that initializes the UART communication requirements
void init_uart(void) {
    // SPBRG is a 8-bit register
    // = (Fosc / (16 x Baud rate)) - 1, BRGH = 1 High Speed IN HEX
    // (8M/(16*9600))-1 = 51 = 0x33
    // (20M / (16 * 9600)) - 1 = 0x81
    SPBRG = 0x81; // Sets Baud rate of 9600 bps @ 4 MHz
    TXEN = 1; // enable transmitter
    BRGH = 1; // select high baud rate
    SPEN = 1; // enable serial port
    CREN = 1; // enable continuous operation
}


void main(void) {
    
    PORTA = 0x00;
    ADCON1 = 0x85;
    TRISA = 0b11011011;
    
    PORTB = 0x00;
    TRISB = 0b11111111;
    
    PORTC = 0x00;
    TRISC = 0b00000000;

    
    init_uart();
    printf("Uart Initialized \n");
    
    ECANInitialize();
    printf("ECAN Initialized \n");
    
    BYTE data[8];
    BYTE dataRX[8];
    BYTE dataLen;
    ECAN_RX_MSG_FLAGS flags;
    unsigned long id;
    BYTE txErrorCount;
    
    data[0] = 0x11;
    data[1] = 0x22;
    data[2] = 0x33;
    data[3] = 0x44;
    data[4] = 0x55;
    data[5] = 0x66;
    data[6] = 0x77;
    data[7] = 0x88;
    
    
    
    while(1)
    {
        //If Recieve message, copy data and transmit with new ARB ID
        if (ECANReceiveMessage(&id, dataRX, &dataLen, &flags))
        {
            id++;
            ECANSendMessage(id, dataRX, dataLen, flags);
        }
        //Transmit random test message
        ECANSendMessage(0x123, data, 8, ECAN_TX_STD_FRAME);
        printf("test \n");
// printf("CANCON: ");
// printf("%04x \n",CANCON);
// printf("TXB0CON: ");
// printf("%04x \n",TXB0CON);
// printf("TXB1CON: ");
// printf("%04x \n",TXB1CON);
// printf("TXB2CON: ");
// printf("%04x \n",TXB2CON);
// txErrorCount = ECANGetTxErrorCount();
// printf("TXERRCNT: ");
// printf("%04x \n",txErrorCount);
        __delay_ms(1000);
    }
    return;
}

 
Thank you
#1

21 Replies Related Threads

    ric
    Super Member
    • Total Posts : 24638
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: offline
    Re: PIC18F4580 UART Communication Interrupting CAN Transmission and Reception 2019/11/13 15:57:02 (permalink)
    +1 (1)
    Is the COM port connected to a laptop PC powered from an AC adaptor with a 2-pin plug?
    Quite possibly the laptop is floating at an AC voltage well above ground level, and injecting this into your CAN network.
    Try disconnecting RX and TX and see if it is just the ground connection on the COM cable causing the problem.
     
    (It's unclear from your description if "connecting" means physically plugging a cable in, or just clicking a CONNECT button in Termite)
     
    If it is just the ground connection, try connecting an independent ground wire to your PCB or to your laptop.
     
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #2
    beb
    New Member
    • Total Posts : 19
    • Reward points : 0
    • Joined: 2019/11/12 13:38:42
    • Location: 0
    • Status: offline
    Re: PIC18F4580 UART Communication Interrupting CAN Transmission and Reception 2019/11/14 06:33:52 (permalink)
    0
    Is the COM port connected to a laptop PC powered from an AC adaptor with a 2-pin plug?
    Yes
     
    (It's unclear from your description if "connecting" means physically plugging a cable in, or just clicking a CONNECT button in Termite)
    Apologies, the CAN stops when I hit the "CONNECT" button in termite, I can be plugged into the COM port and CAN still works fine
     
    I will try what you suggested, thank you!
    #3
    beb
    New Member
    • Total Posts : 19
    • Reward points : 0
    • Joined: 2019/11/12 13:38:42
    • Location: 0
    • Status: offline
    Re: PIC18F4580 UART Communication Interrupting CAN Transmission and Reception 2019/11/14 06:49:53 (permalink)
    0
    Try disconnecting RX and TX and see if it is just the ground connection on the COM cable causing the problem.
    Disconnecting the COM RX/TX pins fixes the issue, I can stay "connected" in termite and CAN transmits, does this mean it is a ground connection issue?
     
    edit: It seems as though if I disconnect the ground from the PCB while connected in termite, the COM data still transmits, and CAN is still interrupted, is the issue not with ground then? It seems the Rx/Tx of the COM data is interrupting the CAN

    post edited by beb - 2019/11/14 07:20:22
    #4
    crosland
    Super Member
    • Total Posts : 1696
    • Reward points : 0
    • Joined: 2005/05/10 10:55:05
    • Location: Warks, UK
    • Status: offline
    Re: PIC18F4580 UART Communication Interrupting CAN Transmission and Reception 2019/11/14 07:56:42 (permalink)
    +1 (1)
    Wk
    hat's the CAN bus connected to at the other end?
     
    Is the CAN bus terminated correctly?
     
    Do you have a ground connection in the CAN bus?
     

    It seems the Rx/Tx of the COM data is interrupting the CAN

    If that's the case then you have an issue in your code. That PIC is more than capable of handling simultaneous USART and CAN activity, unless you do something silly.
    #5
    beb
    New Member
    • Total Posts : 19
    • Reward points : 0
    • Joined: 2019/11/12 13:38:42
    • Location: 0
    • Status: offline
    Re: PIC18F4580 UART Communication Interrupting CAN Transmission and Reception 2019/11/14 08:11:35 (permalink)
    0
    The CAN bus is connected to a CAN monitoring tool:
    https://store.intrepidcs.com/neoVI-FIRE-p/neovi-fire.htm
     
    Through an OBD-II port on HS CAN, I believe the bus is terminated correctly, as CAN transmits and receives fine without using UART. 
     
    So after some more testing, if I initialize UART, but send no data (no printf statements), I still interrupt CAN when I connect with termite. The only time I can be connected through termite and have CAN working, is when I manually disconnect the UART Rx/Tx pins. 
     
    Thank you
    #6
    beb
    New Member
    • Total Posts : 19
    • Reward points : 0
    • Joined: 2019/11/12 13:38:42
    • Location: 0
    • Status: offline
    Re: PIC18F4580 UART Communication Interrupting CAN Transmission and Reception 2019/11/14 13:58:16 (permalink)
    0
    Something else interesting is happening, when I unplug my RX pin from the board, CAN works, and I can stay connected through Termite, I do get data in the COM port, but it is just random values. 
     
    I am using the PIC and a MAX233EPP chip for the UART, and I checked, my wiring seems correct.
     
    Image of wiring:
    https://ibb.co/q1PfNmd
     
    #7
    crosland
    Super Member
    • Total Posts : 1696
    • Reward points : 0
    • Joined: 2005/05/10 10:55:05
    • Location: Warks, UK
    • Status: offline
    Re: PIC18F4580 UART Communication Interrupting CAN Transmission and Reception 2019/11/16 06:11:27 (permalink)
    0
    You still haven't answered all the questions.
     
    Furthermore, if you disconnect the UART Rx/Tx pins then you are not connected.
     
    You need to distinguish between electrical conections and sending/receiving data connection.
    #8
    beb
    New Member
    • Total Posts : 19
    • Reward points : 0
    • Joined: 2019/11/12 13:38:42
    • Location: 0
    • Status: offline
    Re: PIC18F4580 UART Communication Interrupting CAN Transmission and Reception 2019/11/18 06:36:27 (permalink)
    0
    What's the CAN bus connected to at the other end?
     The CAN bus is connected to the HS CAN pins of an Intrepid CS NeoVI Fire tool
    Is the CAN bus terminated correctly?
     Yes, it is terminated correctly, using Intrepid CS's CAN monitoring tool VehicleSpy, I can read CAN traffic that is being transmitted from my PIC, and when I hit "connect" on Termite, to connect to the serial port, the CAN traffic from my PIC stops. 
    Do you have a ground connection in the CAN bus?
    Yes, the Fire is grounded to the PIC. The Fire is also powered from the PIC's 12V output. The PIC is powered using a separate power supply. The RS232 cable is grounded to the PIC as well. 
     
    If I remain connected over software (Termite), and unplug the electrical Rx pin, I start receiving data in Termite, and I see CAN data being sent in VehicleSpy, but when the electrical Rx/Tx pin are connected, I see data that makes sense in Termite, but the CAN data in VehicleSpy stops being sent. 
     
    Let me know if I need to clarify further.
    #9
    crosland
    Super Member
    • Total Posts : 1696
    • Reward points : 0
    • Joined: 2005/05/10 10:55:05
    • Location: Warks, UK
    • Status: offline
    Re: PIC18F4580 UART Communication Interrupting CAN Transmission and Reception 2019/11/18 07:41:29 (permalink)
    0
    beb
    Is the CAN bus terminated correctly?
    Yes, it is terminated correctly, using Intrepid CS's CAN monitoring tool VehicleSpy, 

    I don't know what you think a monitoring tool has to do with CAN termination.
    The CAN bus must be correctly terminated (electrically) at both ends.
     

    Do you have a ground connection in the CAN bus?
    Yes, the Fire is grounded to the PIC. The Fire is also powered from the PIC's 12V output. The PIC is powered using a separate power supply. The RS232 cable is grounded to the PIC as well. 

    I don't know what a "PIC's 12V output" is, do you? The PIC is powered separately to what?
    Is there a solid ground connection between the PIC and the "Fire"? How is that connection made? Is it in the CAN cable?
     
    #10
    beb
    New Member
    • Total Posts : 19
    • Reward points : 0
    • Joined: 2019/11/12 13:38:42
    • Location: 0
    • Status: offline
    Re: PIC18F4580 UART Communication Interrupting CAN Transmission and Reception 2019/11/18 08:15:23 (permalink)
    0
    Here is an image of the termination of CAN from the PIC (sorry for poor formatting):
     
    https://ibb.co/nmMbZSd
     
    The PIC is powered by a 12V Power Supply, there is a solid ground connection between the PIC and the Fire tool (view above image), the connection is a wire from the Fire's ground to the PIC's, the Fire has a CAN cable (OBDII) that is meant to be input into a vehicle's OBDII port, but is instead wired to the PIC directly.  
     
     
    #11
    crosland
    Super Member
    • Total Posts : 1696
    • Reward points : 0
    • Joined: 2005/05/10 10:55:05
    • Location: Warks, UK
    • Status: offline
    Re: PIC18F4580 UART Communication Interrupting CAN Transmission and Reception 2019/11/18 10:26:22 (permalink)
    0
    Where is the 120 ohm termination? It's almost certainly not in the Fire as that is designed to connect to an existing, correctly terminated CAN bus.
     
    Correct CAN termination is 120 ohm at each end of the bus. It probably doesn't matter but, until you rule it out, you can't be sure.
    #12
    Nikolay_Po
    Super Member
    • Total Posts : 1932
    • Reward points : 0
    • Joined: 2012/04/01 13:49:27
    • Location: Russia, Novorossiysk
    • Status: offline
    Re: PIC18F4580 UART Communication Interrupting CAN Transmission and Reception 2019/11/18 10:38:56 (permalink)
    0
    Will your code process the signal at UART Rx pin of a PIC microcontroller? May be your code react on the change of logic level at UART Rx? You need inspect your UART functions how it can "sense" Termite connection start?
    I suppose the UART code is behaves differently after receiving logic level change at Rx or flow control pins and blocks normal CAN operation.
    #13
    beb
    New Member
    • Total Posts : 19
    • Reward points : 0
    • Joined: 2019/11/12 13:38:42
    • Location: 0
    • Status: offline
    Re: PIC18F4580 UART Communication Interrupting CAN Transmission and Reception 2019/11/18 12:27:08 (permalink)
    0
    crosland
    Where is the 120 ohm termination? It's almost certainly not in the Fire as that is designed to connect to an existing, correctly terminated CAN bus.
     
    Correct CAN termination is 120 ohm at each end of the bus. It probably doesn't matter but, until you rule it out, you can't be sure.




    The termination is across CAN bus high and low on the OBDII connector. 
     
    Nikolay_Po
    Will your code process the signal at UART Rx pin of a PIC microcontroller? May be your code react on the change of logic level at UART Rx? You need inspect your UART functions how it can "sense" Termite connection start?
    I suppose the UART code is behaves differently after receiving logic level change at Rx or flow control pins and blocks normal CAN operation.




    Could you elaborate a bit? How would I test this?
     
     
    #14
    Nikolay_Po
    Super Member
    • Total Posts : 1932
    • Reward points : 0
    • Joined: 2012/04/01 13:49:27
    • Location: Russia, Novorossiysk
    • Status: offline
    Re: PIC18F4580 UART Communication Interrupting CAN Transmission and Reception 2019/11/18 12:52:57 (permalink)
    +1 (1)
    I believe you're don't lying when speaking that the CAN gets corrupted after your'e pressing "Connect" button in your terminal software. So the PIC somehow "knows" that connection is started. You need find how. Right?
    How many wires is connected RS-232? How could the PC change something on PIC side? Is there PC Tx connected to PIC Rx? You need to find a) which way "Connect" button can change something at PC side?
    -=-
    Or there is different problem and PIC has nothing to do? What else is connected to the CAN bus except monitoring tool and your PIC device? May be your laptop's USB controller just hangs when you start using both CAN monitor tool and USB-RS-232 adapter simultaneously?
    #15
    beb
    New Member
    • Total Posts : 19
    • Reward points : 0
    • Joined: 2019/11/12 13:38:42
    • Location: 0
    • Status: offline
    Re: PIC18F4580 UART Communication Interrupting CAN Transmission and Reception 2019/11/18 13:31:11 (permalink)
    0
    Nikolay_Po
    I believe you're don't lying when speaking that the CAN gets corrupted after your'e pressing "Connect" button in your terminal software. So the PIC somehow "knows" that connection is started. You need find how. Right?
    How many wires is connected RS-232? How could the PC change something on PIC side? Is there PC Tx connected to PIC Rx? You need to find a) which way "Connect" button can change something at PC side?
    -=-
    Or there is different problem and PIC has nothing to do? What else is connected to the CAN bus except monitoring tool and your PIC device? May be your laptop's USB controller just hangs when you start using both CAN monitor tool and USB-RS-232 adapter simultaneously?




    There are only 3 wires to RS232, Rx, Tx, and ground, the only thing connected to the CAN bus is the PIC device, also it could be my PC's USB controller, but i do not know how i would root cause that. I could ask a co-worker to try it on his PC.
    #16
    ric
    Super Member
    • Total Posts : 24638
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: offline
    Re: PIC18F4580 UART Communication Interrupting CAN Transmission and Reception 2019/11/18 14:36:21 (permalink)
    0
    Nikolay_Po
    ....So the PIC somehow "knows" that connection is started. You need find how. Right?
     
    ... You need to find a) which way "Connect" button can change something at PC side?

    This is the essence of the problem.
    What changes when you press connect?
    Does the PC's Tx line change state?
    Does it send a character?
    Something is happening that affects your PIC. It can't be that hard to find.

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #17
    beb
    New Member
    • Total Posts : 19
    • Reward points : 0
    • Joined: 2019/11/12 13:38:42
    • Location: 0
    • Status: offline
    Re: PIC18F4580 UART Communication Interrupting CAN Transmission and Reception 2019/11/19 07:07:26 (permalink)
    0
    Thanks everyone, I will try and do some digging into what happens when I press "connect" in Termite, are there any other serial monitor programs I could potentially test against this to see if this behavior happens with others?
    #18
    beb
    New Member
    • Total Posts : 19
    • Reward points : 0
    • Joined: 2019/11/12 13:38:42
    • Location: 0
    • Status: offline
    Re: PIC18F4580 UART Communication Interrupting CAN Transmission and Reception 2019/11/20 10:42:40 (permalink)
    0
    The issue is not with the serial monitoring software, I tried Termite and Arduino's serial monitor, both yielded the same result. Not sure what is happening when I am connecting to the serial port. 
     
    NOTE: It seems as though with this code, I need to initialize UART for CAN to even work, if I comment out all of the UART in my code, CAN does not seem to work at all
    post edited by beb - 2019/11/20 11:21:56
    #19
    ric
    Super Member
    • Total Posts : 24638
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: offline
    Re: PIC18F4580 UART Communication Interrupting CAN Transmission and Reception 2019/11/20 12:15:44 (permalink)
    0
    I'm going to take a wild guess here.
    Is it possible your CAN software relies upon interrupts, but has not been correctly set up to generate them itself, so it just happens to work if the USART peripheral is also generating continual interrupts?
    That would explain the "need to initialize UART for CAN to even work," and possibly some of the other strange effects.
     
    These are the sort of things that can happen when the hardware forces you to work through a single interrupt service routine.

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #20
    Page: 12 > Showing page 1 of 2
    Jump to:
    © 2019 APG vNext Commercial Version 4.5