AM3357 (TI-ARM EtherCAT Slaves device) EEPROM Emulation problem

Edmund,

thanks for the detailed report. However the critical info missing here is the software on the slave side. What did you run on the slave? An example from the IA-SDK? Which version?

Did you try the same operation with a Twincat master? That is what we usually use for testing and we have seen no issues with EEPROM Reads so far. For sure the PRU can react in time (it only manages the packet operations) but the EEPROM emulation is actually done on ARM side. So this could as well be an application issue.

We are also using Codesys based EtherCAT master in our demos. No issues there. So did you ask 3S for support too?

Best regards,

Hi,

You can read ESC register offset 0x2 to know the firmware build major and minor number. http://processors.wiki.ti.com/index.php/AM335x_EtherCAT_firmware_API_guide#Firmware_Update has release specific details

Please make sure that you are running 1.1.0.4 release on your ICE board.

We recommend you to update the slave to the latest firmware:  www.ti.com/tool/sysbiossdk-ind-sitara 

>AM335x_SYSBIOS_Industrial_SDK Product Downloads>Pre-built Binaries

Refer to following wiki for running prebuilt binary - http://processors.wiki.ti.com/index.php/AM335x_SYSBIOS_Industrial_SDK_Getting_Started_Guide#Running_Pre-Built_Applications_on_AM335x_ICE_V1.2FV2

1. The SDK version we used:

am335x_sysbios_ind_sdk_prebuilt_01_01_00_04, see fig below: output msg to UART.

2. Yes, As you did, we have tried TwinCAT V2 and V3, there is no problem for this issue. We compare TwinCAT and codesys frames, They did same thing but timing, The TwinCAT master sends EEPROM read commands, the timing of two packets not so closed, So TI-PRU have time to rise the busy bit. Therefore there is no problem for TwinCAT master.

3. For EEPROM emulation , you are right, most part are process by ARM application, but the busy bit turn on is controlled by TI-ESC PRU, PRU give ARM app an event, when app receive this event, app will process EEPROM r/w emulation then ARM reset the busy bit….

Through some testing , when polling busy bit packet is too close previous command frame, this problem occurred!!. We tried polling packet not too close

TI-PRU work well~.

 4. We also told 3S-codesys this problem, but they say they are according to EtherCAT standard, (actually they did!!) And further, we test all other slaves devices using Codesys does not have this problem… (beckhoff ESC IC chip inside.)

5  Which Codesys version you used? We use the newest version of codesys V3.5 SP4 patch 3.

    http://www.codesys.com/

    We suggest you can trial version to duplicate this issue… (just use ICE board…)

Following figs are codesys shots we testing: Each time we scan TI-board get error information:

pdf.7723.AM3357 EEPROM Emulation problems report _TI_fornum_v4 1.pdf

Hi Edmund,

thanks for further info. This should allow us to reproduce the issue. Please allow a few days to work on this. If needed we will contact 3S directly.

Regards, 

Hi,

We can't reproduce this issue with CodeSys V3.5 SP4 patch 3 and I do not agree with pdf analysis that PRU is too slow to turn on busy bit.

I can confirm that busy bit set by PRU during IPG phase of frame which writes to EEPROM CTRL (0x503).

But the point is busy bit is not for master to read and consume, its just an indication to the master that EEPROM interface of the slave is busy or idle. Actually in AM335x, EEPROM interface much faster than ASIC implementation as we emulate EEPROM in memory and do not perform I2C read/write operation. Busy bit is cleared when A8 - which emulates the EEPROM operation, completes the action (read/write/reload) and acknowledges the same to PRU. This can happen within 3 microsecs to 10s of microsecs depending on loading on A8. 

if the operation happens within 7 micro secs or so, master won;t see the busy bit set in the subsequent frame. Otherwise master will see that busy bit is set.

Important information missing in the analysis is the data of frame 40 i.e. . APRD to 0x504 of 4 bytes. For an offset of 8, you shall see Vendor ID, 0xA: Product code and 0xC: Revision no. Can you share the wireshark log for your session please and are you using RTE variant of codesys?

Refer to this pdf for additional detail.. 8204.EEPROM_emulation_codesys_log.pdf 

Hi,

We can't reproduce this issue with CodeSys V3.5 SP4 patch 3 and I do not agree with pdf analysis that PRU is too slow to turn on busy bit.

I can confirm that busy bit set by PRU during IPG phase of frame which writes to EEPROM CTRL (0x503).

But the point is busy bit is not for master to read and consume, its just an indication to the master that EEPROM interface of the slave is busy or idle.

Above figure is screen shot from ESC manual, master need check busy bit when ESC or MCU emulation EEPROM data is ready for master for read back…

Actually in AM335x, EEPROM interface much faster than ASIC implementation as we emulate EEPROM in memory and do not perform I2C read/write operation. Busy bit is cleared when A8 - which emulates the EEPROM operation, completes the action (read/write/reload) and acknowledges the same to PRU. This can happen within 3 microsecs to 10s of microsecs depending on loading on A8. 

As you mention: when master send a read/write EPPROM command to EEPROM CTRL (0x503), and PRU will set the busy bit (as you say in IPG phase), when A8 application put the data to 0x508 then acknowledge to PRU to clear the busy bit. 
Follow this concept, We do a simple test, we put a break point on the line of “acknowledge to PRU to clear the busy bit”. The ARM process(application) will stopped at the line. (We want the master to see the busy bit)

 For master part, theoretically, the master will see the busy bit, and do polling busy bit until busy bit is clear or until master polling timeout. This result is what we expected.

But the result is: Sometimes no problem the result is what we expected(Master see the busy bit and continuous polling) but sometimes failed, (Master can’t not see the busy bit, and read a wrong data back…). The log file please refer to “AM335x Busy bit test.pdf”

if the operation happens within 7 micro secs or so, master won;t see the busy bit set in the subsequent frame. Otherwise master will see that busy bit is set.

Important information missing in the analysis is the data of frame 40 i.e. . APRD to 0x504 of 4 bytes. For an offset of 8, you shall see Vendor ID, 0xA: Product code and 0xC: Revision no. Can you share the wireshark log for your session please and are you using RTE variant of codesys?

No problem, following log is our data log, We using Windows RTE V3 of codesys.

(Sometime success, sometime failed when codesys scan…, timing issue…)

6116.AM3357 EEPROM Emulation problems report _TI_fornum_v5.pdf

1616.AM335x Busy bit test.pdf

1665.BusyBitWithBreakPointTest.zip

1385.Codesys master with am335x scan test.zip

Hi,

Thank you very much for detailed explanation. Our validation team is able to reproduce this now in a different PC. From the initial analysis, it looks like a race condition, we will get back as soon fix is available. Can you please contact me at pratheesh at ti dot com if there is a need to share any firmware update etc...