eCAN in Self-test mode

You cannot sent a message and receive it with the same CAN-node, it is a base rule of CAN arbitration. It means, you will need a 2nd device or a 2nd CAN - interface, as it has been shown in the Back2Back - example with CANA and CANB of the same device.

Regards

While this is true for normal operation, you actually can send and receive at the same node in the "self-test" mode, as is true with other types of CAN controllers. In the self-test mode the CAN acknowledge normally generated from another node is also generated internally. You do need to have a valid baud rate set up and if connected to an actual CAN bus it should be operating at the same baud rate as any other devices on the bus. 

Cheers

Hello Frank,

In Back2Back example is used only eCAN-A module, Mailboxes 0-31:

"MBX0 transmits to MBX16, MBX1 transmits to MBX17 and so on.... This program illustrates the use of self-test mode".

Best regards,

Pawel

Pawel,

sorry if I have confused you, but I  thought the Back2Back - example was setup between CANA and CANB. My fault.

There must be something else, which prevents your code to run properly in LAM - mode.

Some comments:

1. ECanaMboxes.MBOX0.MSGCTRL.bit.DLC = 8; // 8 bytes

what happens wit the remaining bits of MSGCTRL ?   You cannot rely on all remaining bits to be zero, they are random after a reset. Try to change that by first clearing the whole register and then set DLC to 8.

2.  ECanaMboxes.MBOX0.MSGID.all = 0x90000001;

Your comment says that you use ID = 1000 0000 but the code set the ID to 1000 0001.

3. ECanaLAMRegs.LAM1.all = 0x10000000; and ECanaMboxes.MBOX1.MSGID.all = 0xD0000000;

This mask will allow  messages 0x0000 0000 and 0x1000 0000 to pass into Mailbox 1, which means that the message from Mailbox0 ( 0x1000 0001) will not fit.

4. What is the content of your function "mailbox_read(1)"?  Do you poll the RMP register?

Regards

Thanks for your reply Frank,

Ad 1. You have right - firstly I can't change only three bits - I should operate on 32-bits register - I will fix it and write is this helps

Ad 2. I said I am changing values of MSGID - I didn't change comment, but I know it is 1000 0001

Ad 3. I know LAM register shoudn't pass my message with 1000 0001 ID - and here is a problem - sent message is always received - even if I change MSGID - messages with each ID are received by my msgbox

Ad 4. mailbox_read() function only check what is inside MSGBOX1 and save this data in global variables, which I can watch in Watch Window. Here is a source code of this function

void mailbox_read(int16 MBXnbr)

{

   volatile struct MBOX *Mailbox;

   Mailbox = &ECanaMboxes.MBOX0 + MBXnbr;

   TestMbox1 = Mailbox->MDL.all; // = 0x9555AAAn (n is the MBX number)

   TestMbox2 = Mailbox->MDH.all; // = 0x89ABCDEF (a constant)

   TestMbox3 = Mailbox->MSGID.all;// = 0x9555AAAn (n is the MBX number)

}

As you can see, I am not working with RMP register - but whether it may be related with receiving all messages independly of message ID?

Best regards,

Pawel Blaszczyk

Pawel,

I think it is not a good solution to read the receive mailboxes "blind" as you do in your function mailbox_read. Instead, use a polling method for RMP or even better an mailbox receive interrupt.

Polling: The corresponding "Receive Message Pending" (RMP) bit will be set to 1 in  the event of a correct received message. Only at that time I would read the mailbox to make sure to read the correct data. I am not sure how the self test works internally, but there might be the chance of a small time delay between transmit acknowledge and message received.

Regards

I changed my program (RMP register is used) but still all messages which I send from MSGBOX0 I am receiving on MSGBOX1. As you said - I will try with interrupts.

I think I found solution - in self-test mode each sent message has to be received - if no any box can receive message it is stored in first free message box configured as receiver - I changed my program by creating two receive MBOXes with different ID:

ECanaMboxes.MBOX16.MSGID.all = 0xD0000000;

ECanaLAMRegs.LAM16.all = 0x10000000;

ECanaMboxes.MBOX17.MSGID.all = 0xD000000F;

ECanaLAMRegs.LAM17.all = 0x10000000;

Now, when I change MSGID in transmitt box:

ECanaMboxes.MBOX16.MSGID.all = 0xD0000000;

Then message is received by MBOX16 (for 1000 0000 ID), or by MBOX17 (for 1000 000F ID). For another ID - message is always received by MBOX17 (first receive MBOX - MBOXes are checked from 31 to 0)

Thanks for your interest,

Pawel Blaszczyk

Dear Frank,

I do not know if this is the right place to put this message, but I prefer to put it here than open a new discussion.

I think the file  Example_2833xECanBack2Back.c (v131) has two little mistakes.

The first mistake is when checking reception mailboxes:

       for(j=0; j<16; j++)         // Read & check 16 mailboxes
       {
          mailbox_read(j);         // This func reads the indicated mailbox data
          mailbox_check(TestMbox1,TestMbox2,TestMbox3); // Checks the received data
       }

Mailboxes 0 to 15 are transmission maiboxes. So the programme is cheking transmission mailboxes instead of reception mailboxes. 

To check reception mailboxes (mailboxes 16 to 31), the correct routine will be

       for(j=16; j<32; j++)         // Read & check 16 mailboxes
       {
          mailbox_read(j);         // This func reads the indicated mailbox data
          mailbox_check(TestMbox1,TestMbox2,TestMbox3); // Checks the received data
       }

The second little mistake is that interrupts are enabled and it is not neccessary for this example. So, the following lines can be commented

    //EALLOW;
    //ECanaRegs.CANMIM.all = 0xFFFFFFFF;

Are you agree with it?

Francesco,

two points for you. Yes, you are right and the example is indeed not working.  TI have corrected these errors in the latest examples for the F28069  (see. C:\TI\controlSUITE\device_support\f2806x\v115\F2806x_examples\ecan_back2back) , but somehow they missed to update the other device examples... 

I am not the author of these examples, but if TI follows this thread, I am sure they will make a note for a revision. I personally did not use the selftest examples because I prefer the use of real physical communication examples between different CAN nodes.

Thanks a lot.

All,

We are following this thread ;)

I will make a note to get this fixed in the other device support releases.

Trey German