• AVR Freaks

Hot!CAN ùop

Author
josejos
New Member
  • Total Posts : 2
  • Reward points : 0
  • Joined: 2019/04/06 06:42:17
  • Location: 0
  • Status: offline
2020/04/02 09:01:41 (permalink)
0

CAN ùop

Hello,
 
I am working on the PIC18F25K83 program that receive data from the CAN bus and send's it directly back in the bus as test.
I use a small custom board with a PIC18F25K83 with the MCP2551 as the can receiver (schematic is visible in Foto1.jpg).
 
The initiation of the can module is normally ok and i used the can module in the legacy mode.
But every time when i send a can message the id and the data lenght is ok but the 8 data bytes are nok, there is data visible from a received packet.
 
I have already cleared all the buffers of the CAN module used in the legacy mode but the data i still nok.
 
I have searched whole the datasheet for any solution but i did'n find an clue for this problem
 
void initCAN(void)
{
    //----------------------------------------------------------------------------
  // Setup for the can interface
  //----------------------------------------------------------------------------
  //assign the CANTX pin to pin RB2 with the PPS register
  RB2PPS = 0b110011;
  //set CANTX as output and CANRX as input
  TRISBbits.TRISB2 = 0;
  TRISBbits.TRISB3 = 1;
  //disable the analog option on port B
  ANSELB = 0x00;
  //set the CAN module to the configuration mode (CANCON register)
  CANCONbits.REQOP2 = 1;
  CANCONbits.REQOP1 = 0;
  CANCONbits.REQOP0 = 0;
  //wait for the can module to go in configuration mode
  while(CANSTATbits.OPMODE != 0b100);
  //set the baud rate
  BRGCON1bits.BRP = 0b011111;
  //lees elke bericht ongeacht fout of acceptance
  //RXB0CONbits.RXM0 = 1;
  //RXB0CONbits.RXM1 = 1;
  //RXB1CONbits.RXM0 = 1;
  //RXB1CONbits.RXM1 = 1;
  //zet de mask op 0 zodat elk bericht door de filter passeert ook al word elk bericht ingelezen
  //RXM0SIDH = 0x00;
  //RXM0SIDLbits.SID = 0b000;
  //RXM1SIDH = 0x00;
  //RXM1SIDLbits.SID = 0b000;
  //set the can module to normal mode
  CANCONbits.REQOP = 0b000;
  //wait till the can module is in normal mode
  while(CANSTATbits.OPMODE != 0b000);
  //----------------------------------------------------------------------------
}

 
void sendCANmessage(int id, int message[8], int length)
{
    TXB2CONbits.TXREQ = 0;
      //select transmitbuffer
      CANCONbits.WIN = 0b000;
      //zet de hogoste prioriteit naar TXB0
      TXB2CONbits.TXPRI = 0b11;
      //write TXB0 register met adres van RX0D0
      TXB2D0 = 128;
      TXB2D1 = 128;
      TXB2D2bits.TXB2D2 = 128;
      TXB2D3bits.TXB2D3 = 128;
      TXB2D4bits.TXB2D4 = 128;
      TXB2D5bits.TXB2D5 = 128;
      TXB2D6bits.TXB2D6 = 128;
      TXB2D7bits.TXB2D7 = 128;
      
      TXB1D0 = 128;
      TXB1D1 = 128;
      TXB1D2 = 128;
      TXB1D3 = 128;
      TXB1D4 = 128;
      TXB1D5 = 128;
      TXB1D6 = 128;
      TXB1D7 = 128;
      
      TXB0D0 = 128;
      TXB0D1 = 128;
      TXB0D2 = 128;
      TXB0D3 = 128;
      TXB0D4 = 128;
      TXB0D5 = 128;
      TXB0D6 = 128;
      TXB0D7 = 128;

      RXB0D0 = 128;
      RXB0D1 = 128;
      RXB0D2 = 128;
      RXB0D3 = 128;
      RXB0D4 = 128;
      RXB0D5 = 128;
      RXB0D6 = 128;
      RXB0D7 = 128;
      
      RXB1D0 = 128;
      RXB1D1 = 128;
      RXB1D2 = 128;
      RXB1D3 = 128;
      RXB1D4 = 128;
      RXB1D5 = 128;
      RXB1D6 = 128;
      RXB1D7 = 128;
      
   
      
      //laad het adres in
      TXB2SIDLbits.SID = id;
      TXB2SIDH = id >> 3;
      //zet data length to 1
      TXB2DLCbits.DLC = 0b111;
      TXB2DLCbits.TXRTR = 1;
      //request een zend actie bij de can module
      TXB2CONbits.TXREQ = 1;
      //wait till the message is sent
      while(TXB2CONbits.TXREQ == 0);
     
}

 
kind regards
Alexander
 
 

Attached Image(s)

#1

