Pin Mode Multiplexing with XBAR

T

TrapLevel

New member
Hello All,
I'm laying out a new circuit based on the Teensy 4.1 design and want to access more of the features available on the iMXRT1062 including a 16-Bit LCD interface. The challenge I'm having is that the LCD_DATA09 pin (GPIO_B0_13) of the interface is being used in the bootloader connection (Fig 1). My first thought was to use the XBAR feature of the chip to send the LCD_DATA09 signal into XBAR1_IO11 (both on pin GPIO_B0_13 [Fig 4]) and then access it through XBAR1_IO19 (which is on pin EMC_14 [Fig 3]) as shown in Fig 2.

Can XBAR be used to route different internal signals to various pins OR is XBAR only used to route external signals into one pin and out another? If so is there example code to show how to do this?

Follow up question, is there a better way around my problem of an already utilized GPIO_B0_13 pin? Maybe, using another pin in the bootloader interface without having to alter the bootloader code?

Thanks for reading!

Figure 1. Bootloader Interface
Figure 2. Current LCD Interface pin selection with XBAR'd DATA09 pin
Figure 3. Pin EMC_14 MUX control section of the datasheet
Figure 4. Pin GPIO_B0_13 MUX control section of the datasheet
 
You can leave it disconnected from the bootloader, as has been done with several other custom boards.
 
TrapLevel said:
In the meantime, does anyone have a good resource for understanding what XBAR is normally used for? The manual/datasheet isn't as explicit as I need.
Click to expand...
All you need to do is maybe read it like 50 times, and maybe something will make some sense :D

I have played with XBar a few times, and each time it takes a few reads, plus trying code a few different ways, until something might work.

Some places that use them to some extent.

HardwareSerial - You can use an XBAR pin with a Hardware Serial port as an RX pin or as a CTS pin. However if you wish to use one for either of these two uses, you can only do it for one of them... (Per Hardware port).
This is controlled by: port->PINCFG = LPUART_PINCFG_TRGSEL(1); // Trigger select as alternate RX

There is some code in the HardwareSerial.cpp code base, that I did to setup the connections.
like: xbar_connect(pin_to_xbar_info.xbar_in_index, hardware->xbar_out_lpuartX_trig_input);
Which Input is the XPAR pin index, and the output is the XBAR output, for example for Serial1 which is on LPUART6
XBARA1_OUT_LPUART6_TRG_INPUT

ADC library
It uses it to connect a Quad TImer to ADC like: from XBARA1_IN_QTIMER4_TIMER3 to XBARA1_OUT_ADC_ETC_TRIG10
Maybe see ADC library for details.

Audio library:
OctoWS2811 library
QuadEncoder library

Just search through the teensy4 core as well as the different libraries that come with Teensy install that reference xbar_connect
 
Look out! In the above, xenForo has interpreted a [i] as markup to go into italic text - you really can't afford to be lazy and omit CODE tags :cry:
 
TrapLevel said:
In the meantime, does anyone have a good resource for understanding what XBAR is normally used for? The manual/datasheet isn't as explicit as I need.
Click to expand...
XBAR is mostly used for inter-module triggers without requiring the CPU to get involved, e.g. using a timer to trigger ADC sampling at a regular interval. It can't be used to reroute arbitrary pins, especially in this case where the bootloader runs its own code on the CPU (via jtag) that we have no insight into.
 
To get an idea of what XBAR can do, start with "Table 4-8. XBAR1 Output Assignments" which begins on page 68. Those are all the places XBAR can send a signal. At first it seems like a long list, but sadly there are so many things inside the chip which don't connect to XBAR. It's really only able to send signals to those specific places. Many times I've wished it has more stuff connected, but NXP only put certain connections inside the chip.

Then the next step, and the one that's really difficult (at least for me) is understanding what each of those things can actually do with the signal it receives from XBAR. Some are pretty easy, like the serial ports which can use the 1 signal it receives as either RX or CTS input. To actually make use of XBAR, you need to configure the receiving peripheral to actually make use of the signal it gets from XBAR. Often NXP's documentation has that buried among a ton of other details about the peripheral. Some of those, particularly FlexIO, are so poorly documented. :(

Of course you can also approach is from the other side, looking at what signals you can send into XBAR. To be honest, I've really only used pins and timers.

XBAR itself is pretty simple. It just connects any of its inputs to any of its outputs. When you're experimenting with XBAR (or at least when I am) usually the process involves temporarily connecting the signals to actual pins, so you can watch when they really do with an oscilloscope or logic analyzer.
 
@KurtE - Thank you for the example code, this is helpful for getting started


It can't be used to reroute arbitrary pins
Click to expand...
@jmarsh - this is super disappointing but it makes sense why I couldn't find examples of people doing this

@PaulStoffregen - thank you, XBAR does seem pretty simple, I'm disappointed NXP's documentation is so hit or miss. I'm going to go back and reread this section to help understand the IO limits
 
You must log in or register to reply here.
Back
Top