AM3357: CAN RX Fifo order problem

Hello Wojciech Chrobot

Thank you for the query.

I looked at the AM335x errata and did not see a similar advisory.

I need to check internally if similar issues have been reported/resolved.

In the meantime, could you provide some additional inputs including the development environment and the board being use that could help.

Regards,

Sreenivasa

Hello

I use a product board, that is connected to a Sonnet Echo express SE I with Profibus/Devicenet PCI card.

My processor is AM3357BZCZA30 24AKKIW.

I need this information because I am working on it and can't solve this problem.

Hello Wojciech Chrobot

Thank you for the inputs.

Are to facing this issue on a specific board or multiple boards.

When do you see the error - continuosly.

Can you pls help me understand the development environment you are using?

Regards,

Sreenivasa

I facing this issue on multiple boards. I see this error continously- about 3 times per second ( since I speed up communication to 5 frames per ms - from master). I use the Devicenet stack - which is based on CAN peripherials. The problem is in bad construction of FIFO buffer. Sometimes next frame in the sequence is in the wrong message cell - as in the first post (Message cell is Linestatus (L:) - in the log section).

Devicenet Speed is 500kbit/s
I have a problem with Devicenet communication, with CAN Message RX Fifo - the problem occurs since I start sending frames from the master immediately (about 5 frames in one milisecond) and send them in a loop, immediately after receiving the previous response from the device.
I configured msg fifo as eg. message: 36,37,38,39,40 RX IF2 receive eob = 0 and 41 - eob = 1. (Expected RX frames count is 6 frames)
I notice that sometimes (3 times per second - typically) I went to a fifo message unnecessary - the next frame is in the same message:

(17284 - miliseconds,i - id,e - error, L - message number, (d:?) - messages expected order)

17284 -|s:1|i:0x4b5,L:36,(d:0)
17284 -|s:1|i:0x4b5,L:36,(d:1)
17285 -|s:1|i:0x4b5,L:36,(d:2)
17285 -|s:1|i:0x4b5,L:37,(d:4)
17285 -|s:1|i:0x4b5,L:38,(d:5)
17285 -|s:1|i:0x4b5,L:36,(d:3)

We see above the 3rd message (d:3) should be read from message 36, but we read message 37 (d:4) and 38 (d:5) before it

When I change the code to check inside the interrupt message number once again - I have opposite problem, but only one time per 2 seconds:

13813 -|s:1|i:0x4b5,L:36,(d:0)
13814 -|s:1|i:0x4b5,L:36,(d:1)
13814 -|s:1|i:0x4b5,L:36,(d:4)
13814 -|s:1|i:0x4b5,L:37,(d:2)
13814 -|s:1|i:0x4b5,L:38,(d:3)
13815 -|s:1|i:0x4b5,L:36,(d:5)

We see above that (d:4) message is read too early - the program does not check a fifo buffer - it checks the same message number once again.

How can I correctly handle fifo messages when the previously read message is filled too early, instead of using the next fifo number.
I tried to set newdata bit of current message to "1" (by a IF2MCTL register or by a NEWDAT34 register) - but it does nothing.
I tried to disable IntPnd of messages for time of reading the whole fifo, and enable them after I finish reading - but I loose frames.
Please help.

Hello Wojciech Chrobot

Thank you for the inputs.

Let me review the inputs and check internally if we have heard of this issue from other customer or have some recommendations.

Regards,

Sreenivasa

Hello, do you have a solution to my problem?

Hello Wojciech Chrobot

Thank you for following-up.

Could you please add some info on the development environment you are using.

Regards,

Sreenivasa

From software I have:

BIOS ver. 6_51_00_15
XDC tools ver. 3_50_00_10_core

from hw:

there is a product version board with processor: AM3357BZCZA30 24AKKIW. This board is connected to a echo express se I with Profibus/DeviceNet PCIe card (this is a DeviceNet master).

What additional information do you need?

Hello Wojciech Chrobot

Thank you for the inputs.

Please read below thread and help me understand the development approach you have been following.

(+) PROCESSOR-SDK-AM335X: BIOS and XDC tools - Processors forum - Processors - TI E2E support forums

Regards,

Sreenivasa

We tested it in sysbios and in bare-metal. The behavior is the same. We suppose the problem lies in the HW implementation of the fifo CAN buffer. So my question is, do you confirm that the problem occurs because of the hardware - as in TMS320F2837xD.

Hello Wojciech Chrobot

Thank you for the input.

Wojciech Chrobot said:

So my question is, do you confirm that the problem occurs because of the hardware - as in TMS320F2837xD.

I will have to check internally to confirm if we use similar IP.

Please expect delay in response as i reach out to the apps, systems and design teams.

Regards,

Sreenivasa

Hello,

Is there any new information?

Hello Wojciech Chrobot

Thank you for following on this.

I have been checking internally and have not able to get any inputs that i can share.

AM335X

23.4 Registers 23.4.1 DCAN Registers Table 23-13 lists the memory-mapped registers for the DCAN. All register offset addresses not listed in Table 23-13 should be considered as reserved locations and the register contents should not be modified.

TMS320F2837xD

22.15.2 CAN_REGS Registers Table 22-8 lists the CAN_REGS registers. All register offset addresses not listed in Table 22-8 should be considered as reserved locations and the register contents should not be modified.

I compared the registers between the 2 devices. The registers seem similar and the AM335X has additional registers.

I would tend to agree with your assessment: Does this problem still occur in AM3357? CAN registers are similar to TMS320F2837xD - Based on the comparison. I am checking internally to understand if this is the case and will update you when i get some inputs from the experts.

Regards,

Sreenivasa

ok, thank you, I'm waiting for a reply.

Hello Wojciech Chrobot

Thank you for the note.

I will update the thread based on the inputs i receive.

Regards,

Sreenivasa

Hello.

Do we have any new information?

Hello Wojciech Chrobot

Thank you for the follow-up.

I have not been able to reach out to the CAN expert.

I am checking internally.

Regards,

Sreenivasa

Hello.

Do we have any new information?

Hello Wojciech Chrobot

Thank you for following on this.

Please note that i do not have any updates.

Since this is a device that has been released many years before, it is taking time to reach out to the design owner.

I am following on this and will update when i have an answer.

Regards,

Sreenivasa