AM2432: Ethernet IP stack enter data abort after several hours test

Tony Tang

Mastermind 29602 points

Part Number: AM2432

Tool/software:

MCU SDK: 9.02

Industry SDK: ind_comms_sdk_am243x_09_02_00_08

Issue: Enter Data Abort over 6 to 7 hours, or longer a litte.

Test on 8pcs boards, all triggered this issue. Did not notice the call trace before, but currently 3 pcs on debugging all triggered from same place from call trace.

From CCS, captured the trigger place and read out fault address (0x3220747A)

From the call trace, triggered the data abort inside LLDP_deleteNeighborDevice(), should be ldr instruction at 0x700DD6AC accessed invalid address, seems R0 passed in a illegal address, as this is inside the protocol, application did not call these functions directly. need BU help analysis.

over 1 year ago

0 Archit Dev over 1 year ago

TI__Expert 3420 points

Hi Tony,

Can you share some more information here :

1. Which example is the customer using?
2. Are they facing this issue in the out-of-box example? Or is it their custom application?
3. Are they facing this issue on the AM243x EVM/LP? Or is it their custom board?
4. Can you share the test topology and test procedure details?

We have faced some similar issues when we tested 6 devices (AM243x LP) connected to a Rockwell PLC in a daisy chain fashion for long term (40 hours+) . We suspect this is due to some thread-unsafe memory allocation/free being done in the EIP and lwIP Stack. The debug is still under progress.

Please expect an update in about 2-3 weeks while we debug and fix the issue, followed by some long term stability tests.

Regards
Archit Dev

0 sigong over 1 year ago in reply to Archit Dev

Prodigy 250 points

Hi Archit Dev,

Thanks for the response.

1.The example used can be found in this way :

C:\ti\ind_comms_sdk_am243x_09_02_00_08\examples\industrial_comms\ethernetip_adapter_demo\device_profiles\generic_device\mii\am243x-lp;

2.Actually,we have added codes about peripherals like uart,more GPIOs and changed codes about PHYs,OSPI flash.In our application,we just use these EIP APIs provided by the EIP stack,like EI_API_CIP_getAttr_uint,EI_API_CIP_setAttr_uint and so on.

3.So far,all of the long term stability tests are carried out on our own board.And all 8 boards in test had the same anomaly at least once.

4.We use the AB PLC(1756-L83E) in the test.The PLC and 8 boards(Ethernet/IP adapter) are all connected to network switch.

Need more deatails about test?please tell me.

regards

sigong

0 Archit Dev over 1 year ago in reply to sigong

TI__Expert 3420 points

Hi sigong.

Thank you very much for your detailed response.

As I explained in my previous message, although not identical, we have seen some similar failures in the long-term tests with a lot of devices in the network.

We are currently in the process of debugging the issue on our side. We will share a patch in some time.

Your patience is appreciated.

Regards
Archit Dev

0 Tony Tang over 1 year ago in reply to Archit Dev

TI__Mastermind 29602 points

Hi Archit,

Is there progress?

0 Pourya Eskandari over 1 year ago in reply to Tony Tang

TI__Intellectual 2140 points

Hi Tony,

as Archit mentioned we are investigating the issue, we are running long-term tests right now on some fixes we have done.
A patch will be provided, when the issue is fixed.

Best regards

Pourya

0 sigong over 1 year ago in reply to Pourya Eskandari

Prodigy 250 points

Hi Archit and Tony,

I have followed the note in EIP_Dynamic_Allocation_and_LLDP_Fixes.zip and rebulit these drivers mentioned.

However,some new issues have appeared until now:

The first one is that program will enter EI_APP_TASK_osErrorHandlerCb and be stuck in it.

The second is that program is stuk in _DebugP_assertNoLog.

Could you tell me the reason?

0 Pourya Eskandari over 1 year ago in reply to sigong

TI__Intellectual 2140 points

Hi signog

1) Can you please share UART log? That would greatly help to identify what could have caused the EI_APP_TASK_osErrorHandlerCb being called.
2) Which Chip Variant is your design based on? At which frequency is the chip running?
3) In your application, do you use heap allocation? If yes, can you double check if it is thread safe?
4) Some contexts about your test setup would be helpful (Cyclic I/O time, Static IP or DHCP, etc.)