8 Replies Related Threads

    NJT
    Starting Member
    • Total Posts : 31
    • Reward points : 0
    • Status: offline
    Re: CAN ùop 2020/04/02 16:25:10 (permalink)
    0
    Alexander, 
     
    The fact that you have proper CAN functionality and can see proper ID and DLC indicates that you are doing most everything correctly, and I can't see any obvious issues in your code offhand.  In your example code (which I'm guessing is a debug test) you're sending 128 for each of the data bytes, what values are you seeing instead of 128 on the output?

    "In the beginning, the universe was created.  
    This has made a lot of people very angry and been widely regarded as a bad move." 
    -Douglas Adams
    #2
    pcbbc
    Super Member
    • Total Posts : 1687
    • Reward points : 0
    • Joined: 2014/03/27 07:04:41
    • Location: 0
    • Status: offline
    Re: CAN ùop 2020/04/02 19:04:37 (permalink)
    +1 (1)
     
          //write TXB0 register met adres van RX0D0
     
          TXB2D0 = 128;
          TXB2D1 = 128;
          TXB2D2bits.TXB2D2 = 128;
          TXB2D3bits.TXB2D3 = 128;
          TXB2D4bits.TXB2D4 = 128;
          TXB2D5bits.TXB2D5 = 128;
          TXB2D6bits.TXB2D6 = 128;
          TXB2D7bits.TXB2D7 = 128;

    Am I missing something????  Why the “bits” union fields for D2 through D7????
     
    DoesTXB2D2bits.TXB2D2 represent the whole register byte, or just bit D2 of byte B2?
     
    If just a bit, what does setting a bit field to 128 actually even do? I assume it would get truncated? So same as setting zero? The other bits in the register would remain unchanged.
          
    Edit: Say what data you are expecting, and what data you are actually seeing. Just “not okay” doesn’t help us much.
       
          
       
       
    post edited by pcbbc - 2020/04/02 19:08:04
    #3
    ric
    Super Member
    • Total Posts : 26942
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: CAN ùop 2020/04/02 19:31:40 (permalink)
    +1 (1)
    pcbbc
    Am I missing something????  Why the “bits” union fields for D2 through D7????

    Good catch.
    Is that the real code?
    Those precise bit names do not exist.
    The definition of that structure is:
    typedef union {
        struct {
            unsigned TXB2D2                 :8;
        };
        struct {
            unsigned TXB2D20                :1;
            unsigned TXB2D21                :1;
            unsigned TXB2D22                :1;
            unsigned TXB2D23                :1;
            unsigned TXB2D24                :1;
            unsigned TXB2D25                :1;
            unsigned TXB2D26                :1;
            unsigned TXB2D27                :1;
        };
    } TXB2D2bits_t;

     

    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!
    #4
    pcbbc
    Super Member
    • Total Posts : 1687
    • Reward points : 0
    • Joined: 2014/03/27 07:04:41
    • Location: 0
    • Status: offline
    Re: CAN ùop 2020/04/02 19:38:06 (permalink)
    +1 (1)
    Ric - Ah but then entire 8 bit byte is defined in the structure as TXB2D2.
    So the code presented is the same as writing the entire byte, and it’s just a red herring.
    You can see why it had me confused though.
    #5
    ric
    Super Member
    • Total Posts : 26942
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: CAN ùop 2020/04/02 19:40:34 (permalink)
    +1 (1)
    Me too. I misread the structure name as "TXB2D2bits" in all the subsequent lines.
     

    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!
    #6
    pcbbc
    Super Member
    • Total Posts : 1687
    • Reward points : 0
    • Joined: 2014/03/27 07:04:41
    • Location: 0
    • Status: offline
    Re: CAN ùop 2020/04/02 19:47:07 (permalink)
    +1 (1)
    No idea why the OP coded it that way.
    I can only assume they we trying random s#!t in an attempt to get it to work, and forgot to remove before posting.... wink: wink
     
    Really need OP to say what the are expecting and what they are actually receiving.
    As NJT indicates the fact they are receiving something, but not what they expect, is unusual. There would appear no obvious reason for that, other than misunderstanding of what is expected.
    #7
    josejos
    New Member
    • Total Posts : 2
    • Reward points : 0
    • Joined: 2019/04/06 06:42:17
    • Location: 0
    • Status: offline
    Re: CAN ùop 2020/04/03 14:05:33 (permalink)
    +1 (1)
    Hello everyone,
     
    Thanks for the reply's.
     
    @Ric, yes i have tested different methods to set the TXB registers of the can controller to make sure that this is not the problem like pcbbc said :)
     
    I have worked on the problem today and i take a deeper look in the CAN signal (measured with the oscilloscope) to understand the strange behaviour. The data i gathered from the original thread was received by an mbed microcontroller.

    At the moment i don't have a decoding license for the CAN signals so i decoded the data with the hand.
     
    Raw data send over the can bus as seen on the scope image:
    00000 10000 01011 00011 10000 01100 01010 1110
    After removing the stuffing bits:
    00000 00000 01100 01110 00001 00010 01110 0
     
    • SOF (start of frame) = 0 OK
    • ID = 1 OK
    • RF = 1 NOK ?
    • ...
    I setted the Remote frame bit high so there was no data placed in the frame.
    After setting this bit low, the problem was solved :)
     
    Regards Alexander
    #8
    pcbbc
    Super Member
    • Total Posts : 1687
    • Reward points : 0
    • Joined: 2014/03/27 07:04:41
    • Location: 0
    • Status: offline
    Re: CAN ùop 2020/04/03 23:24:16 (permalink)
    0
    PICNIC / PEBKAC
    Glad you are sorted.
    #9
    Jump to:
    © 2020 APG vNext Commercial Version 4.5