• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 83 subscribers
  • Views 470 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMDSECATCNCD379D: Can CPU interrupt (e.g. PWM, external) corrupt EMIF r/w operation?

Yiu Hang Li
Intellectual 460 points
Part Number: TMDSECATCNCD379D
Other Parts Discussed in Thread: CONTROLSUITE, C2000WARE

Hi there,

We are still working on integrating ethercat slave stack code (SSC) with our motor servo control.

The SSC has 2 parts:
(1) receiving interrupt from ethercat slave controller (ESC) for cyclic data exchange
(2) infinite loop function in main for one time data transfer.
Both parts will communicate with ESC via EMIF.

We are worried with the following scenario. Let say 16bit EMIF for async ram, If (2) is half way of an r/w operation (e.g. reading an int array with for loop) and there is an interrupt from (1).

My question is:
(a) Will (2)'s r/w be suspended or corrupted? (by corrupt I mean like when SPI r/w who must have atomic access or the operation will be meaningless)
(b) Which r/w operation from (1) or (2) will be prioritized?

My guess:
(guess for a) Won't corrupt, CPU will finished the current 16 bit r/w, suspend (2), run (1)'s ISR, then resume with what's in (2)
(guess for b) based on (guess for a), CPU will prioritize (1)'s operation
Which my guess is based on TMS320F2837xD reference manual and this post e2e.ti.com/.../685593. I understnad this post was asking something quite similar but it is on sync ram. I would like to know do async ram work the same way?

Also we are concerned because in SSC's hardware abstraction layer, r/w functions for (1) and (2) to ESC are separated. All r/w function for (2) will disable interrupt first before the actual operation. This make sense for SPI but if (guess for a) and (guess for b) are true why same treatment EMIF then?

Additionally I have also consider using CLA or DMA. But I imageine there will be the following difficulties, please correct me if I am wrong:
(CLA) CLA's program need to occupy a whole LSx ram, data though can be mixed with CPU's program/data in other LSx RAM. But we are already running low on LSx RAM.
(DMA) DMA can only access GSx RAM, but CPU's program & data reside in LSx RAM. So even DMA do the EMIF r/w, there need to be an buffer on GSx ram. CPU need to do another r/w itself to copy the result to/from LSx RAM

Based on my concern with (CLA) and (DMA), I have also consider moving some of the sections in link cmd file to GSx RAM, by doing so:
(consq for CLA) can spare a LSx RAM for CLA's program
(consq for DMA) DMA can directly access CPU program's data?
Is this possible? Even if so will there be any adverse effect (e.g. slower perofrmance)? Since in controlSUITE, none of the link cmd file utilize GSx RAM (beside the DMA example) which seems like a waste for such big chunk of memory. Also I am having a hard time decipheriing the meaning of different sections in link cmd file, where can I look for related info?

