[AM3359 ICE] Ethercat EoE malloc/free issue?

Hi,

If you are using SDK 1.00.00.04 and SSC 5.01 - I suggest to try attached patch. We found this issue of memory leak in EoE mode with SSC5.01. Note that this patch is still under review with Beckhoff and may not be the final one to fix the problem.

2352.0006-Fix-memory-leaks-in-SSC5.01-stack-in-EoE-mode.zip

Working fine now, thank you!

The problem was present since SDK 1.00.00.03 and SSC ver. 5.0.

I hope guys at beckhoff will apply this patch to their stack.

It seems that a new issue is coming out: "task1" task is going out of stack memory.

I've increased the stack size from 0x800 to 0x1000, but the problem is still there. The cpu exits with this dump in error console:

[CortxA8] le: 0x800241a8.

Task stack base: 0x800241f0.
Task stack size: 0x1000.
R0 = 0x00000060 R8 = 0xffffffff
R1 = 0x80026a5b R9 = 0xffffffff
R2 = 0x00000060 R10 = 0xffffffff
R3 = 0x00000043 R11 = 0xffffffff
R4 = 0xffffffff R12 = 0x80026a56
R5 = 0xffffffff [CortxA8] SP(R13) = 0x80025128
R6 = 0xffffffff LR(R14) = 0x8000a55c
R7 = 0xffffffff PC(R15) = 0x80015854
PSR = 0x2000019f
ti.sysbios.family.arm.exc.Exception: line 174: E_dataAbort: pc = 0x80015854, lr = 0x8000a55c.[CortxA8]
xdc.runtime.Error.raise: terminating execution

This problems seems not correlated to EoE. The context is:

- SDK version 1.00.00.04,  SSC version 5.1, CodeComposer 5.2

- ICE board connected to an ethercat master, only this slave present in network, free run mode enabled.

- CoE - Online tab in Twincat System Manager with "Auto update" option enabled, to continuously trigger CoE data refresh:

With SDK version 1.00.00.03 and SSC version 5.0 everything is working fine. The issue come out with 1.00.00.04 and SSCv5.1.

.

Eugenio,

just the register dump doesn't tell what issue you see there. It might be stack size but this is not sure. If you debug the issue you should be able to see what is happening at the place where your code traps into the exception.

We are not extensively testing the higher level protocols in the stack as this is not our code. As Pratheesh mentioned we passed on the patch to ETG/Beckhoff but it is up to them to integrate into a new version of SSC. I saw you also posted in the ETG forum.

Regards.

This is a screenshot of CCS after the exception:

Cpu jumps to C$$EXIT(), but I can't figure out how to understand who thrown this exception. No EoE activity was on before the exception, just polling CoE variables. Everything is fine with previous versions of Sdl and ETG slave stack. These are the very few weeks I'm working through Code Composer (/Eclipse) and I'm not as experienced as I'd like.

Disabling EoE support in ecat_def.h solves the issue (but I'll need ethernet in the future). I can't guess if this is related to PRUs firmware or ETG slave stack.

Hi,

How long it takes for this crash to occur?

Is EoE still enabled at the master?

Regarding the patch for EoE - I forgot to mention that I increased system heap and stack size in BIOS config as well

i.e. increasing BIOS.heapSize to 12288 and Program.stack to 4096 in app.cfg (application SYS/BIOS config file) improved the behavior. I still think there are more issues on the EoE implementation as memory leak (now at a very slower rate) still occur after ~ 30,000 pings or so. We have raised this issue with Beckhoff and hoping to get a resolution. Let me know if this helps - meanwhile we will try to reproduce this issue with 1.00.00.04.

It takes thousands of pings (polling CoE variables in the meanwhile).

EoE is enabled at athe master.

Disabling EoE support in ecat_def.h eliminates the problem, so the issue (as stated by Frank in this thread) is strictly related to EoE code in beckhoff stack.

Engineers at Nuremberg ETG headquarter in Germany are informed, but still I got no answer.

Thank you for your support!

Hi,

the following patch file should fix the problem.

2133.SSC_V5i01_eoe_patch.zip