• State Resolved
  • Replies 7 replies
  • Subscribers 84 subscribers
  • Views 92 views
  • Users 0 members are here
Support feedback
Options
Options
Related

TMS320F28388D: Does CLB Local Mux input ECAPxIN0 reflect ECCTL0.INPUTSEL ?

Pierre Bouchet1
Expert 2615 points

Part Number: TMS320F28388D

Hello,

I'm trying to use the CLB local mux entry ECAPxIN0 (driverlib CLB_LOCAL_IN_MUX_ECAP_ECAPIN, local mux select 11 per Table 9-4 in SPRUII0F) to bring an external GPIO signal into a CLB tile via an eCAP module. My Input X-BAR and CLB Input X-BAR are both fully allocated and AUXSIG channels are scarce, so I was looking for an alternative routing path. My bench results suggest my understanding of the signal is wrong, and I'd like to confirm what ECAPxIN0 actually represents on F2838x.

Setup (device: TMS320F28388D, target tile: CLB4, so the relevant module per Table 9-4 is eCAP7):

  • A GPIO carrying a toggling signal is routed to INPUTXBAR10 via InputXbarRegs.INPUT10SELECT.
    INPUTXBAR10 is independently routed to a GPIO via AUXSIG6 for monitoring and the signal is clearly visible on the scope on that GPIO.
  • In the eCAP7 configuration registers:
    • PCLKCR3.bit.ECAP7 = 1
    • ECCTL0.bit.INPUTSEL = 9
    • ECCTL2.bit.CAP_APWM = 0
    • ECCTL2.bit.TSCTRSTOP = 1
  • CB4:
    • CLB_configLocalInputMux(CLB4_BASE, CLB_IN2, CLB_LOCAL_IN_MUX_ECAP_ECAPIN)
    • Synchronizer enabled.
    • The same input was tested with CLB_LOCAL_IN_MUX_EPWM9A and EPWM9A is correctly visible at the CLB output, so the routing through CLB4 to the scope is known good.

 

Via JTAG I can confirm at runtime:

  • PCLKCR3.bit.ECAP7 = 1
  • ECCTL0.bit.INPUTSEL = 9
  • TSCTR is incrementing
  • INPUTXBAR10 is toggling on the scope. 

The CLB4 output driven from ECAP_ECAPIN shows a constant high level with no edges. Substituting CLB_LOCAL_IN_MUX_EPWM9A on the same input immediately shows that signal.

Question: What is the actual source of the ECAPxIN0 signal feeding the CLB local mux on F2838x?

  1. Is ECAPxIN0 the eCAP capture input after the ECCTL0.INPUTSEL mux, or a different point in the datapath not affected by INPUTSEL?
  2. Is it perhaps the dedicated ECAPx input from the GPIO peripheral mux that F2838x no longer exposes (per the F2837x to F2838x migration note SPRACQ1 eCAP capture inputs are now routed exclusively through Input X-BAR)?
  3. If it is the post-INPUTSEL signal, is there any other configuration required to make it visible?

Thanks,

Pierre