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.

Difficulty getting eCAP5 working on TMS570LC4357 development kit

Other Parts Discussed in Thread: HALCOGEN

I have one of the TMS570LC43x development kits.  I worked through the PWM & eCAP example in HalCoGen and was able to get this fully functional using PWM1 and eCAP1.  I then attempted to extend this to utilize eCAP5 (what I will use in my final application) and I have not been able to get the interrupt to fire.  I think I got everything configured correctly in HalCoGen but obviously I am missing something.  I connected the PWM1 to pin 'H18' on the development kit and I can confirm the PWM output is getting to the pin with an o-scope.  Any suggestions on what I have not connected up correctly to get this interrupt to fire would be very much appreciated.   Attached I have included the project I am trying to get to work.  

I am using CCS V: 6.1.0.00104

I am using HalCoGen V:  04.05.01

6153.ECAPExample.zip

  • Hello:

    We have received your post and will get back to you soon.

    Regards.
  • Hello Chris,

    I think your pinmux is the problem.

    You have:

    pinMuxReg->PINMUX[81] = 0U;

    This means that you are selecting  the ECAP[4,5,6] bond pads that are not present in the ZWT package. Please change to:

    pinMuxReg->PINMUX[81] = 0x02020202U;

    You have the same problem for PINMUX[82]. You should change to pinMuxReg->PINMUX[82] = 0x02020202U also if you want to use eQEP modules in the future.

    There are two bond pads associated with each eCAP module. One is present in the ZWT package and the other one is not. The one that is not bonded out is the default input. When you use eCAP for input capture there is a mux that will select either inputs (one that is present in ZWT and the other not present in ZWT). You happen to select the one that is not present in the ZWT package. Actually, this is not your fault as there is no selection in HalCoGen. I will report to HalcoGen team to either provide option to select the secondary pad or to always select the secondary pad. 

  • Charles,

      Thank you for your response on this subject quickly.  I had found the other post that mentioned this problem and looked into it and did not seem to be the case.  When I open HL_pinmux.c I see the following lines at line numbers 314 & 316:

    "

    pinMuxReg->PINMUX[81] = 0x02020202U;

    pinMuxReg->PINMUX[82] = 0x02020202U;

    "

    I even re-downloaded the .zip file that I attached with my original post and checked this file for that code and it appears to be in place.  Is there somewhere else that I need to be checking these PINMUX configurations or somewhere else that these get set?  

    Thanks,

    Chris

  • Turns out that I had not properly configured the I/O multiplexer on-board the dev kit correctly. I had the Ethernet enabled which remapped the pin on the external header to the internal pin on the processor. So turns out it was a HW issue. Thanks for the help.
  • Chris,

      Glad that you found the problem before me as I was trying to debug your code.

  • Charles,

    I have continued to extend my project to enable both ECAP4 & ECAP5 at the same time (both driven by different PWM's). If I only have the ECAP4 interrupt vector enabled I can get correct interrupts for ECAP4. If I only have ECAP 5 interrupt vector enabled I can get correct interrupts for ECAP5. But if I try and enable both of them I only get interrupts on ECAP4 and ECAP5 (ecap5Interrupt(void)) gets fired. Any thoughts on why I am having difficulty with multiple ECAP modules running together?

    Thanks,
    Chris
  • Hi Chris,

      You are saying if both of them (eCAP4 and eCAP5) are enabled then only eCAP4 is serviced but not eCAP5, correct?

      If you place a breakpoint at the entry to ecap5Interrupt(), does it stop there?

  • Charles,

    This is correct, I am an engineer working on the same team as Chris and we have revisited this problem. Here is what is happening:

    Both eCAP4 & eCAP5 are enabled and being driving be PWM modules, only the eCAP4 interrupt request is serviced. If I place a breakpoint in the ecap5Interrupt() it will never be reached. I can see in the registers that the IRQ flags are set for the eCAP5 module. Furthermore, if I poll the eCAP5 registers in the ecap4Interrupt(), I can then call eCAP5Interrupt() and everything works just fine. It seems we have found a work around for now, but fundamentally this is still incorrect. Perhaps you could have your team investigate this issue a little further to see why the eCAP5 IRQ never gets serviced?

    I have tested both the eCAP4 & eCAP5 modules independently and they work fine, it is just when we are using both that this problem seems to occur.

    Thanks,

    Warren
  • Another update:

    It looks like the highest priority IRQ (in terms of which one is closest to the top in the IVT list) is the one that is always serviced. I enabled eCAP3, 4, and 5 and fed them the same signal. Only eCAP3's interrupt request ever got serviced while both 4 and 5 were left pending.