RM48L952: CAN IF3 problem

Hi,

I am forwarding this issue to our CAN expert, and he will update you soon.

--

Thanks & Regards,

Jagadish.

Hi,

The IF3 registers (data, arbitration, control) can automatically be updated with received message objects which are specified in CAN IF3x update registers. Those objects should have the same message ID and MASK setting. The # of message object is not copied to IF1x/IF2x and IF3x registers. 

영호 안 said:

1. When receiving data from Notification using CAN IF3, IF3 does not change the value of CAN interrupt register, so the data cannot be distinguished by checking the message box number. Is this characteristic of IF3? Or is it the wrong result?

As mentioned earlier, the IF3x registers can be updated automatically and DMA request is generated if DE3 is enabled. Is this feature enabled in your project? 

If you want to use polling mode, you can check the IF3Upd flag to determine if there is new IF3 content ready.

Let me double check today.

영호 안 said:

1. When receiving data from Notification using CAN IF3, IF3 does not change the value of CAN interrupt register, so the data cannot be distinguished by checking the message box number. Is this characteristic of IF3? Or is it the wrong result?

If CAN2 IF3x is used, the CAN2 RX interrupt should be disabled.

The NewDat bit in the message object will be reset by a transfer to IF3. If CAN RX interrupt is enabled, the code will be checking the newDat flag forever.

You can use either IF3 interrupt to read data from IF3x data registers, or use polling mode (checking IF3Upd flag in IF3OBS) to read the data from IF3x data registers, or use DMA to transfer data from IF3x data registers to SRAM automatically.

To use IF3x interrupt, please select channel 46 of VIM vector table for CAN2 IF3x and set DE3 bit of CAN2 CTL register:

// Enable DE3 bit in CTL register to trigger DMA when IF3 receives data
canREG2->CTL |= (1U << 20U);

After data of message object is copied to IF3x data registers, the IF3Upd flag is set. 

영호 안 said:

2. And to classify data using IF3, I tried to classify data by looking at the ID of the IF3 ARB register.
At this time, the ID value of the ARB register was not reset, so there was a phenomenon that the receive interrupt works even though it is a transmit interrupt. In conclusion, I added the condition "When the message box number is 0" to the condition, but I do not understand this phenomenon.

To get the ID updated, the ARB bit of IF3OBS register needs to be set.

for example, canREG2->IF3OBS = 0x1F;

영호 안 said:

3. If IF3 does not receive the message box number value of CAN interrupt register, how should the data be classified when receiving data using IF3 in Notification?

The message ID should be used instead of # of mailbox.

As a result of testing, RX interrupt is not generated if RX interrupt is disabled when using IF3. The reason is that 44, 46, 60 of VIM Channel = IF3 of CAN1, 2, 3, but even if they are enabled, the interrupt code is not generated in sys_vim.c, so the code does not work with Notification. Therefore, it is not right to disable the RX interrupt by using IF3.
What I am curious about is the phenomenon that the message box number is not enabled in bits 0~23 of DCAN INT (CAN Interrupt register) when data is received using IF3 rather than DMA.
For this reason, message = 0U occurred because there was no message box number when receiving data when using IF3.
I wonder if this phenomenon is normal or abnormal.
If this is a normal operation and it is designed to operate like this, I wonder why the IF3 is designed so that it cannot distinguish the message box number when receiving.
And I wonder why the interrupt code is not generated even when VIM Channel 44, 46, 60 (CAN1, 2, 3 IF3) is enabled.

영호 안 said:

As a result of testing, RX interrupt is not generated if RX interrupt is disabled when using IF3. The reason is that 44, 46, 60 of VIM Channel = IF3 of CAN1, 2, 3, but even if they are enabled, the interrupt code is not generated in sys_vim.c, so the code does not work with Notification. Therefore, it is not right to disable the RX interrupt by using IF3.

HAL doesn't give the ISR handler for channel 44/46/60. You have to define the ISR handler for those channels. The interrupt flag is IF3Upd in IF3OBS register:

