CCS/LAUNCHXL-F28377S: ethercat

Hello Stamatis,

for single core launch pad , you will have to use build configuration 5 or 6. Right click on the project, navigate to build configuration->set Active->Choose option 5 or 6.

Depending on the Launch pad you are using you will have to select the proper build configuration so the mapping comes out correctly. Also refer to the hal/etherCAT_slave_c28x_hal.h file for details on the IO configurations.

The PDI HAL test app doesn't include EtherCAT slave stack. We have another upcoming release that supports EtherCAT slave stack Demo and solutions for F2837xD MCU, please stay tuned. 

The EEPROM bin file provided with the PDI HAL Test APP just allows customers to evaluate the PDI from C28x MCU, accessing ET1100 ESC registers and RAM. The SW provided with the TI Design doesn't have an EtherCAT slave stack support yet.

Hope this helps.

Best Regards

Santosh Athuru

Hello again and thanks for replying,

The pins I mentioned at the initial post (GPIO78 ->SPI_IRQ) are for build configuration number 6 that i am currently using. The problem is that on the GPIO concerning the EEPROM_LOADED pin is not declared throughout the project. As you said, I had already checked the hal/etherCAT_slave_c28x_hal.h file where i had found the GPIO connected to SPI_IRQ. Stil I cannot see where the EEPROM_LOADED is! 

"The PDI HAL test app doesn't include EtherCAT slave stack. We have another upcoming release that supports EtherCAT slave stack Demo and solutions for F2837xD MCU, please stay tuned."

By that you mean that the provided bin file is not capable of implementing Ethercat communication? Because the reason i bought this launchpad and the ESCis mianly because i thought that i could establish Ethercat communication really quickly(after reading your guide). Neveetheless, beckhoff provides an xmal file (SSC) for the specific ESC that i am using so i am guesing that the problem could be overcome. Could you please tell me when this new demo will be released because i have to meet a deadline and i am really on a great hurry. Please let me know.

"The EEPROM bin file provided with the PDI HAL Test APP just allows customers to evaluate the PDI from C28x MCU, accessing ET1100 ESC registers and RAM. The SW provided with the TI Design doesn't have an EtherCAT slave stack support yet."

In order to access these registers, the ESC needs to be in Operational mode, right? DO i have to switch in RUN MODE as well on TwinCat?

Thank you

Looking forward to hearing from you

Athiniotis Stamatis

Hello,

Please refer to the documentation that you get with the TI Design, the documentation clearly shows what kind of communication is possible from TwinCAT. With the provided bin files we are enabling the PDI interface on the ESC to access the registers and RAM space from MCU. TwinCAT will be able to scan the network and you will be able to view the memory space of the ESC from TwinCAT. The documentation shows the snapshots of this.

The EEPROM_LOADED pin for your configuration is defined in the *hal.h header file, line 237.

The register access in the PDI HAL Test app are for read only at this point, since there is no stack there are no register writes shown in the example/reference. Also the slave node doesn't have to be operational for register/RAM access. PDI has access to the memory space as per the ET1100 spec.

The current time line for the stack based demo/example release looks like end of 3rd quarter.


Best Regards
Santosh Athuru

1.The header file you mentioned reaches only to line 158 if I am correct on pressuming that you mean the ethercat_slave_c28x_hal.h header file.

2. TI instead of providing an xml ENI file provides a bin file that Twincat is not recognizing and consequently I am still unable to write EEPROM accordingly.

3. Do you have any update on the release of the new "tutorial" concerning EtherCat implementation?

Stamatis,

stamatis athiniotis said:

1.The header file you mentioned reaches only to line 158 if I am correct on pressuming that you mean the ethercat_slave_c28x_hal.h header file.

