[RTEMS Project] #4983: MCAN fail on arm/samV71 bsp in RTEMS 5.3
RTEMS trac
trac at rtems.org
Tue Jan 16 11:05:23 UTC 2024
#4983: MCAN fail on arm/samV71 bsp in RTEMS 5.3
-----------------------+----------------------------
Reporter: Dario | Owner: (none)
Type: defect | Status: new
Priority: high | Milestone:
Component: bsps | Version: 5
Severity: critical | Keywords: MCAN on SAMV71
Blocked By: | Blocking:
-----------------------+----------------------------
Hi expert.
I have found a big problem regarding internal SAMV71 MCAN module (the
code is unchanged regards RTEMS 6 then I think it should to be present
also in that version) running on SAM V71 XPLAINED ULTRA EVALUATION KIT.
The problem is present in RX direction. I use FIFO functionality, I have
configured 32 buffer in FIFOs, when I receive the 33th message, the packet
is invalid (I think it is repeated one), follow you can see a couple of 15
messages that should to be identically, idx is buffer position in FIFO:
idx=4 MCAN Rx Fifo 0 data: 0x00 0x64 0x53 0x00 0x01 0x02 0x03 0x04
idx=5 MCAN Rx Fifo 0 data: 0x01 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B
idx=6 MCAN Rx Fifo 0 data: 0x02 0x0C 0x0D 0x0E 0x0F 0x10 0x11 0x12
idx=7 MCAN Rx Fifo 0 data: 0x03 0x13 0x14 0x15 0x16 0x17 0x18 0x19
idx=8 MCAN Rx Fifo 0 data: 0x04 0x1A 0x1B 0x1C 0x1D 0x1E 0x1F 0x20
idx=9 MCAN Rx Fifo 0 data: 0x05 0x21 0x22 0x23 0x24 0x25 0x26 0x27
idx=10 MCAN Rx Fifo 0 data: 0x06 0x28 0x29 0x2A 0x2B 0x2C 0x2D 0x2E
idx=11 MCAN Rx Fifo 0 data: 0x07 0x2F 0x30 0x31 0x32 0x33 0x34 0x35
idx=12 MCAN Rx Fifo 0 data: 0x08 0x36 0x37 0x38 0x39 0x3A 0x3B 0x3C
idx=13 MCAN Rx Fifo 0 data: 0x09 0x3D 0x3E 0x3F 0x40 0x41 0x42 0x43
idx=14 MCAN Rx Fifo 0 data: 0x0A 0x44 0x45 0x46 0x47 0x48 0x49 0x4A
idx=15 MCAN Rx Fifo 0 data: 0x0B 0x4B 0x4C 0x4D 0x4E 0x4F 0x50 0x51
idx=16 MCAN Rx Fifo 0 data: 0x0C 0x52 0x53 0x54 0x55 0x56 0x57 0x58
idx=17 MCAN Rx Fifo 0 data: 0x0D 0x59 0x5A 0x5B 0x5C 0x5D 0x5E 0x5F
idx=18 MCAN Rx Fifo 0 data: 0x0E 0x60 0x61 0x62 0x63 0xA9
idx=19 MCAN Rx Fifo 0 data: 0x00 0x64 0x53 0x00 0x01 0x02 0x03 0x04
idx=20 MCAN Rx Fifo 0 data: 0x01 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B
idx=21 MCAN Rx Fifo 0 data: 0x02 0x0C 0x0D 0x0E 0x0F 0x10 0x11 0x12
idx=22 MCAN Rx Fifo 0 data: 0x03 0x13 0x14 0x15 0x16 0x17 0x18 0x19
idx=23 MCAN Rx Fifo 0 data: 0x04 0x1A 0x1B 0x1C 0x1D 0x1E 0x1F 0x20
idx=24 MCAN Rx Fifo 0 data: 0x05 0x21 0x22 0x23 0x24 0x25 0x26 0x27
idx=25 MCAN Rx Fifo 0 data: 0x06 0x28 0x29 0x2A 0x2B 0x2C 0x2D 0x2E
idx=26 MCAN Rx Fifo 0 data: 0x07 0x2F 0x30 0x31 0x32 0x33 0x34 0x35
idx=27 MCAN Rx Fifo 0 data: 0x08 0x36 0x37 0x38 0x39 0x3A 0x3B 0x3C
idx=28 MCAN Rx Fifo 0 data: 0x09 0x3D 0x3E 0x3F 0x40 0x41 0x42 0x43
idx=29 MCAN Rx Fifo 0 data: 0x0A 0x44 0x45 0x46 0x47 0x48 0x49 0x4A
idx=30 MCAN Rx Fifo 0 data: 0x0B 0x4B 0x4C 0x4D 0x4E 0x4F 0x50 0x51
idx=31 MCAN Rx Fifo 0 data: 0x0C 0x52 0x53 0x54 0x55 0x56 0x57 0x58
**idx=0 MCAN Rx Fifo 0 data: 0x00 0x14 0x33 0x00 0x01 0x02 0x03 0x04**
idx=1 MCAN Rx Fifo 0 data: 0x0E 0x60 0x61 0x62 0x63 0xA9
The first data byte is the internal sequence number (0x00 - 0x0E)
If I reduce the fifo lenght the problem is present in
(MCAN1_NMBR_RX_FIFOx_ELMTS - 1) fifo element, the problem is present in
polling mode and in interrupt mode.
I have seen the Microchip reference code found in
https://github.com/Microchip-MPLAB-
Harmony/csp_apps_sam_e70_s70_v70_v71.git
bool MCAN1_MessageReceiveFifo(MCAN_RX_FIFO_NUM rxFifoNum, uint8_t
numberOfMessage, MCAN_RX_BUFFER *rxBuffer)
{
uint8_t rxgi = 0U;
....
switch (rxFifoNum)
{
case MCAN_RX_FIFO_0:
/* Read data from the Rx FIFO0 */
rxgi = (uint8_t)((MCAN1_REGS->MCAN_RXF0S &
MCAN_RXF0S_F0GI_Msk) >> MCAN_RXF0S_F0GI_Pos);
for (count = 0U; count < numberOfMessage; count++)
{
rxFifo = (uint8_t *) ((uint8_t
*)mcan1Obj.msgRAMConfig.rxFIFO0Address + ((uint32_t)rxgi *
MCAN1_RX_FIFO0_ELEMENT_SIZE));
(void) memcpy(rxBuf, rxFifo, MCAN1_RX_FIFO0_ELEMENT_SIZE);
if ((count + 1U) == numberOfMessage)
{
break;
}
rxBuf += MCAN1_RX_FIFO0_ELEMENT_SIZE;
rxgi++;
**if (rxgi == 1U)
** {**
** rxgi = 0U;**
}**
}
/* Ack the fifo position */
MCAN1_REGS->MCAN_RXF0A = MCAN_RXF0A_F0AI((uint32_t)rxgi);
status = true;
break;
....
}
return status;
}
I suppose there are a different handling on the first buffer.
I hope the description is clear enought.
Best regards,
Dario
--
Ticket URL: <http://devel.rtems.org/ticket/4983>
RTEMS Project <http://www.rtems.org/>
RTEMS Project
More information about the bugs
mailing list