TMDXIDDK379D: Integrating EtherCAT Slave Stack with Drive Development Kit TMDXIDDK379D

Kevin,
The TMDSECATCNCD379D kit SW in controlSuite supports running EtherCAT slave stack , this kit can be plugged into the IDDK in place of a regular controlCARD to add EtherCAT capabilities to the IDDK.

We don't have a combined IDDK + EtherCAT example in controlSuite at this time, but user should be able to make this by defining the input/output variables as needed and by passing on the needed information from EtherCAT input/output variable to the IDDK control loop.

It should be possible to run EtherCAT on core 2 as well, just make sure the ASYNC interface (EMIF1 ) and IOs for interrupt are configured to be accessible from CPU2, I haven't tested this combination yet but I don't foresee any show stopper. EMIF2 access from CPU2 is not possible.

Please let us know if you have any questions.

Best Regards
Santosh Athuru

Hello Santosh – I was able to port the TIDM-DELFINO-ETHERCAT reference design software to CPU2 and run it alongside my IDDK motor control code on CPU1.  I did this using the SPI Flash configuration of the EtherCAT code.  As a verification I commented the ‘echoback’ line of code from the ESC APPL_Application() function where SpeedPosFbk is being set to SpeedPosReq and moved this operation to CPU1.  This demonstrated being able to set a value in TwinCAT, passing to the eCAT slave on CPU2, passing it through shared memory to CPU1, then sending it all the way back through shared memory to CPU2, and on to TwinCAT in a different variable.

However, I did run into an issue when I tried to call the IDDK function posEncoderSuite() from CPU1 in an attempt to send my motor position to the eCAT master.  I am using a Biss-C position encoder which utilizes SPI-B on CPU1.  I believe my issue has to do with the fact that CPU1 and CPU2 are both using a SPI peripheral.  I thought I would be okay because the IDDK code is using SPI-B on CPU1 and the EtherCAT stack is using SPI-C on CPU2.  However, my problem is clearly related to running both SPI peripherals at the same time.  What appears to be happening is the Biss-C code is getting hung up in a while loop because it’s not getting a successful SPI Rx.  Do you have any clues why this problem might  be happening?

 

I would actually prefer to use the EMIF configuration for running the eCAT slave stack but this is not working for me either.  Something is preventing the EMIF config of the TIDM-DELFINO-ETHERCAT reference design project from working ‘out of the box’ straight from controlSUITE on CPU1.  This project is running all the way to the “wait until ESC is started” do-while loop in HW_Init() (line 84).  Variable u16PdiCtrl is never equal to 0x08 or 0x05.

 

By the way, I am using a TMDSECATCNCD379D kit control card and I have always made sure to have the EMIF/SPI switches in the right position on the EtherCAT daughter board when testing either config.  If I could get this baseline EMIF solution working then I could port it to CPU2 in the same fashion as I did the SPI config and then maybe the SPI issue becomes moot.

 

So, in summary, my questions are:

1. What might be causing trouble with running SPIB on CPU1 while running *** on CPU2
2. What might be causing the baseline echoback reference design ASYNC16 configuration to get stuck where it is?

 

Thanks in advance for your help.

Kevin Alstrin

Kevin,
thanks, that is great progress.

I will need to consult with some one here to understand the SPI usage for BISS position encoder on IDDK, so I will let you know if there is conflict that needs to be considered with HW/SW here.

On the EMIF/ASYNC 16 question - the provided TMDSECATCNCD379D projects should work.
1.> First you made sure that the switches1 and 2 on SW1 on the EtherCAT adapter board are pointing to EMIF1.
2.> if you are working on the EtherCAT solution reference project or the PDI HAL API Test App project, make sure you are building the proper build configuration for ASYNC16 (if you right click on the project and navigate to build configuration, you will have to choose build config 1 or 2)
3.> You have programmed the slave node EEPROM with the ASYNC16 ESI file provided.

