i.MX RT Crossover MCUsのトピックRe: Most Simple Possible XBAR Example - Pin / GPIO Mirror

Most Simple Possible XBAR Example - Pin / GPIO Mirror

r0oland — Wed, 07 Feb 2024 11:23:32 GMT

I have now spend several hours trying to figure this out and I am not sure what is going on.

What I want (as a first step for later more complicated triggering schemes):

Take a signal from one pin and directly output it on another pin via XBAR.

I am using pins D15 and D14 on the Arduino Headers of the i.MX RT1064 Evaluation Kit which I have setup using the pin configuration tool of MCUXPresso like so:

pin M14 | D15 | GPIO_AD_B0_00 acts as XBARA1 Input 14

pin H10 | D14 | GPIO_AD_B0_01 acts as XBARA1 Output 15

My code besides the auto-generated code is quite simple, in the main loop I call:

XBARA_Init(XBARA1); XBARA_SetSignalsConnection(XBARA1, kXBARA1_InputIomuxXbarInout14,kXBARA1_OutputIomuxXbarInout15);

I expect to see the input signal on D14 () which is a square wave to be output on D15 ().

However, I see nothing...Any clues to what is going on?

Re: Most Simple Possible XBAR Example - Pin / GPIO Mirror

MultipleMonomials — Wed, 07 Feb 2024 19:31:51 GMT

Hmm, one possible reason here could be that the output pin isn't set to output mode. They don't make this very clear in the docs, but by default, all of the XBAR_INOUTxx pins are set as inputs, and to change that you have to set the bit in IOMUXC_GPR_GPR6. So for your application it would look like:

IOMUXC_GPR->GPR6 |= IOMUXC_GPR_GPR6_IOMUXC_XBAR_DIR_SEL_15_MASK

I thought that the IDE was supposed to generate this automatically if you configure XBAR pins as outputs, but maybe it isn't for some reason.

Re: Most Simple Possible XBAR Example - Pin / GPIO Mirror

r0oland — Thu, 08 Feb 2024 06:45:28 GMT

Thank you for your suggestions. I was also wondering about that, but it seems the IDE did indeed set those XBAR pins correctly. The auto-generated code is not clean but looks correct to me:

IOMUXC_GPR->GPR6 = ((IOMUXC_GPR->GPR6 & (~(IOMUXC_GPR_GPR6_IOMUXC_XBAR_DIR_SEL_5_MASK | IOMUXC_GPR_GPR6_IOMUXC_XBAR_DIR_SEL_14_MASK | IOMUXC_GPR_GPR6_IOMUXC_XBAR_DIR_SEL_15_MASK | IOMUXC_GPR_GPR6_IOMUXC_XBAR_DIR_SEL_16_MASK | IOMUXC_GPR_GPR6_IOMUXC_XBAR_DIR_SEL_17_MASK))) | IOMUXC_GPR_GPR6_IOMUXC_XBAR_DIR_SEL_5(0x01U) | IOMUXC_GPR_GPR6_IOMUXC_XBAR_DIR_SEL_14(0x01U) | IOMUXC_GPR_GPR6_IOMUXC_XBAR_DIR_SEL_15(0x00U) | IOMUXC_GPR_GPR6_IOMUXC_XBAR_DIR_SEL_16(0x00U) | IOMUXC_GPR_GPR6_IOMUXC_XBAR_DIR_SEL_17(0x01U) );

What is even stranger, I kept working on this yesterday and it seems to be working as expected for XBAR1_XBAR_IN16 and XBAR1_XBAR_OUT17, i.e. I change the pins on the header to D9 (pin M11) and D8 (G11) and now things work as expected.

I am wondering if there is a bug with pins 14/15 either in some of the auto-generated IDE code or if something is preventing those pins to be used as intendend?

Would be great if someone could doublecheck with an EVAL kit if it's just me...

Re: Most Simple Possible XBAR Example - Pin / GPIO Mirror

MultipleMonomials — Thu, 08 Feb 2024 18:51:40 GMT

Wait, that auto generated code *doesn't* look right:

IOMUXC_GPR_GPR6_IOMUXC_XBAR_DIR_SEL_15(0x00U)

I think that should be a 1 to mark the pin as output.

Re: Most Simple Possible XBAR Example - Pin / GPIO Mirror

r0oland — Wed, 14 Feb 2024 07:44:15 GMT

As far as I can tell it's an issue with pins D14 and D15 on the header. Using other pins seems to be working fine...Would be great if someone from NXP could confirm / deny this, but I doubt they ever read this...

Re: Most Simple Possible XBAR Example - Pin / GPIO Mirror

mjbcswitzerland — Wed, 14 Feb 2024 19:13:57 GMT

Hi

Do you see anything when watching this XBAR video?
https://www.youtube.com/watch?v=zNWIG-O7ZW0

If I find some time I will run the RT 1064 simulation to see how it reacts to your configuration.

Regards

Mark

Re: Most Simple Possible XBAR Example - Pin / GPIO Mirror