Thanks for reading. Any reply is appreciated :D

  • 0
    TI__Guru** 115881 points

    Hi,

    My guess:
    (guess for a) Won't corrupt, CPU will finished the current 16 bit r/w, suspend (2), run (1)'s ISR, then resume with what's in (2)
    (guess for b) based on (guess for a), CPU will prioritize (1)'s operation

    Your understanding is correct.

    Also we are concerned because in SSC's hardware abstraction layer, r/w functions for (1) and (2) to ESC are separated. All r/w function for (2) will disable interrupt first before the actual operation. This make sense for SPI but if (guess for a) and (guess for b) are true why same treatment EMIF then?

    I did not understand this question. Are you asking why NOT same treatment for EMIF ?

    (CLA) CLA's program need to occupy a whole LSx ram, data though can be mixed with CPU's program/data in other LSx RAM. But we are already running low on LSx RAM.
    (DMA) DMA can only access GSx RAM, but CPU's program & data reside in LSx RAM. So even DMA do the EMIF r/w, there need to be an buffer on GSx ram. CPU need to do another r/w itself to copy the result to/from LSx RAM

    This is correct.

    Based on my concern with (CLA) and (DMA), I have also consider moving some of the sections in link cmd file to GSx RAM, by doing so:
    (consq for CLA) can spare a LSx RAM for CLA's program
    (consq for DMA) DMA can directly access CPU program's data?
    Is this possible?

    Yes, from device architecture point of view, it is possible but in a given application, how data need to be shared between CPU/CLA and DMA need to be evaluated and appropriate method should be used.

    Even if so will there be any adverse effect (e.g. slower perofrmance)? Since in controlSUITE, none of the link cmd file utilize GSx RAM (beside the DMA example) which seems like a waste for such big chunk of memory. Also I am having a hard time decipheriing the meaning of different sections in link cmd file, where can I look for related info?

    I can not see any adverse effect but again, this need to be evaluated for specific application by user. Linker cmd file provided in C2000Ware is just for reference and user need to modify this as per their need. You can get more info about C2000 linker cmd file in this link.

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Intellectual 460 points

    Hi Vivek,

    Thanks a lot for the reply! It really ease my mind to know my guess is correct.

    Regarding the 2nd question, a snippet of code may help explain it more clearly.

    E.g. In c file etherCAT_slave_c28x_hal.c, For the write function used in (2), the SPI version goes like this:

    void ESC_writeWordNonISR(uint16_t wrdata, uint16_t offset_addr)
    {
        DINT;
        ESC_writeSPI(offset_addr, &wrdata, 0x02);
        EINT;
    }

    The EMIF version goes like this:

    void ESC_writeWordNonISR(uint16_t WordValue, uint16_t Address)
    {
        DINT;
        ((((volatile uint16_t *)pEsc)[((Address)>>1)]) = (WordValue));    // EMIF write
        EINT;
    }

    Both disable interrupt (DINT;) before the operation start. It makes sense for SPI, but why for EMIF then? 

  • 0 in reply to Yiu Hang Li
    TI__Guru** 115881 points

    Hi,

    Look like in this case we want to complete the EMIF write in specific time hence do not want to interrupt this process. It's more for predictable behavior, I assume.

    I am looping in EtherCAT expert to confirm on this.

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    TI__Mastermind 30255 points

    Hello

    What Vivek says is correct. Read/write APIs that disable interrupts is a requirement to be compatible with the Beckhoff slave stack code. These APIs are used when reading very time sensitive data and can't afford to be interrupted (ex: reading the SYNC0 cycle time offset).

    Best regards

    Chris

  • 0 in reply to Christopher Chiarella
    Intellectual 460 points

    Thanks for the reply Chris!

    If the disable interrupt is mandatory, then how to avoid missing interrupt during nonISR r/w (the scenario mentioned in my original post)? Because beside interrupt from ESC, we are also using PWM interrupt for motor control which can't be missed

    I can't find any info on SYNC0 cycle time offset. Do u mean ESC system time offset (ESC register 0x0920:0x0927) or object dictionary (OD) 0x10F8 timestamp which is a copy of ESC system time (ESC register 0x0910:0x0917)? In this sense I could understand the time sensitive nature. But in our case we won't be r/w these register.

    I will try to justify it is possible to remove the disable interrupt with the following reaosns, please correct me if wrong:

    In SSC, Most r/w in (2) are only a word (16 bit) which will be prioritized by CPU to finished first before switch to run ISR, so its r/w speed is guaranteed.

    The only places I could find that will r/w more than 16 bit are (with justification after ->):
    * for initialization -> Initialization won't be problem since interrupt is not start yet
    * for OD object 0x10F8 timestamp -> 0x10F8 is not used in our use case, it won't be updated
    * for mailbox r/w -> Not sure, from what I read in program, the mailbox r/w can be interrupt because ESC only start exchanging data when buffer is full or the last 2 word is read?

  • 0 in reply to Yiu Hang Li
    TI__Mastermind 30255 points

    You won't miss an interrupt. Once global interrupts is re-enabled, then you'll receive the PWM interrupt.

    You're correct in that the actual read/writes in the main loop code (not initialization code) are 16-bit which is an atomic operation. You'll likely be able to remove the disable/enable interrupts from the EMIF APIs (not the read/write block APIs) and still operate correctly. This however does differ from the slave implementation spec. I'd recommend at least running the Beckhoff Conformance Test tool to re-confirm proper functionality. 

    Best regards

    Chris

  • 0 in reply to Christopher Chiarella
    Intellectual 460 points

    Thanks for the reply Chris! That's good to know!

    I have read some more on technical reference manual. I think I now understand what you mean by interrupt won't missed, it will pend in PIE module until CPU's interrupts are re-enable.

    This disable/enable interrupt brought us big problem when we were using SPI, hence we are very careful now when switching to EMIF. 

    Any way thanks again for the help Vivek and Chris.