Hello !
I have some trouble with the FlexCAN on ColdFire, hope someone can help me out
Sometimes the FlexCAN sends multiple frames on to the network even though we only send one frame by the CAN driver (we are using the drivers supplied with CodeWarrior). This seems to happened randomly it could work fine a long time then suddenly all frames sent are duplicated.
We have also seen bursts of messages (with the same message) causing 100% busload.
Have done a lot of debugging, for example a breakpoint at the start of the send service in the CAN driver and a breakpoint at the end i can see that 2 frames are sent at each call to the send routine.
However if i set another breakpoint just after writing 0xC to the CODE field then only one frame is sent.
Anyone have an idea of what could be wrong? I have not found any errata on this problem.
I supply the send service in the driver, we are only using one mailbox for TX.
int8 FlexCANSendDataPoll(uint8 *pData, uint8 u8Size, uint32 u32ID, uint8 u8MB)
{
uint8 u8Counter;
uint8 *pDataPointer;
uint32 u32Rescue = 0;
tFlexCANMB *BuffPtr;
uint16 temp = 0;
/*Set the buffer pointer*/
BuffPtr = &MCF_FLEXCAN_BUFFERS.MB0 + u8MB;
(*BuffPtr).u16CtrlStat = MB_CTRLSTAT_CODE(0x8);
if (!(u32ID & FLEXCAN_EXTENDEDID(0)))
{
/* Standard ID */
(*BuffPtr).u32ID.u32ExtID = MB_STANDARD_ID(u32ID);
}
else
{
(*BuffPtr).u32ID.u32ExtID = MB_EXTENDED_ID(u32ID - FLEXCAN_EXTENDEDID(0));
temp |= (MB_CTRLSTAT_SRR | MB_CTRLSTAT_IDE);
}
pDataPointer = &((*BuffPtr).u8Data0);
for (u8Counter = 0; u8Counter < u8Size; u8Counter++)
{
*(pDataPointer++) = *(pData++);
}
temp |= MB_CTRLSTAT_LENGTH(u8Size);
(*BuffPtr).u16CtrlStat = MB_CTRLSTAT_CODE(0xC) | temp;
while(!(MCF_FlexCAN_IFLAG & (1<<u8MB)))
{
if (u32Rescue++ == RESCUE_VALUE)
return 0;
}
/* Clear interrupt flag */
MCF_FlexCAN_IFLAG = (1<<u8MB);
return 1;
}
Hello, I have the same problem about FlexCan. I notice that if I don't use PLL then EXTAL works fine. If I use PLL and FlexCan with the EXTAL doesn't woks fine. Always with the same cpu speed.
I also see that it doen't happen if you freeze the bus previous to made the changes to send, independent of the PLL or EXTAL for FlexCan.
¿ What clock uses the arbitration sequence ? ¿ The selected clock or always FSys/2 ?
Regards.
Hello,
Now it woks fine !!
If you use EXTAL for FlexCan, 48MHz and PLL for CPU with the same speed 48MHz, there will be problems with frames send twice.
If you use EXTAL for FlexCan and PLL up to 66, 80 MHz works fine. It seems a problem with the sync beetween Flexcan frequency and FSys.
For this reason when I didn't use the PLL (same EXTAL clock for FSys and FlexCan works fine).
¿ Is that right ?
Thanks !!
That looks like something that should be in the Errata for this chip.
Except I can't find any errata documents for the MCF5225x chips on Freescale's sites. Anyone know where they are?
Hello sir,
It seems I'm running into the same problem as you, but in my case the frames are sent once or many times (more than 50), depending of the data. In that case, the ERRCNT is increasing and BIT1ERR bit is set, as BUS OFF (but interrupt disabled) bit. The thing I can't understand is why does it depend of the data I'm sending? For example, 0x.........BB works fine, but 0x.........CC is sent many times. Do you think it can be somethink like you?
OK, Thanks Kan.
I never get any error flags and no error frames are sent.
However i changed the clock source from EXTAL to system clock and now it seems to work.
I was able to run all my test suites without any duplicate frames or 100% load.
Could my previous problems have been caused by a bad EXTAL ???????
Not familiar with FlexCAN, but sounds like sometimes your node detects errors and retransmits messages twice or more times.
Liljo wrote:Sometimes the FlexCAN sends multiple frames on to the network even though we only send one frame by the CAN driver (we are using the drivers supplied with CodeWarrior). This seems to happened randomly it could work fine a long time then suddenly all frames sent are duplicated.
We have also seen bursts of messages (with the same message) causing 100% busload.