mjbcswitzerland — Wed, 14 Feb 2024 23:21:00 GMT

Hi

I just set up the code in the uTasker project for the RT1064:

POWER_UP_ATOMIC(2, XBAR1_CLOCK); // ensure that XBAR1 is powered
IOMUXC_GPR_GPR6 &= ~(IOMUXC_GPR_GPR6_IOMUXC_XBAR_DIR_SEL_14); // ensure XBAR_INOUT14 is an input
_CONFIG_PERIPHERAL(GPIO_AD_B0_00, XBAR1_INOUT14, PORT_DSE_MID); // select XBAR_INOUT14 on GPIO1_IO00 (GPIO_AD_B0_00) alt. function 1
IOMUXC_GPR_GPR6 |= (IOMUXC_GPR_GPR6_IOMUXC_XBAR_DIR_SEL_15); // set XBAR_INOUT15 as an output
_CONFIG_PERIPHERAL(GPIO_AD_B0_01, XBAR1_INOUT15, PORT_DSE_MID); // select XBAR_INOUT15 on GPIO1_IO01 (GPIO_AD_B0_01) alt. function 1
XBAR1_IOMUX_XBAR_OUT15(XBAR1_IOMUX_XBAR_INOUT14_IN); // connect the XBAR_IN14 input to XBAR_OUT15

and ran the simulation and GPIO_AD_B0_01 followed GPIO_AD_B0_00.

Then I loaded the code to the EVK and wanted to verify on D15 / D14 of the headers but couldn't find the signals there. Instead these are GPIO_AD_B1_00 and GPIO_AD_B1_01.

These pads have no XBAR function and so maybe you misread the circuit diagram?

Regards

Mark

Re: Most Simple Possible XBAR Example - Pin / GPIO Mirror

mjbcswitzerland — Thu, 15 Feb 2024 00:11:45 GMT

Hi

For completeness I also tested a version (simulation and on EVK HW) for D9 and D8:

POWER_UP_ATOMIC(2, XBAR1_CLOCK); // ensure that XBAR1 is powered
IOMUXC_GPR_GPR6 &= ~(IOMUXC_GPR_GPR6_IOMUXC_XBAR_DIR_SEL_16); // ensure XBAR_INOUT16 is an input
_CONFIG_PERIPHERAL(GPIO_AD_B0_02, XBAR1_INOUT16, PORT_DSE_MID); // select XBAR_INOUT16 on GPIO1_IO02 (GPIO_AD_B0_02) alt. function 1: J24-2 on EVK
IOMUXC_GPR_GPR6 |= (IOMUXC_GPR_GPR6_IOMUXC_XBAR_DIR_SEL_17); // set XBAR_INOUT17 as an output
_CONFIG_PERIPHERAL(GPIO_AD_B0_03, XBAR1_INOUT17, PORT_DSE_MID); // select XBAR_INOUT17 on GPIO1_IO03 (GPIO_AD_B0_03) alt. function 1: J24-1 on EVK
XBAR1_IOMUX_XBAR_OUT17(XBAR1_IOMUX_XBAR_INOUT16_IN); // connect the XBAR_IN16 input to XBAR_OUT17

Therefore my conclusion is a mis-read of the diagram and the code itself is fine and operational

Regards

Mark

Re: Most Simple Possible XBAR Example - Pin / GPIO Mirror

r0oland — Thu, 15 Feb 2024 07:06:13 GMT

Dear Mark,

thanks a lot for taking the time and checking this. I think I figured out what happened:

The Eval-Board apparently has an error in the schematic for header J24 Pins 9/10 D14/D15.

The routed signals are GPIO_AD_B1_00 and GPIO_AD_B1_01, but they "should" be GPIO_AD_B0_00 and GPIO_AD_B0_01.

Here is my thinking:

- pins GPIO_AD_B1_00 & 01 are already routed to J23 and it seems illogical to route the same pins twice to the Arduino headers

- the MCUXpresso IDE thinks those header pins are connected to pins M14 and H10, i.e. GPIO_AD_B0_00 & 01, which would make more sense to route to J24 when looking at the other pins routed to J24.

There is definitely a mismatch between MCUXpresso IDE and the schematic.

I didn't double check the signals in the schematic since MCUXpresso so far has worked fine...leason learned.

Re: Most Simple Possible XBAR Example - Pin / GPIO Mirror

r0oland — Thu, 15 Feb 2024 07:32:08 GMT

I just doubled checked with the latest SDK and IDE and the error is still there. Is there an official way to issue a bug report with NXP?

Re: Most Simple Possible XBAR Example - Pin / GPIO Mirror

MultipleMonomials — Thu, 15 Feb 2024 10:19:47 GMT

Hmm, maybe this an EVK rev A thing? I know that on the MIMXRT1050 EVK rev A, they routed the signals like this, and then they changed it to AD_B1 signals because D14 and D15 need to support I2C to comply with the Arduino pinout (even though it means those signals are on the headers twice).