This is my example code for can2IF3UpdateInt ISR handler. This handler will be called after data of message object is copied to IF3x data registers.

#pragma CODE_STATE(can2IF3UpdateInterrupt, 32)
#pragma INTERRUPT(can2IF3UpdateInterrupt, IRQ)

void can2IF3UpdateInterrupt(void)
{
uint32 value = (canREG2->IF3OBS & 0x9800) >> 8;
uint8 * pData = rx_data;
uint32 i;

if (value == 0x98U)
{
for (i = 0U; i < 8; i++)
{
#if ((__little_endian__ == 1) || (__LITTLE_ENDIAN__ == 1))
/*SAFETYMCUSW 45 D MR:21.1 <APPROVED> "Valid non NULL input parameters are only allowed in this driver" */
*rx_ptr = canREG2->IF3DATx[i];
/*SAFETYMCUSW 45 D MR:21.1 <APPROVED> "Valid non NULL input parameters are only allowed in this driver" */
rx_ptr++;
#else
/*SAFETYMCUSW 45 D MR:21.1 <APPROVED> "Valid non NULL input parameters are only allowed in this driver" */
*rx_ptr = canREG2->IF3DATx[s_canByteOrder02[i]];
/*SAFETYMCUSW 45 D MR:21.1 <APPROVED> "Valid non NULL input parameters are only allowed in this driver" */
rx_ptr++;
#endif
}
}
}

영호 안 said:

For this reason, message = 0U occurred because there was no message box number when receiving data when using IF3.
I wonder if this phenomenon is normal or abnormal.

For processing the received CAN data, the messageID is enough to determine where the message from. 

영호 안 said:

If this is a normal operation and it is designed to operate like this, I wonder why the IF3 is designed so that it cannot distinguish the message box number when receiving.

The data, arbitration and mask of the selected message objects (IF3UPDxx register) is transferred to IF3x registers (data, arb, and mask) automatically. Unlike using IF1 and IF2, you need to write message number to IF1CMD or IF2CMD register to initiate the data transfer from message object to IF1 or IF2 registers.

영호 안 said:

And I wonder why the interrupt code is not generated even when VIM Channel 44, 46, 60 (CAN1, 2, 3 IF3) is enabled.

1. configure CAN IF3 registers:

// Enable DE3 bit in CTL register to trigger DMA and IF3 Interrupt when IF3 receives data
canREG2->CTL |= (1U << 20U);

// Read DATA A & B, ARB and MASK */
canREG2->IF3OBS = 0x1F;

// Message box 0/1/2/3/4 configured for auto update
canREG2->IF3UEy[0]= 0x00000F; //4 mailboxes

2. Enable VIM channel 46 (IF3 ), and write your own ISR as my example

There is nothing in the datasheet that says DCAN INT is not used when receiving data as IF3.
So I couldn't decide which method I was using was the right one.
But thanks to you, I solved it. Thanks for teaching.

I made an ISR handler for CAN1 IF3. However, even though both IF3 UEy and OBS were enabled, the CAN1 IF3 ISR handler did not trigger an interrupt.
Is it a problem to enable CAN1 High because CAN1 also has a TX transmission role?
In CAN1HighlevelInterrupt, interrupt works for both sending and receiving, but I don't know why the CAN1 IF3 ISR handler I made doesn't work.

Is DE1 in CTL register enabled? 

The DCAN1 IF3 channel in VIM vector table should be enabled too.

Add the ISR name (can1IF3UpdateInterrupt) to channel 44 of VIM RAM:

Added CAN1 IF3 ISR to VIM RAM and enabled IF3 channel in VIM vector table.
I know that DE1 bit in CAN control register enables IF1 when connecting DMA request line. Is it related to IF3 ISR?
I am attaching my project. This project was tested on an EVM board.

20221109_CAN1_2_TEST.zip

Thank you for answer. As a result of testing, I found that it worked as I wanted.
In the data sheet, DE1, DE2, and DE3 Bits were only described as DMA request line enable, so I did not know they had to be enabled when using the IF3 ISR handler.
Thank you for your valuable time.