on above, I apologize, I should have mentioned to download the latest SW from web (http://www.ti.com/tool/tidm-delfino-ethercat ), the SW is updated in June 2017. 

stamatis athiniotis said:

TI instead of providing an xml ENI file provides a bin file that Twincat is not recognizing and consequently I am still unable to write EEPROM accordingly.

On above, in the current release there is no EtherCAT slave stack support and there is no EtherCAT slave application profile support. So there is no ENI file. The upcoming October 2017 release will have all these. 

The documentation provided shows how to program the EEPROM in section 2.4, figure 24 and figure 25. Once you click browse, point to the binary file for the PDI port in the browse window.

stamatis athiniotis said:

Do you have any update on the release of the new "tutorial" concerning EtherCat implementation?

Yes, this is planned to be released in October 2017. We will have collateral SW for customers to generate EtherCAT slave stack sources and a sample demo application sources using the SSC tool (from ETG website).  This is being planned as a controlSuite update.

Hope this helps.

Best Regards

Santosh Athuru

Thank you for your immediate response and for eagerly answering to every question I pose. I sincerely appreciate your work.

1)"On above, in the current release there is no EtherCAT slave stack support and there is no EtherCAT slave application profile support. So there is no ENI file. The upcoming October 2017 release will have all these."

So If I want to follow the already given tutorial to see the registers of the memory, I definitely need the ENI file (it is precisely documented). From what you are saying I must infer that currently, I can not evaluate the PDI from C28x MCU, accessing ET1100 ESC registers and RAM because the xml file is not provided. So the aforementioned step is not doable and the tutorial is incomplete and I have to wait for the next version to even evaluate the PDI?

Thank you

Athiniotis Stamatis

Athiniotis,

I believe the screen shot is confusing if you look for the blue selection on the left pane. Please follow the the text mentioned in step 3 , it mentions, click browse (on the window shown in snapshot) and select the respective EEPROM file from the downloaded sw/master_files directory.


Best Regards
Santosh Athuru

Mr Santosh Athuru, 

This is exactly what I have been trying to do but no matter what I do, the outcome is on the following screenshot

Athiniotis,

The errors that you see in the screen above are fine. It is because you are not running an EtherCAT slave stack on the MCU yet. The purpose of the EEPROM file that you programmed on the ESC is just to enable the PDI interface. The PDI HAL API Test app can now access the ESC memory using the provided HAL. The PDI HAL API Test is not running any EtherCAT stack, so the EtherCAT master will not be able to put the slave node through statemachine and to OP state.

Once you programmed the EEPROM, follow through section 4.1 to test the PDI interface access.

If you are concerned to check if EEPROM is programmed correctly or not, then you can check by reading EEPROM from the TwinCAT itself.

Best Regards

Santosh Athuru

Mr Santosh Athuru,

You mean that now EEPROM is written properly at the ESC? The sign "Box 1(P00000002 R03160002)" is correct? Because according to the Smart View Window (step 2.4.4) should have the indicated properties whereas in my situation when i Browse and fine the appropriate bin file for spi communication and click it, the Smart View Window remains empty.

Stamatis,
yes. The EEPROM should be programmed correctly. The Box 1 name shows up like that because there is no ESI file for this slave with TwinCAT.

The smart view window gets populated after you click Read E2PROM button. It is not auto populated on the write.

Best Regards
Santosh Athuru

Hello again mr Santosh Athuru,

I followed your instructions and ecerything worked fine until the part of the code that is depicted on the following picture. It seems that pdicontrol is not being updated and the register ii reaches the value 0x100 and then the function ESC_signalFail is triggerd. Hence there is no registers update. Do you know why the this is the case? Have I done anything wrong regarding the hardware? The only pins connected are: 

• EEPROM LOADED
• SPI_SEL
• SPI_CLK
• SPI_INT
• SPI_DO
• SPI_DI
• GNDs and 5V supply

Thank you

Hello again Mr Santosh Athuru,,

I also tried to uncomment the lines regarding the Slave_Select pin in case that it caused the trouble but unfortunately the stack provides an error and is not accessing the aforementioned registers. DO you have any other suggestions?

Athiniotis Stamatis

Stamatis,

can you verify if the SPI is working fine? did you have to update the code to see if the SPI signals used by SW are same as connected in HW? The PDI control has to be read correctly before you can do anything with the ESC. PDI Control reading zero means that SPI reads didn't work, so you should be debugging SPI.

Best Regards

Santosh Athuru

Mr Santosh Athuru,

Hardware connections for SPI are the following:

EEPROM_LOADED -> GPIO20 = Pin 34 (Launchpad)

SPI_SEL -> GPIO19 = Pin 75 (Launchpad)

SPI_INT -> GPIO78 = Pin 11 (Launchpad)

SPI_D_I (MOSI) -> GPIO58 = Pin 15 (Launchpad)

SPI_D_o(MISO) -> GPIO59 = Pin 14 (Launchpad)

