can overwritten failed: updating message object

Hello Jays

user4076341 said:

CANMessageSet() to get data send.

CANMessageSet is to set the data for transmission and not to get the data

To understand the issue better, You plan to send Msg-A, and if the bus is lost then Msg-B must be sent, but instead Msg-A goes through?

Regards

Amit

we do a test like avalanche:so the nodes send frm almost at the same time.

as to a specific node, it can send frame A/B and about 2ms later the last frame shall be repeated. frame B maybe not exist if A has enough information, like not all snow move at the same time, B have more information than A, a C may exist in fact if unlucky... In case of data lost, the last send shall be repeated(named as A1 B1).

So the test shall see A-A1 if no B exist, or B-B1 if A was overwritten(updated by frame B) and the case just like A-A1 which can not be distinguished, or A-B-B1 when A get the bus. Most tests run ok, but A-B1 can be seen on the bus which show the fact that B lost.

Hello Jays,

I think I am confused by the barrage of A's and B's. Can you please share your application code and indicate which message is A, B, A1 and B1

Regards
Amit

as to a specific can node, it send first frame data named as A, if no new data shall be send, it will send A again named as A1, so if the receiver side lost A, it can get A1 which is the same as A.

If new data produced before A1 or while A is sending since node can fail to send, new frame named B shall overwritten A since B is new and A is old. Also, if no new data produced, there shall have a B1 to be send, otherwise a C shall be send which may overwritten B as well.

Hello Jays,

Is auto retransmission enabled in your application code for CAN? Also how is the application code ensuring that the CAN controller is Idle and not transmitting any data that may cause the next message to be missed.

Regards
Amit

yes, auto retransmission enabled.

Application don't care about controller idle or not, just calling canmessageset api which shall check.

I forget to mention that the repeated send frames' id set a bit to make it be distinguished, also lower it's priority in senging.

Hello Jays,

"Application don't care about controller idle or not, just calling canmessageset api which shall check."

I think this is not the method by which the CAN controller would work. Not knowing which message is being sent adding or updating messages while in the buffer may lead to incorrect transmissions. You would need to make the application "smarter" to check the CAN state when sending messages that are being updated.

Regards
Amit

"cpu may update the data bytes any time", datasheet clearly tell that.

Application call canmessageset() to send A, then again send B if new data produced using the same message object.

I don't know wherez problem u point....

Hello Jays

I would again request you to share the application code as mentioned in my earlier post.

Regards
Amit

I'm with Amit on this. It sounds like you are trying to update the message while it is sending even if the h/w has a double buffer to allow this I'm a good deal less certain the API accommodates such use.

Cyclic updates are common on CAN, I use them myself. The way they are usually done though would not cause your symptoms. Indeed your symptoms sound like you either have a noisy bus or you have overloaded it.

Robert

app data send by two ways: 1, check if the specified message object used or not, if being used, then wait; or data send to message object; 2, do not check the specified the message object used, just updating data, which discussed here and find the problem.

Here's the code:

/* Send data directly without checking if any data in can hardware
* message object buffer! So old data maybe written by new data.
*
* Param:
* ucPri - priority used for transfering
* ucDst - destion address
* ucSrc - source address
* bRpFlag - flag show if frame is first or repeat
* ucLen - data length
* pucPck - data buffer
*
* return: none.
*/
void SendFrmDirect(uint8_t ucPri, uint8_t ucDst, uint8_t ucSrc,
BOOL bRpFlag, uint8_t ucLen, uint8_t *pucFrm)
{
tCANMsgObject MsgObj;
uint8_t ucObjId = s_ucTxMsgIdSt[ucPri];//get according message object ID
MSG_ID tMsgId;

MsgIdSet(&tMsgId, ucPri, ucDst, ucSrc, bRpFlag);
MsgObj.ulMsgID = tMsgId.ulDat;

MsgObj.ulMsgLen = ucLen;
MsgObj.pucMsgData = pucFrm;
MsgObj.ulFlags = MSG_OBJ_TX_INT_ENABLE;

HWREGBITB(&s_ucPriMsgSend, ucPri) = 1; //flag according message object being used

CANMessageSet(CAN0_BASE, ucObjId, &MsgObj, MSG_OBJ_TYPE_TX);
}

Hello Jays

That is what myself and Robert and inclining towards. In the case-2, if you do not check for the message state and update the message object, the result cannot be guaranteed.

Regards
Amit

You all said to the point: the test is an extreme condition where bus is noisy at the time. We know that there maybe data lost, old data lost is acceptiable, but new data shall not!

My concern is about the data lost where the datasheet said there's way to avoid it, my first post cited these words:

In order to only update the data in a message object, the WRNRD, DATAA and DATAB bits in the
CANIFnMSKn register are set, followed by writing the updated data into CANIFnDA1, CANIFnDA2,
CANIFnDB1, and CANIFnDB2 registers, and then the number of the message object is written to
the MNUM field in the CAN IFn Command Request (CANIFnCRQ) register. To begin transmission
of the new data as soon as possible, set the TXRQST bit in the CANIFnMSKn register.
To prevent the clearing of the TXRQST bit in the CANIFnMCTL register at the end of a transmission
that may already be in progress while the data is updated, the NEWDAT and TXRQST bits have to be
set at the same time in the CANIFnMCTL register. When these bits are set at the same time, NEWDAT
is cleared as soon as the new transmission has started.

I think these show that new data updated shall not be lost if proper steps done, or I'm mis-understanding these words?

Thanks a lot.

As already mentioned, if no data changed, frames send as A/A1/A2/... in a cyclic manner where A1/A2 is almost the same as A. But if data changed and keep changing, we send like A/B/C/D... as a data stream without delay, till a steady state.

So it's not just a cyclic update, at the very moment old data act as a subset of new , old can be and shall be updated. If bus ok, send A/B/C/D....; if overloaded, just keep trying and get the latest be send.

My code test show the result as A/B1 frames received, which indicates there's a B lost, although the frame lost has no information lost since B=B1, but system delayed.

Hello Jays,

I checked the CANMessageSet and the NEWDAT is not being set. I believe if that is the cause of the issue then the CAN driver has to be updated to add the additional conditions, driverlib recompiled and then application recompiled with the new driverlib path instead of the pre compiled driverlib.

Regards
Amit

Apparently we get to the point.

I've tried as your words before the discussion and find some inconformity, I wonder to know if there's any error about the registers mentioned in datasheet or if there's a existing code.

Hello Jays

Apparently, with limited info on the code structure, bus transactions and not knowing what the setup and stress on the system. Does your application code check the CANERR and CANSTS register?

We do not know what your end system is implementing, so of course there is no code to offer. The CAN registers in our knowledge has no errors and has seen wide deployment with industrial customers.

Regards
Amit

Hello Jays,

Out of curiosity: Your first post on the thread has "Hercules™ Safety Microcontrollers"!!!

Regards
Amit

Hello Amit

Application code do check CANERR and CANSTS register to handle the errors met, but here no signal about the rx, we're talking about tx process.

The datasheet words here:

In order to only update the data in a message object, the WRNRD, DATAA and DATAB bits in the
CANIFnMSKn register are set, followed by writing the updated data into CANIFnDA1, CANIFnDA2,
CANIFnDB1, and CANIFnDB2 registers....

In fact, " WRNRD, DATAA and DATAB bits" in the CANIFnMSK register, not the CANIFnMSKn, i don't think the "n" here can denotes to be none.

crazy sweat, i don't know why i made the mistake to post the wrong place with 2 posts.

Hello Jays,

There is the TXOK which along with LEC may be used to see if there was any Bus Error during the transmission.

Regards
Amit