Best regards
Pourya

0 sigong over 1 year ago in reply to Pourya Eskandari

Prodigy 250 points

Hi,

1)Because the probe was not connect to the board while the issue occuring,so I do not have the UART log.

2) AM2432BKFGHIALXR ; And the frequency keeps the default value as the example's configuration.

3)No,I don't use heap allocation.The added application is just involved with uart, timer, GPIO etc.

4)I use DMTIMER1 to deal with tasks about uart protocol ,and its cycle is configured with 500us.

In the time1 callback,It enable uart sending.

And the program stay in the timer1 callcback for about 2us.

0 sigong over 1 year ago in reply to sigong

Prodigy 250 points

By the way,we can find the return value of the EI_APP_TASK_init is false.

0 Tony Tang over 1 year ago in reply to Pourya Eskandari

TI__Mastermind 29602 points

Hi Pourya,

Sorry for my mistake, there are 8pcs board under test, 3 pcs failed, rest 5pcs is running normally from last night so far.

0 Pourya Eskandari over 1 year ago in reply to Tony Tang

TI__Intellectual 2140 points

Hi Tony,

regarding power-cycle problem, under file appTask.c and function EI_APP_TASK_main,
please replace the old code in the image below with SOC_generateSwWarmResetMcuDomain() to reset the device, when Power-Cycle command is received.

Best regards Pourya

0 Tony Tang over 1 year ago in reply to Pourya Eskandari

TI__Mastermind 29602 points

Hi Pourya,

Thanks, Customer will test with it and feedback result.

There is another different error attach the snapshot again. it is after EIP communication established. the error rate is less than osError.

if it also related to the power cycle, or a new error mode, please

0 sigong over 1 year ago in reply to Tony Tang

Prodigy 250 points

Hi,

Here is the update.

1.This is the uart log when the program enter into EI_APP_TASK_osErrorHandlerCb and is stuck in it.

