CAN transmission error in i.MX6D

[ko-hey]

Hi all

My customer have a trouble in CAN so I have a question about it.

Please tell me the following question.

// Symptom //

In CAN transmission, when the amount of data to be transmitted increases, erroneous data may be extra transmitted.

// Control Method //

The setting is as follow.

・Using 54-63 message buffer for send.

・LPRIO_EN = 1(Local Priority enabled)

・LBUF = 0(Buffer with highest priority is transmitted first)

・All PRIO = 0.

・MCR AEN = 0(Abort disable).

・IMASK = 0

They've controlled the following procedure for sending by 10 ms cycle.

1. Find a message buffer which CODE region is INACTIVE and ABORT.

2. Store the number of data, ID and data.

3. Write a "1100" to CODE then start sending.

Normally, all Message buffers are "INACTIVE" every 10 ms cycle, and the number of data is smaller than the message buffer number,

When the amount of data is large, the transmission process of the peripheral can not keep up, the message buffer is exhausted,

INACTIVE "will be sent repeatedly by looping in 1 and waiting tens of times to store the data.

At this time, occasionally, extra data may be transmitted.

// Question //

1.

When storing data to message buffer, is there a problem in the way of judging by looking at the CODE area as shown in 1 above ?

2.

Does IFLAG become 1 without setting with MASK?

According to p 1302, confirming transfer completion with IFLAG then confirming the result with CODE.

Also, in the description of IFLAG of p1349, it becomes 1 when transmission and reception succeed.

Is the interrupt generation different from the flag setting?

3.

In the explanation of p1315 abort, it is abort that the mechanism to safely interrupt pending.

I think that the pending is occurred when a data store to another high priority buffer during the arbitration is executed.

In that case, is there any risk of erroneous data transmission ?

In what situations does user need to take care the abort ?

Ko-hey

[jimmychan]

which BSP are you using?

[ko-hey]

Hello jimmychan

Sorry for late reply.

Now they have tried to implement QNX 6.6.

Before implementing the QNX, they tested the CAN's normal communication with Yocto L4.1.15_2.0.0 and it was no problem.

This means that they haven't done the stress test like doing with QNX.

From the above situation, we guess that the driver which is implemented with QNX have some problem.

So we want to clear the procedure and setting for control the CAN.

Could you tell me whether the method which I posted to this thread is correct or not ?

Ko-hey

[ko-hey]

Hello jimmychan

Could you follow and answer the question ?

Ko-hey

[jimmychan]

As you mentioned that they tested the CAN's normal communication with Yocto L4.1.15_2.0.0 and it was no problem, Is it means they tried their " Control Method" on Linux BSP? and no problem on Linux BSP? 

[ko-hey]

No, they just tried your BSP without any change and the communication was no problem so hardware is OK.

After that they tried to change to QNX in reference to NXP BSP.

However, they failed the some tests.

So they review and want to confirm about their Control Method".

As a result, they asked us the questions.

[jamesbone]

Hello Ko-Hey,

Unfortunately we do not have QNX BSP to help you very deep, but I can see, that in your control method you are never looking for an Overrun Flag if the Buffer gets exhausted, or  checking any received error in your method.  You can use as an example the CAN Driver from the  Yocto Linux Driver.

Have a great day,
Jaime

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[ko-hey]

Hi jamesbone

Thank you for reply.

I'll tell the user should check Overrun Flag.

Ko-hey