Can you clarify which reference CCS project you are using to test the EMIF/ASYNC16 SW? Did you go through the SPRUIG9 reference document provided in controlSuite (C:\ti\controlSUITE\development_kits\TMDSECATCND379D_V1.0) as well?


Best Regards
Santosh Athuru

Kevin,
on the SPI-B usage for BISS, were you able to get it independently working without EtherCAT? I'm not seeing any signal conflict between SPIB and *** usage in this context. Did you check for any signals conflicts between BISS and EtherCAT?

Must be the SW that is assigning owner of peripherals/IOs to the respective CPUs?

Best Regards
Santosh Athuru

Hello Santosh,

Can we concentrate on just the EMIF/ASYNC 16 issue for starters?  I have verified the following:

1. Switches1 and 2 on SW1 of the EtherCAT adapter board are pointing to “EMIF”.
2. I am building the build configuration 2 “F2837xD_CCARD_IMIF_RAM”.
3. I have programmed the slave node EEPROM with the ASYNC16 ESI file.
4. Yes, I have followed both SPRUIF9 and SPRUIG9 carefully.

Both the pdi_hal_test_app and the TMDSECATCNCD379_EtherCAT_Reference projects are behaving the same way when I run them.  They both get hung up at the same point.  There is a do-while loop near comment “Now wait till EEPROM is loaded”.  This is at line 1367 of etherCAT_slave_c28x_hal.c in the pdi_hal_test_app project.  Function call ESC_readWordNonISR(0x0140) never returns 0x08 so the program gets stuck here.  Instead this read is returning 0x88 when compared to the 0xFF bit mask.  Is it possible that the EMIF memory addressing could be off?  These projects by default are using EMIF1.

Kevin,
Sure, the control card build configuration 1 and 2 uses EMIF2. Not EMIF1, the PDI HAL API Test APP has a typo saying it uses EMIF1 in the build configuration notes, but if you look at hal.c line 975 to line 979, EMIF1 is not selected.

Can you verify the ESC memory from EtherCAT master, please verify both the register 0x140 contents and also the EEPROM contents from the master ?

Best Regards
Santosh Athuru

Kevin,
also make sure that the daughter card is sitting snug on the J9, sometimes there could be a mis-alignment and it could cause us to see weird things.

Best Regards
Santosh

Santosh,
I'm able to verify ESC memory from the ESC master looks like you would expect. In particular at offset 0x0140 I see PDI Ctrl is 0x0E08 (dec 3592) in TwinCAT. I also verified that the daughter board is seated properly in J9. I made the typo earlier. I realize that we are using EMIF2.
Thanks,
Kevin

Kevin
I re-verified in my set up, I read 0x0e08 correctly. Can you remove the TMDSECATCNCD379D kit out of the IDDK board and power the board using a micro USB cable from top and check the EMIF operation?

This would isolate the issue to signal contention when plugged into IDDK and we can take it forward from there. I don't have an IDDK with me at this moment to test it out.


Best Regards
Santosh Athuru

Santosh,

Good catch.  this was the problem.  ASYNC16 works fine with the control card not in the IDDK slot.  In retrospect I found that paragraph 4.2 of SPRUI76 warns of this:

I checked the schematic and it turns out that the GPIO's used for EMIF data that are routed to J9 on the control card are also used for the quadrature encoder and sin/cos position interfaces on the IDDK via the HSEC connector.  So it looks like utilizing the dual-core processor to run EtherCAT alongside IDDK control code will not be possible using EMIF due to hardware constraints.  It should still be possible with the SPI interface though.  It appears that the 4 SPI signals go directly between the MCU and J9.

Thanks,

Kevin

Kevin,
thanks for the confirmation. Yes that looks like a limitation. I'm checking with team if there is any thing else that can be done at this time or in future designs. Meanwhile are you back onto SPI?

Best Regards
Santosh Athuru