SPI_CLK -> GPIO60 = Pin 7 (Launchpad)

GND -> Pins 1, 10, 19, 28, 37, 46 of ESC

5V(supply) -> Pins 47 & 49 of ESC

From the stack and the pdf I see that these pins are the only pins needed for the establishment of communication. Am a missing anything crucial?

Best regards

Athiniotis Stamatis

Moreover,

Do i have to connect GPIO61 or change the stack of the project in order to function properly?

Athiniotis Stamatis

Stamatis,
we are about to release a stack based example and solution project with a HW kit to web shortly. So I've been busy with that.

We plan to get back to your test set up and help debug once we are through the release, mainly connecting FB1111 SPI board to a launch pad. From the initial review the signals look good, if you have programmed the SPI EEPROM binary configuration correctly then it should work, I will also try to test with a FB1111 SPI board and let you know.

Best regards
Santosh Athuru

Hello mr Santosh Athuru,

I am intensely interested and eager for this new project and your limited time is totally understood. Looking forward for the new release and hope it is applicable to my already HW.

King regards

Athiniotis Stamatis

Hello Stamatis,
I understand, the new software is for an EtherCAT kit that can be ordered from TI, I will update you with the weblink once it is live. I would suggest you to order the kit and explore the HW/SW and you should be able to move the SW to your HW with minimal effort and having the kit with you from TI also helps us direct your debug.


Best Regards
Santosh Athuru

Hello Stamatis,

The new EtherCAT kit webpage is live, once the controlSuite is updated you can get the new SW support for the kit.

www.ti.com/.../tmdsecatcncd379d

Best Regards
Santosh Athuru

Hello mr Santosh Arthuru,
1)Thank you for letting me know. I have already ordered the dual core launchpads that I plan to use in my application (Launchxl F28379d) but in the meantime I want to test the project in my already purchased launchxl F28377s. Is it possible to do so without major alterations? 

Thank you

Stamatis,
I would suggest you to order at least one TMDSECATCNCD379D kit so you have a reference.

It should be possible to adapt and use the SW delivered for TMDSECATCNCD379D for your HW. Check section 4.1.2 of www.ti.com/.../spruif9.pdf

The Demo binary files delivered for TMDSECATCCND379D will not work for LAUNCH PADs but the PDI HAL API Test (no stack support) and the Solution reference project (www.ti.com/.../spruig9.pdf) which lets users do stack level evaluation/build can be adapted abnd used for LAUNCHPADs. Just follow the steps in www.ti.com/.../spruig9.pdf user guide and build the project by enabling the SPI port as needed, the default SPI port enabled is SPI C. Cross check if the SPI signals in the project and your HW are same or not.


Best Regards
Santosh athuru

Mr Santoshu,

I have already done the suggestions you mentioned following the steps described in the Reference Solution.

1) In the predefined variables I changed from SPI C to SPI B that are available in my launchpad

2) The connected pins are:

• EEPROM LOADED->GPIO20(changed the code)
• SPI_INT  -> GPIO78(changed the code) 
• SYNC0 -> GPIO62(changed the code) 
• SYNC1 -> GPIO4(changed the code) 
  • ESC_RESET_ET1100_GPIO -> Not connected because my ESC (FB1111 0141) does not provide reset pin (does this pin stimulate the error?)
• SPI_SEL B -> GPIO66
• SPI_CLK B -> GPIO65 
• SPI_DO B -> GPIO64
• SPI_DI B -> GPIO63
• GNDs and 5V supply

Thank you

Hello Stamatis,

so is that working now? One more thing to check is the EEPROM config (first 15 bytes), I'm not sure but they could be different between the TI ESC board's config and the FB1111 0141 board's config ? can you check with any working FB1111 0141 example/set up and use the same values instead of the ones provided by the TI example ESI file for SPI version?

It is good idea to check why they are different as well?


Best Regards
Santosh Athuru

Unfortunately no it is not working,

1)I stepped into the code and it stops it the following do-loop and I can not understand why.

2) The EEPROM CONFIGURATION seems fine and since my ESC has the same proccessor ET1100 I do not think that it needs any alteration but I will check it out. Does ti provide any manual for its ESC?

Thank you

TMDSECATCNCD379D reference kit that TI provides use ET1100 ESC, so you will have to refer to the ET1100 ESC only.
Section 3.5 of www.ti.com/.../spruif9.pdf explains the EEPROM config values we have working for the SPI mode 3 with our boards. Can you cross verify it with the working FB1111 board values?