DMSC Firmware Version 8.6.4--v08.06.04 (Chill Capybar
DMSC Firmware revision 0x8
DMSC ABI revision 3.1

[BOOTLOADER_PROFILE] Boot Media       : NOR SPI FLASH 
[BOOTLOADER_PROFILE] Boot Media Clock : 10.000 MHz 
[BOOTLOADER_PROFILE] Boot Image Size  : 555 KB 
[BOOTLOADER_PROFILE] Cores present    : 
r5f0-0
[BOOTLOADER PROFILE] SYSFW init                       :      12027us 
[BOOTLOADER PROFILE] System_init                      :    5366511us 
[BOOTLOADER PROFILE] Drivers_open                     :        272us 
[BOOTLOADER PROFILE] Board_driversOpen                :        170us 
[BOOTLOADER PROFILE] Sciclient Get Version            :      10025us 
[BOOTLOADER PROFILE] CPU load                         :     482182us 
[BOOTLOADER_PROFILE] SBL Total Time Taken             :     502480us 

Image loading done, switching to application ...
Pruicss  max =3 selected PRU:3
software version: 9125
The data is corrupted, write default values.
PRU_PHY_detect:185 Phy 3 alive
PRU_PHY_detect:185 Phy 15 alive
+EI_API_ADP_pruicssStart
-EI_API_ADP_pruicssStart
Assembly 0x64 size: 0
Local interface IP is 192.168.1.113
EI_API_ADP_getMacAddr:  1c:63:49:20:7c:e5
0x1 0x40 0x2 0x60 0x27 0x43 0x4 0x43 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x1 0x60 0x0 0x60 0x2d 0x0 0x1 0x1 0x16 0x1 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 

DMSC Firmware Version 8.6.4--v08.06.04 (Chill Capybar
DMSC Firmware revision 0x8
DMSC ABI revision 3.1

[BOOTLOADER_PROFILE] Boot Media       : NOR SPI FLASH 
[BOOTLOADER_PROFILE] Boot Media Clock : 10.000 MHz 
[BOOTLOADER_PROFILE] Boot Image Size  : 555 KB 
[BOOTLOADER_PROFILE] Cores present    : 
r5f0-0
[BOOTLOADER PROFILE] SYSFW init                       :      12024us 
[BOOTLOADER PROFILE] System_init                      :    5366515us 
[BOOTLOADER PROFILE] Drivers_open                     :        272us 
[BOOTLOADER PROFILE] Board_driversOpen                :        170us 
[BOOTLOADER PROFILE] Sciclient Get Version            :      10025us 
[BOOTLOADER PROFILE] CPU load                         :     482188us 
[BOOTLOADER_PROFILE] SBL Total Time Taken             :     502487us 

Image loading done, switching to application ...
Pruicss  max =3 selected PRU:3
software version: 9125
The data is corrupted, write default values.
PRU_PHY_detect:185 Phy 3 alive
PRU_PHY_detect:185 Phy 15 alive
+EI_API_ADP_pruicssStart
-EI_API_ADP_pruicssStart
Assembly 0x64 size: 0
Local interface IP is 192.168.1.113
EI_API_ADP_getMacAddr:  1c:63:49:20:7c:e5
0x1 0x40 0x2 0x60 0x27 0x43 0x4 0x43 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x1 0x60 0x0 0x60 0x2d 0x0 0x1 0x1 0x16 0x1 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 

DMSC Firmware Version 8.6.4--v08.06.04 (Chill Capybar
DMSC Firmware revision 0x8
DMSC ABI revision 3.1

[BOOTLOADER_PROFILE] Boot Media       : NOR SPI FLASH 
[BOOTLOADER_PROFILE] Boot Media Clock : 10.000 MHz 
[BOOTLOADER_PROFILE] Boot Image Size  : 555 KB 
[BOOTLOADER_PROFILE] Cores present    : 
r5f0-0
[BOOTLOADER PROFILE] SYSFW init                       :      12343us 
[BOOTLOADER PROFILE] System_init                      :    5366196us 
[BOOTLOADER PROFILE] Drivers_open                     :        272us 
[BOOTLOADER PROFILE] Board_driversOpen                :        170us 
[BOOTLOADER PROFILE] Sciclient Get Version            :      10020us 
[BOOTLOADER PROFILE] CPU load                         :     482182us 
[BOOTLOADER_PROFILE] SBL Total Time Taken             :     502476us 

Image loading done, switching to application ...
Pruicss  max =3 selected PRU:3
software version: 9125
The data is corrupted, write default values.
PRU_PHY_detect:185 Phy 3 alive
PRU_PHY_detect:185 Phy 15 alive
+EI_API_ADP_pruicssStart
Non real time packet is dropped: No RX callback registered for non-realtime packets.PRU_EIP_EmacNrtRxCallback: 0x1d0024 EC is fatal=1, SRC:PRU_EIP_EmacNrtRxCallback:490

Error: 0x001d0024, Fatal: yes

2.And this is uart log when the program is stuck in _DebugP_assertNoLog.

0x1 0x40 0x2 0x60 0x27 0x43 0x4 0x43 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x1 0x60 0x0 0x60 0x2d 0x0 0x1 0x1 0x16 0x1 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 

DMSC Firmware Version 8.6.4--v08.06.04 (Chill Capybar
DMSC Firmware revision 0x8
DMSC ABI revision 3.1

[BOOTLOADER_PROFILE] Boot Media       : NOR SPI FLASH 
[BOOTLOADER_PROFILE] Boot Media Clock : 10.000 MHz 
[BOOTLOADER_PROFILE] Boot Image Size  : 555 KB 
[BOOTLOADER_PROFILE] Cores present    : 
r5f0-0
[BOOTLOADER PROFILE] SYSFW init                       :      12161us 
[BOOTLOADER PROFILE] System_init                      :    5366378us 
[BOOTLOADER PROFILE] Drivers_open                     :        278us 
[BOOTLOADER PROFILE] Board_driversOpen                :        170us 
[BOOTLOADER PROFILE] Sciclient Get Version            :      10024us 
[BOOTLOADER PROFILE] CPU load                         :     482188us 
[BOOTLOADER_PROFILE] SBL Total Time Taken             :     502493us 

Image loading done, switching to application ...
Pruicss  max =3 selected PRU:3
software version: 9125
The data is corrupted, write default values.
PRU_PHY_detect:185 Phy 3 alive
PRU_PHY_detect:185 Phy 15 alive
+EI_API_ADP_pruicssStart
-EI_API_ADP_pruicssStartAssembly 0x64 size: 0
Local interface IP is 192.168.1.113
EI_API_ADP_getMacAddr:  1c:63:49:20:7c:e5
0x1 0x40 0x2 0x60 0x27 0x43 0x4 0x43 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x1 0x60 0x0 0x60 0x2d 0x0 0x1 0x1 0x16 0x1 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 

DMSC Firmware Version 8.6.4--v08.06.04 (Chill Capybar
DMSC Firmware revision 0x8
DMSC ABI revision 3.1

[BOOTLOADER_PROFILE] Boot Media       : NOR SPI FLASH 
[BOOTLOADER_PROFILE] Boot Media Clock : 10.000 MHz 
[BOOTLOADER_PROFILE] Boot Image Size  : 555 KB 
[BOOTLOADER_PROFILE] Cores present    : 
r5f0-0
[BOOTLOADER PROFILE] SYSFW init                       :      12061us 
[BOOTLOADER PROFILE] System_init                      :    5366485us 
[BOOTLOADER PROFILE] Drivers_open                     :        272us 
[BOOTLOADER PROFILE] Board_driversOpen                :        170us 
[BOOTLOADER PROFILE] Sciclient Get Version            :      10025us 
[BOOTLOADER PROFILE] CPU load                         :     482188us 
[BOOTLOADER_PROFILE] SBL Total Time Taken             :     502494us 

Image loading done, switching to application ...
Pruicss  max =3 selected PRU:3
software version: 9125The data is corrupted, write default values.
PRU_PHY_detect:185 Phy 3 alive
PRU_PHY_detect:185 Phy 15 alive
+EI_API_ADP_pruicssStart
-EI_API_ADP_pruicssStart
Assembly 0x64 size: 0

0 Pourya Eskandari over 1 year ago in reply to sigong

TI__Intellectual 2140 points

Hi Sigong,

to double check, these logs were captured with the Fix I mentioned earlier, correct? (use SOC_generateSwWarmResetMcuDomain)

Regarding Problem#1:
After analyzing it seems that the EI_APP_TASK_init has failed, you also mentioned earlier that you have noticed that it returns false.
Could you please do a debug and step through the EI_APP_TASK_init to find out where exactly it fails?
This also explains, why you see the error message “No RX callback registered for non-realtime packets”.

Regarding Problem#2:
It is also an initialization error, which is related to Problem#1 but it shows itself now at a different place.

You mentioned earlier, that you are using a timer to trigger UART printouts. When is the timer & UART initialized? After Stack initialization or before that? Could that cause a problem? for example trying to access something which is not still initialized, etc.?

Best regards
Pourya

0 sigong over 1 year ago in reply to Pourya Eskandari

Prodigy 250 points

Hi,

Yes.It is true that these logs were captured with the Fix.

In reality,I have used both SOC_generateSwWarmResetMcuDomain and SOC_generateSwWarmResetMainDomain and it has the same result.

Problem#1:

I'll need to explain that it is a guess that the function EI_APP_TASK_init returns false.Because the value of first_eip_stackinit keeps 0 as default from Expressions when debugging.In my opinion,The only chance of first_eip_stackinit changing to 1 is that EI_APP_TASK_init returns true.Otherwise,the "return;" will works.

It is difficult to debug the function EI_APP_TASK_init just before the issues occur,because the board in test is powered up and off without a break.However,we'll have a try to add some signals in it later.

Problem#2:

The timer & UART is initialized in the CMN_OS_init before the execution of CMN_APP_mainCreate.And the Stack initialization is in the EI_APP_TASK_main.

0 Pourya Eskandari over 1 year ago in reply to sigong

TI__Intellectual 2140 points

Hi sigong,

let me know when you have found out, where in EI_APP_TASK_init you see the failure.
If debug is hard, you could also try UART log, in which you check the return values of each subsequent calls inside the EI_APP_TASK_init and print info, if you notice something goes wrong.

Best regards
Pourya

0 sigong over 1 year ago in reply to Pourya Eskandari

Prodigy 250 points

Hi,

Regarding Problem#1:

It is certain that some issues occurred in the "EI_API_ADP_pruicssStart".Because we cannot find uart log like "-EI_API_ADP_pruicssStart" when Error happened.Is it right?

///////////////////////////////////////////////////////////////////////////////////////////

DMSC Firmware Version 8.6.4--v08.06.04 (Chill Capybar
DMSC Firmware revision 0x8
DMSC ABI revision 3.1

[BOOTLOADER_PROFILE] Boot Media : NOR SPI FLASH
[BOOTLOADER_PROFILE] Boot Media Clock : 10.000 MHz
[BOOTLOADER_PROFILE] Boot Image Size : 555 KB
[BOOTLOADER_PROFILE] Cores present :
r5f0-0
[BOOTLOADER PROFILE] SYSFW init : 12027us
[BOOTLOADER PROFILE] System_init : 5366511us
[BOOTLOADER PROFILE] Drivers_open : 272us
[BOOTLOADER PROFILE] Board_driversOpen : 170us
[BOOTLOADER PROFILE] Sciclient Get Version : 10025us
[BOOTLOADER PROFILE] CPU load : 482182us
[BOOTLOADER_PROFILE] SBL Total Time Taken : 502480us

Image loading done, switching to application ...
Pruicss max =3 selected PRU:3
software version: 9125
The data is corrupted, write default values.
PRU_PHY_detect:185 Phy 3 alive
PRU_PHY_detect:185 Phy 15 alive
+EI_API_ADP_pruicssStart
-EI_API_ADP_pruicssStart
Assembly 0x64 size: 0
Local interface IP is 192.168.1.113
EI_API_ADP_getMacAddr: 1c:63:49:20:7c:e5
0x1 0x40 0x2 0x60 0x27 0x43 0x4 0x43 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x1 0x60 0x0 0x60 0x2d 0x0 0x1 0x1 0x16 0x1 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff

DMSC Firmware Version 8.6.4--v08.06.04 (Chill Capybar
DMSC Firmware revision 0x8
DMSC ABI revision 3.1

[BOOTLOADER_PROFILE] Boot Media : NOR SPI FLASH
[BOOTLOADER_PROFILE] Boot Media Clock : 10.000 MHz
[BOOTLOADER_PROFILE] Boot Image Size : 555 KB
[BOOTLOADER_PROFILE] Cores present :
r5f0-0
[BOOTLOADER PROFILE] SYSFW init : 12024us
[BOOTLOADER PROFILE] System_init : 5366515us
[BOOTLOADER PROFILE] Drivers_open : 272us
[BOOTLOADER PROFILE] Board_driversOpen : 170us
[BOOTLOADER PROFILE] Sciclient Get Version : 10025us
[BOOTLOADER PROFILE] CPU load : 482188us
[BOOTLOADER_PROFILE] SBL Total Time Taken : 502487us

DMSC Firmware Version 8.6.4--v08.06.04 (Chill Capybar
DMSC Firmware revision 0x8
DMSC ABI revision 3.1

[BOOTLOADER_PROFILE] Boot Media : NOR SPI FLASH
[BOOTLOADER_PROFILE] Boot Media Clock : 10.000 MHz
[BOOTLOADER_PROFILE] Boot Image Size : 555 KB
[BOOTLOADER_PROFILE] Cores present :
r5f0-0
[BOOTLOADER PROFILE] SYSFW init : 12343us
[BOOTLOADER PROFILE] System_init : 5366196us
[BOOTLOADER PROFILE] Drivers_open : 272us
[BOOTLOADER PROFILE] Board_driversOpen : 170us
[BOOTLOADER PROFILE] Sciclient Get Version : 10020us
[BOOTLOADER PROFILE] CPU load : 482182us
[BOOTLOADER_PROFILE] SBL Total Time Taken : 502476us

Image loading done, switching to application ...
Pruicss max =3 selected PRU:3
software version: 9125
The data is corrupted, write default values.
PRU_PHY_detect:185 Phy 3 alive
PRU_PHY_detect:185 Phy 15 alive
+EI_API_ADP_pruicssStart
Non real time packet is dropped: No RX callback registered for non-realtime packets.PRU_EIP_EmacNrtRxCallback: 0x1d0024 EC is fatal=1, SRC:PRU_EIP_EmacNrtRxCallback:490

Error: 0x001d0024, Fatal: yes

////////////////////////////////////////////////////////////////////////////////////////////////////

0 sigong over 1 year ago in reply to sigong

Prodigy 250 points

I also need to explain that the function "EI_APP_TASK_init" has been moved into the FOR loops in the "EI_APP_TASK_main".Does this matter?

0 Tony Tang over 1 year ago in reply to sigong

TI__Mastermind 29602 points

From upper UART log, you are using DMSC8.6 +SDK9.2, should use same version from one SDK.

0 Pourya Eskandari over 1 year ago in reply to sigong

TI__Intellectual 2140 points

Hi Sigong,

yes it does matter, the EI_APP_TASK_init is supposed to be called only once during initialization phase, was there a reason to put it in a for-loop?

Regarding Problem#1, the error is with high probability happened earlier than EI_API_ADP_pruicssStart, only we see it late.

Would it be possible for you to share your Application source-code, so that we are on the same page?

Best regards
Pourya

0 sigong over 1 year ago in reply to Pourya Eskandari

Prodigy 250 points

Hi,

The reason I put the EI_APP_TASK_init in a for-loop is that we have to get information including ip,mask and gateway from the other control board through periodic serial communication.In fact,the EI_APP_TASK_init is also executed only once.

An earlier version of the program has been decoded and should have been shared with you by Tony's hand. It differs from latest version in these respects,including the mechanism of restart from WDT ,the call of Comm_InputData_Deal has been changed to Timer2_Callback and just some conditional judgments at the application level.If you need the latest version,I 'll request its decryption and share it with you.Thanks.

Besides,if it does not go wrong in the EI_API_ADP_pruicssStart, how can we locate the accurate place of the error?

Pourya Eskandari said:
Regarding Problem#1, the error is with high probability happened earlier than EI_API_ADP_pruicssStart, only we see it late.

0 Pourya Eskandari over 1 year ago in reply to sigong

TI__Intellectual 2140 points

Hi Sigong,

Some notes about global variables, please use “volatile” keyword to make sure your variables are used and interpreted the way you meant. (for example, volatile uint32_t gWatchdogInt = 0; or volatile uint8_t first_eip_stackinit=0; ...)
Another thing is, for better determinism you could use standard delay functions if you want to wait for the PHY to recover from the reset.

In EI_APP_TASK_main please check if CUST_DRIVERS_init returns successfully. Does CUST_PHY_detect call your Custom-PHY implementation function successfully every time?

Best regards

Pourya

0 sigong over 1 year ago in reply to Pourya Eskandari

Prodigy 250 points

Hi Pourya,

1.I'll follow the advice of adding “volatile” keyword and make a test.

2.The delay operation after PHY_Reset in the image has been removed in the latest version.And there is no such operation anywhere else.

3.I'll also take notice of the return of CUST_DRIVERS_init .

Because there remains only 2 boards now,maybe the issues reoccur need a longer time.I will respond to questions as they arise.

Thanks.

0 Archit Dev over 1 year ago in reply to sigong

TI__Expert 3420 points

Hi,

Multiple stability issues related to dynamic memory allocation have been fixed in the Industrial Comms SDK v 9.2.0.15. I'd suggest you to check it out.

Download Link: https://www.ti.com/tool/download/INDUSTRIAL-COMMUNICATIONS-SDK-AM243X/09.02.00.15
Release Notes: https://software-dl.ti.com/processor-industrial-sw/esd/ind_comms_sdk/am243x/09_02_00_15/docs/am243x/ethernetip_adapter/eip_releasenotes.html

Please be aware that there can be some deadlock conditions when accessing I2C0 from the example. As a workaround, GPIO based LEDs can be used depending on the hardware.

Regards
Archit Dev

Arm-based microcontrollers

Arm-based microcontrollers forum

AM2432: Ethernet IP stack enter data abort after several hours test