2381407_en-US

[#1]

TRGMUX Assistance - MCXE316

I am attempting to use the TRGMUX method to route the output of the comparator LPCMP0 to the input of eMIOS0_CH7 (which is configured an an input capture). I am using the MCXE316 device. Part of my issue is understanding the inputs/outputs and wrapping my brain around the nomenclature, and the second I believe is a bug in the PERI_TRGMUX.h file.

I have the eMIOS0 channel 7 configured as a simple input capture, this works properly when assigned to a physical pin. But, I wish to have the input capture triggered instead by the output of the LPCMP0 comparator. Accordingly I should be able to have TRGMUX route the output of the comparator to the input of the input capture of eMIOS0_7.

I look at the MCXE31_TRGMUX_connectivity.xlsx file attached to the reference manual, and I see on the left side "input number", which I am assuming i the input into the TRGMUX. I see LPCMP_0_COUT listed there, with an input number of 5, what I think I am after. Along the top I see "EMIOS_0_ipp_ind_emios_ch[7]" and I see the output register no. of 9 above it. I also see that channels 5, 6, and 9 also have this same number as well.

So, my first question - how to I tell the TRGMUX that the LPCMP0 trigger output goes to channel 7 and not 5 or 6 or 9? I know that the internals of the TRGMUX register has SEL0, SEL1, SEL2, and SEL3 - do I use one of these to choose the channel selection? If so how is this mapped (SEL0 is channel 5, etc), or is there some other mapping, or no mapping? I have looked in the manual and I have not stumbled on this.

Using my best guess that SEL3 is for channel 7 (just for a test), I attepted to use the TRGMUX method in the SDK - here is my calling sequence:

  TRGMUX_SetTriggerSource(TRGMUX, kTRGMUX_Emios0_1, kTRGMUX_TriggerInput2, kTRGMUX_SourceLpcmp0 );

with the TRGMUX being the register base, kTRGMUX_Emios0_1 is the TRGMUX register for the eMIOS0 (define value is 9), kTRGMUX_TriggerInput2 is the SEL2 input of the register, and kTRGMUX_SourceLpcmp0 is the source of the trigger (define value is 5).

The problem is that the routine throws a hard fault within this method itself. Here is the actual SDK code for this method:

status_t TRGMUX_SetTriggerSource(TRGMUX_Type *base, uint32_t index, trgmux_trigger_input_t input, uint32_t trigger_src)
{
  uint32_t value;
  status_t status;

  value = base->TRGCFG[index];
  if (0U != (value & TRGMUX_TRGCFG_LK_MASK))
  {
   status = kStatus_TRGMUX_Locked;
  }
  else
  {
   /* Since all SEL bitfileds in TRGCFG register have the same length, SEL0's mask is used to       access other SEL
   * bitfileds. */
   value = (value & ~((uint32_t)TRGMUX_TRGCFG_SEL0_MASK << (uint32_t)input)) |
   ((trigger_src & (uint32_t)TRGMUX_TRGCFG_SEL0_MASK) << (uint32_t)input);
   base->TRGCFG[index] = value;

   status = kStatus_Success;
  }

  return status;
}

The routine crashes on the first line
value= base->TRGCFG[index];

If I look at the debug output, it appears that the TRGCFG array has never been initialized - this variable is defined in PERI_TRGMUX.h and the structure is:

/** TRGMUX - Size of Registers Arrays */
#define TRGMUX_TRGCFG_COUNT 40u

/** TRGMUX - Register Layout Typedef */
typedef struct {
__IO uint32_t TRGCFG[TRGMUX_TRGCFG_COUNT]; /**< TRGMUX ADC12_0 Register..TRGMUX CM7_RXEV Register, array offset: 0x0, array step: 0x4, valid indices: [0-1, 3, 6-18, 21-39] */
} TRGMUX_Type;

I am just not finding where the TRGCFG is actually defined anywhere. In the debugger the whole array is set to 199661, all 40 elements, which must be garbage. I am accessing element 9 (index is 9).

So my second question is am I using this method correctly and my assumptions OK or is there an issue within the SDK routine?

Board DesignBoot ROM|Booting | FlashClock|TimersRe: TRGMUX Assistance - MCXE316

Hi @brucebowling 

Thank you for the post!

Your understanding of how the TRGMUX SELx works is correct the EMIOS0_0 is for channel 1 to 4, EMIOS0_1 is for channels 5 to 7 and 9, as shown in the TRGMUX_connectivity.xlsx the channels 0 and 8 are not able. 

Also,

I was able to reproduce the issue on my side. I will review it internally and share any relevant information that may help resolve it.