We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi,
I'm using CAN communication on an XE164 (MultiCAN). Currently, I'm trying to use an RX FIFO and not having much luck with it. The FIFO is set up using DAVE, but when I watch in the debugger I can see that only the first slave object (BOT) is ever filled. The pointer CUR is not advanced after reception, it remains set on the BOT object. The PNEXT of the BOT object does point to the next slave object, and all other BOT/TOP pointers appear to be correct.
Can anyone figure how this might happen?
Regards, Alto Speckhardt
Thank you very much for your message. I took your code apart bit by bit, yet couldn't discover much of a difference to mine. I'm not even using an interrupt, just polling for now, so it should be even less complicated in my example.
I'm including my initialization, just in case I've become completely blind and overlooked something important. MO64 is my base object, MO65 the first slave object. The highest slave object is MO69 (not included, all following slave objects are initialized just like MO65.)
When I run the program, all reception takes place in MO69 (the last - or first, whatever - slave object). The pointer CUR in the base object points to MO69 initially, but stays there, no matter how many messages are received (all stored in MO69).
This is all DAVE-code, so I don't expect any great revelations: ;-)
/// ----------------------------------------------------------------------- /// Configuration of Message Object 64: /// ----------------------------------------------------------------------- /// General Configuration of the Message Object 64 : /// - message object 64 is valid /// - message object is used as receive object /// - this message object is assigned to list 3 (node 2) CAN_MOCTR64H = 0x00A0; // load MO64 control register high CAN_MOCTR64L = 0x0000; // load MO64 control register low /// Configuration of Message Object 64 Arbitration: /// - priority class 1; transmit acceptance filtering is based on the list /// order /// - standard 11-bit identifier /// - identifier 11-bit: 0x050 CAN_MOAR64H = 0x4140; // load MO64 arbitration register high CAN_MOAR64L = 0x0000; // load MO64 arbitration register low /// Configuration of Message Object 64 acceptance mask: /// - only accept receive frames with matching IDE bit /// - acceptance mask 11-bit: 0x7FF CAN_MOAMR64H = 0x3FFF; // load MO64 acceptance mask register high CAN_MOAMR64L = 0xFFFF; // load MO64 acceptance mask register low /// Configuration of Message Object 64 interrupt pointer: /// - use message pending register 2 bit position 0 CAN_MOIPR64H = 0x0000; // load MO64 interrupt pointer register high CAN_MOIPR64L = 0x4000; // load MO64 interrupt pointer register low /// Configuration of Message Object 64 FIFO/Gateway pointer: /// - current select pointer : MO69 /// - object select pointer : MO65 CAN_MOFGPR64H = 0x4145; // load MO64 FIFO/gateway pointer register // high /// - bottom pointer : MO69 /// - top pointer : MO65 CAN_MOFGPR64L = 0x4145; // load MO64 FIFO/gateway pointer register // low /// Configuration of Message Object 64 Function control: /// - this object is a RECEIVE FIFO BASE OBJECT /// - 8 valid data bytes CAN_MOFCR64H = 0x0800; // load MO64 function control register high CAN_MOFCR64L = 0x0001; // load MO64 function control register low /// ----------------------------------------------------------------------- /// Configuration of Message Object 65: /// ----------------------------------------------------------------------- /// General Configuration of the Message Object 65 : /// - message object 65 is valid /// - message object is used as receive object /// - this message object is assigned to list 3 (node 2) CAN_MOCTR65H = 0x00A0; // load MO65 control register high CAN_MOCTR65L = 0x0000; // load MO65 control register low /// Configuration of Message Object 65 Arbitration: /// - priority class 1; transmit acceptance filtering is based on the list /// order /// - standard 11-bit identifier /// - identifier 11-bit: 0x050 CAN_MOAR65H = 0x4140; // load MO65 arbitration register high CAN_MOAR65L = 0x0000; // load MO65 arbitration register low /// Configuration of Message Object 65 acceptance mask: /// - only accept receive frames with matching IDE bit /// - acceptance mask 11-bit: 0x7FF CAN_MOAMR65H = 0x3FFF; // load MO65 acceptance mask register high CAN_MOAMR65L = 0xFFFF; // load MO65 acceptance mask register low /// Configuration of Message Object 65 interrupt pointer: /// - use message pending register 2 bit position 1 CAN_MOIPR65H = 0x0000; // load MO65 interrupt pointer register high CAN_MOIPR65L = 0x4100; // load MO65 interrupt pointer register low /// Configuration of Message Object 65 FIFO/Gateway pointer: CAN_MOFGPR65H = 0x0000; // load MO65 FIFO/gateway pointer register // high CAN_MOFGPR65L = 0x0000; // load MO65 FIFO/gateway pointer register // low /// Configuration of Message Object 65 Function control: /// - this object is a RECEIVE FIFO SLAVE OBJECT connected to the base /// object 64 /// - 0 valid data bytes CAN_MOFCR65H = 0x0000; // load MO65 function control register high CAN_MOFCR65L = 0x0000; // load MO65 function control register low
One more note: When I manually change the pointer CUR from MO69 to, say, MO66, the reception still occurs in MO69.
Did I miss something in activating the FIFO in the first place, so that no FIFO handling takes place at all and the message is simply received by the highest priority object that has the identifier configured - which happens to be MO69?
Hum... My experience is DAVE is not always right :(
Anyway, I could try to use DAVE for a setup but don't have time until next week at the earliest to test it.
I do see a problem that you (DAVE) is setting the RXEN bit in a slave object.
/// General Configuration of the Message Object 65 : /// - message object 65 is valid /// - message object is used as receive object /// - this message object is assigned to list 3 (node 2) CAN_MOCTR65H = 0x00A0; // load MO65 control register high CAN_MOCTR65L = 0x0000; // load MO65 control register low
My code...
*dst++ = MSGVAL; /* MOCTR */
From the manual...
In order to avoid direct reception of a message by a slave message object, as if it was an independent message object and not a part of a FIFO, the bit RXEN of each slave object must be cleared. The setting of the bit RXEN is "don't care" only if the slave object is located in a list not assigned to a CAN node.
Maybe you could change this and see if you get a different behavior?
Regards, Chris
Well... ;-)
Yes, you're absolutly right! When I began to manually (after the DAVE initialization) reset the RXEN bits in the slave objects the FIFO started to work as expected.
Thank you very much indeed!