Best Regards
Santosh

Hello again,

1)Using the xls document that Beckhoff provides for the ET1100 ESC (FB1111 has the same ESC with your development kit) and inputting the parameters listed in the reference guide for SPI PDI, the yielded configuration hex code is 0x050E03CC0A0000000000 whereas in the Config.xml provided for your kit the CONFIG Hex code is 0x050E03EE409C00000000 although it should have been the same because we are refering to the same ESC. Moreover I noticed some incongruity in the ESC register address between the xls document attached and your reference guide(see attached screenshots).

2)Do you think that there is any error in my connected pins that I mentioned in earlier comments?

3)Do you know why the program stops at the specific do-loop mentioned in the previous question.

Thank youet1100_configuration_and_pinout_v4.6.xls

Hello again mr Santosh,

I changed the configuration hex code as mentioned in the last post and produced a new sack now the code does not stop in the aforementioned do loop. In fact, it seems like working perfectly fine. However, the ESC remains in INIT state and does not switch to OP state and consequently even though I "online write" the LEDs, the state of the switches does not change. Do you know what is going wrong? The function MainLoop() is constantly running right now.

Thank you

Hello Stamatis,

thanks for the update. So you are running the solution reference project or the PDI HAL API test now after updating the HEX code for your configuration?

Best Regards
Santosh Athuru

Hello again,

1)I am running the solution reference project and it the thing is that it does not switch into operational mode, yet it performs the MainLoop() function over and over again. Do I need to change anything more in the yielded stack in order to make it Operational?

2)I noticed that in the SSC project supplied that yielded the stack, the 16bit microcontroller register is set although TMS320F2837x belongs to the 32bit microntroller family processors. How do you explain this fact?

Response below:

#1> the mainLoop() will keep running and will check for stack statemachine transition requests and other house keeping. having MainLoop running doesn't mean the stack will get operational. Do you try to manually put the slave node to state machine transitions? if yes, does the slave node get to pre-op or safe op? what is the error you see here? can you check for the PDI error counter register and other error counter register on the ESC to see if you need to debug PDI?

#2> the minimum unit of data that can be addressed on a 28x MCU is 16 bits. Which means a byte is 16 bit as well and each address points to a 16 bit in memory.

Best Regards
Santosh

Hello again,

1) When you say to "manually put the slave node to state machine transition" you mean via Twincat? Because if you mean that, I have tried several times and the same error keeps occurring:

2)"can you check for the PDI error counter register and other error counter register on the ESC to see if you need to debug PDI" I am trying to debug the pdi and from what i can infer, it doesn't receive any outputs and the ALEvent register remains 0.

3)Yes but the SSC Tool "asks" if the host microcontroller is of 16 or 32 bit architecture not the minimum unit of data that can be addressed by the uC.

4) There is also a function called SWAPWORD() in the stack that does not do anything and is constantly skipped because there is not any definition of it throughout the code. Is it automatically yielded by the SSC Tool?

Moreover (in the pdi_hal_test that it is still not working properly),

I noticed that the part that it stops is the following:

Although the first read and write is executed successfully and dtest_data becomes 0xBAADF00D. Yet in the second write and read is not executed properly and dtest_data doe not become 0x00000000 so the code stops and eternally executes the ESC_signalFail() function.

Do you know where does the problem stems from? because that might indicate what is causing the error in the Reference guide project.

Thank you

That tells that there is an issue with the SPI port, it is probably failing. Please debug SPI further, you might have to scope the signals and check the timings.

Best Regards

Santosh Athuru

Hello again,

Today I received the Launchxl F28379D and changed to configuration SPI C which is the original configuration for the supplied project (reference Project)

Stepping into the code I noticed that there is another inconsistency between the configuration on the SSC and the SPI Initialization. In fact in the SSC, the yielded Hex code(which is also mentioned in the Reference Design pdf) SPI Mode 3 is selected which is generally translated into CLKPOL=1 & CLK_PHASE=1

 

Yet inside the ESC_initSPIFIFO() it is written for CLKPOLARITY=1 & CLK_PHASE=0 (NOT MODE 3)

Shouldn't  it be: SpixRegs->SPICTL.bit.CLK_PHASE = 1; to match the analogous configuration of the SSC Tool? 

Thank you!

Moreover,

the u16PdiCtrl register remains 65535 as shown ion the image and doesn't change into 0x05 as it should have been.

wait, now I'm confused. I thought you said you were past the PID control read stage and are in mainloop() ?

were you able to order a TMDSECATCCND379D kit? it would help if you have something working to compare with your board.
So with the new LaunchXL board, how are you connecting the FB1111 board? on which connectors is the FB1111 board sitting?

You can change the clock polarity and phase as per your HW/ documentation, I haven't tested the F28379xD with FB1111 SPI port much, but I've tested the SPI access with our ET1100 boards a lot and the provided reference code works. User can modify it as needed as per their HW design.


you have two HW platforms now that you are trying to get to work?
1.> F2837xS launchPAD with FB1111 SPI board (using J1, J2,J3,J4 headers on launchPAD)?
2.> F2837xD LAUNCHXL with FB1111 SPI board (suing J1, J2, J3, J4 headers on launchPAD)?


Best regards
Santosh Athuru

Also, please review this forum post as well
e2e.ti.com/.../631455

Hello mr Santosh,

I am responsible for the haze and sorry for that and I will try to make everything clear now. 

1) With my previous board (launchxl f28377s), indeed, i had gone past the PDI control read stage and was in mainloop() but the ESC did not change into Operational State. However, with my new board(launchxl F28379D) that I got today I tried both SPI A and SPI C (changed both the connected pins and the predefined symbols to match) but I could not get past the PDI control stage. As I mentioned earlier the register u16PdiCtrl remains 65535(0xFFFF) whatsoever and does not advance to main loop(). -In both cases I am referring to the reference guide project-

2) In both cases FB1111-0141 SPI is used as ESC(which like I said before has the ET1100, so configuration MUST be the same for my ESC and your ESC). As a matter of fact, now that I have acquired the new board(launchxl F28379D) I am focusing on this specific HW since this is what I intend to use in my final application.

3)No I haven't ordered the kit that you mentioned because I think that the same configuration should work for my application since we are dealing with the exact same uP (TMS320F28379D) and of course the ESCs have identical Proccessors.

4)You have tested ET1100 with SPI MODE 3 and the provided initialization in the code(CLKPOLARITY=1 & CLK_PHASE=0 (NOT MODE 3)  and it worked?

5)I tried to scope my signals but the clock of the SPI is 100MHz and my saleae L8 did not scope it. Should i diminish the clock frequency in order to test it?

Thank you

I believe SPI is at 20 MHz and yes the SW delivered with the TMDSECATCCND379D kit works for SPI as well as EMIF. Even though it is the same ET1100, the EEPROM configuration could vary, there was other forum user who was using a different polarity of the BUSY signal on EMIF and it took a while to debug. So it will be a good idea to checkout the differences in your schematic and ours.

For your #4> yes, you can verify this if you have the kit. At this point we don't have enough time to replicate the set up you have with the FB1111 board with a LAUNCHPADXL but it will be best if you could get the kit and try it on. The EtherCAT daughtercard adapter from the kit can be used with F28379D LAUNCHXL as well and with some minor SW modifictions (SPI port options) you can have the SW working on LAUNCH PAD environments.

For the level of evaluation you are doing, it will defintely help and cut down your development cycle if you have a couple of TMDSECATCNCD379D kits with you.

Hope this helps.

Best Regards
Santosh

Hello again,

I have scoped the signals of SPI while trying to access the 0x0140 address to clarify if there is a proper PDI. I thnk that SPI Configuration is correct. Moreover as I have mentioned previously, in your configuration it is clearly stated that SPI mode 3 is used. However, in the SPIInit() function it is declared differently. In my code I tried both yours and mine CLKPOL and CLKPHASE but neither worked as expected.

The scoped signals(besides somi) are

Stamatis,

thanks for posting the solution. Please use forums if you have anymore questions. 

Best Regards

Santosh Athuru

Statimatis,

and the SYNC configuration is up to the user, one can choose whatever the ESC supports. The reference example is set to use active HIGH and the C2000 MCU interrupt detection is set accordingly if you look at the source code.  The documentation is more of a EEPROM byte to the functionality description and we put it there for users to understand it better, it might not necessarily be a one-to-one match with the reference example.

Best Regards
Santosh Athuru