Bringing up the CAN buses on NavQPlus

CAN 2.0

CAN-FD

There is an LED next to each CAN bus PHY on the board that will light up after running one of these commands.

These interfaces support the Linux SocketCAN library. Here is a good link showing some simple SocketCAN example code:

CAN Bus Locator

There are four CAN-FD connectors, they are connected "pass-through" style so that the bus may continue on, or a termination resistor network be plugged in.

• J21 and J22 are connected to CAN1 hardware signals / CAN0 logically in Software

• J19 and J20 are connected to CAN2 hardware signals / CAN1 logically in software

CAN Bus Schematic

CAN BUS LEDs

These LEDS are connected to the enable signal going to the CAN PHY

CAN BUS SIC PHYs

NavQPlus uses TJA1463 CAN SIC PHYs. These are compatible and drop-in replacement for traditional CAN-FD PHYs.

The TJA1463 CAN signal improvement capability (SIC) transceiver with sleep mode is part of the TJA146x transceiver family that implements CAN SIC as defined in CiA 601-4. By meeting the CAN physical layer as defined in ISO11898-2:2016 and SAE J2284-(1-5), the TJA1463 is fully interoperable with high-speed classical CAN and CAN FD.

CAN signal improvement significantly reduces signal ringing on a network, allowing reliable CAN FD communication to function at 5 Mbit/s in larger topologies. In addition, the TJA1462 features a much tighter bit timing symmetry performance to enable CAN FD communication up to 8 Mbit/s.

The TJA1463 is backwards compatible and a drop-in replacement for classical CAN and CAN FD transceivers, such as NXPs TJA1043 and TJA1443

Potential improvements

Because of their improved reliability handling of bus signals, it may be possible to implement:

• Higher bus speeds (Note however that 512kBaud negotiation speed remains the DroneCode standard and is also most common in automotive applications)

• Unterminated/poorly terminated stubs

• Central termination of the CAN bus

CAN Termination

The preferred split termination method from Automotive applications is applied on board the NavQPlus. These parts may need to be removed if you wish to terminate your CAN bus at a different node. Note that as mentioned above, it may be reasonable to use the NavQPlus as a central termination point in a CAN-SIC network.

Additional CAN boards

Shown below is an example of the NavQPlus attached to a "CAN Node" board. A small termination network board is included with the UCANS32K1SIC. The CAN Node board can used for generic CAN-SIC (CAN-FD) node development for sensors and actuators. Essentially it is an S32K1 automotive MCU with the UART/SPI/I2C/PWM pinned out for general purpose use.

You may wish or need to modify your NavQPlus to accept additional camera types. This is not difficult, but does require care.

The Production "RevB version" of the NavQPlus makes a small adjustment to the MIPI CSI Clock line in order to be more compatible with a variety of image sensors. This is also the configuration used with the OV5645 fixed focus image sensors from Innowave that ship with the RevB board As shown in the image below, the resistors R21 and R37 shoudl be 0 Ohm (or solder jumpers) and the resistors R22 and R38 should be removed. (DNP/DNI).

This image uses Netplan to configure the network manager which is "Networkmanager".

Setting the IP address using ifconfig will NOT be applied persistently, and can/will be overridden periodically by Networkmanager This manages network conflicts for controlling IP networks like Ethernet and WiFi. Network Manger has several command line utilities

• nmcli to get current network status

• nmui is a termnial user interface to modify connections

  • set static IP/ DHCP

  • set DNS

  • connect to a wifi network

Examples are provided in the and sections.

You can follow this tutorial below in order to set Static IP with NavQ+ :

Connecting the Innowave OV5645 Camera

<todo> add more detail

The innowave camera comes pre-installed with the latest revision (2024) of the NavQPlus. It is a fixed focus camera unlike the autofocus google coral camera. The installation and removal is very similar to the the instructions below for the Google coral camera.

The flex cable has marking on it "this side up" that should be visible when looking at the connector side of the board. i.e you can read "this side up" and also read the silkscreen "CSI 1"on the bottom of the board at the same time.

Connecting the Google Coral Camera

Pin 1 (P1) on the Google Coral Camera should be connected to the pin with the arrow on the MIPI-CSI port. Please see the images below. The sides with the red box should line up. You should see the blue on the flex cable when connecting to the MIPI-CSI port.

Camera Mount

Depending on your kit, there may be a tall or short camera mount included. The short version typically ships with the NavQPlus or drone itself, while a tall version may come with an MR-Buggy3 development kit. Please refer to the image below for information on how to assemble.

The camera mount is provided unassembled.

Introduction

UART1 is assigned to communicate with the Bluetooth portion of the WiFi/BT Wireless module on the NavQPlus Baseboard. Therefore it is not available for general use (outside of creating your own modified custom baseboard).

UART1 interface voltage

The signaling from the SOM to the NavQPlus carrier board on J16 is at 3V3 but the Murata 1ZM expects 1.8V. The level conversion is done using U26.

Software

Murata WiFi BT Module

The module is using the NXP 88W8987 chipset. Type 1ZM is a small and very high-performance module based on NXP 88W8987 combo chipset which supports Wi-Fi® 802.11a/b/g/n/ac + Bluetooth® 5.1 BR/EDR/LE up to 433Mbps PHY data rate on Wi-Fi® and 3Mbps PHY data rate on Bluetooth®. The WLAN section supports SDIO 3.0 interface and the Bluetooth® section supports high-speed 4-wire UART interface and PCM for audio data.

The 88W8987 implements highly sophisticated enhanced collaborative coexistence hardware mechanisms and algorithms, which ensure that WLAN and Bluetooth® collaboration is optimized for maximum performance.

In IEEE 802.11ac mode, the WLAN operation supports rates of MCS0 - MCS9 (up to 256 QAM) in 20MHz, 40MHz and 80MHz channels for data rate up to 433Mbps.

Type 1ZM module is packaged in an impressively small form factor that facilitates integration into size- and power-sensitive applications such as IoT applications, handheld wireless system, gateway and more.

Introduction

UART3 is available for general use. Hardware flow control is supported.

Note from the schematic clip below, that the MPU can multiplex these signals with SPI1. This is normally configured in the Linux image and is not the default configuration.

UART3 Interface voltage

The signaling from the SOM to the NavQPlus carrier board on J9 is at 3V3 but the Murata 1ZM expects 1.8V. The level conversion is done using U26.

UART3 Locator

Schematic

All the UART signals are protected from ESD using the Nexperia IP4292CZ components. This is part of an optimized BOM as they are also required for the USB interfaces. In additional to its exceptional performance the board layout may be optimized because of being able to route traces straight under the component.

Software

UART3 may be accessed as a standard /dev/ttyS_ in Linux. UART3 may be accessed /dav/ttymxc2 in linux <TODO-check wich ttyS number it is>

Introduction

UART4 is available for general use. Hardware flow control is supported.

Note from the schematic clip below, that the MPU can multiplex these signals with SPI2. This is normally configured in the Linux image, and is not the default configuration.

UART4 Locator

UART4 interface voltage

The signaling from the SOM to the NavQPlus carrier board on J11 is at 3V3

Alternative output is on the AUX connector at location J12 also at 3V3 signalling. However this is not the default linux BSP, and would require changes to the dtb files.

Schematic

J11/UART4 is the default location for UART4 signals. Also by default UART4 is assigned to the M7 Core on the i.MX8M Plus. An RTOS such as FreeRTOS or Zephyr would normally use it as the default console to the embedded MCU.

UART NetNames

Note signal names are differed on J11 vs J12. This is only a labelling detail, since the pinmuxing on the chip is used to "move" the UART4 interface from one set of pins on the MPU (and board to board header). In order to route these signals independently on the carrier board, they need their own net names.

UART ESD

All the UART signals are protected from ESD using the Nexperia IP4292CZ components. This is part of an optimized BOM as they are also required for the USB interfaces. In additional to its exceptional performance the board layout may be optimized because of being able to route traces straight under the component.

Software

UART3 may be accessed as a standard /dev/ttyS_ in Linux. <TODO-check wich ttyS number it is>

PCIe signals are on a flex cable connection located on the back of NavQPlus. A PCIe adapter has been prepared by a 3rd party to work with NavQPlus. It is not in production as of yet. Please contact hovergames@nxp.com for more details.

The NXP PCF2131 Nano-Power Highly Accurate RTC with Integrated Quartz Crystal is included on board. The PCF2131 is a CMOS real time clock (RTC) and calendar with an integrated temperature compensated crystal (Xtal) oscillator (TCXO) and a 32.768 kHz quartz crystal optimized for very high accuracy and ultra-low power consumption. This IC has four timestamping hardware inputs. These can log events such as tampering or an enclosure being opened even when no power is applied to the rest of the board. See the Datasheet for this part for more information.

Note this RTC is in addition to the internal RTC for the i.MX 8M Plus.

Note that at time of publishing, there are several Linux drivers available from various public sources, but the one integrated with the NavQPlus BSP does not support this function yet.

A LVDS LCD display interface using 1-2 ribbon cable connectors is available on the backside of NavQPlus. Refer to the schematics for details. This is an advanced configuration to drive LCD glass directly.

A MIPI DSI interface using a ribbon cable connector is available on the backside of NavQPlus. Refer to the schematics for details.

DRAFT DRAFT DRAFT

Rest and PMIC Control "GPIO"

A series of test points are available to access the Reset and PMIC controls one the NavQPlus board. These could be used where a remote button or other external controls are desired.

Misc GPIO Locator

<TODO> - complete mapping from Schematic to board layout (image here)

This chapter will describe some of the hardware features present on the NavQ+.

This hardware interfaces section of the NavQPlus document is intended as a high level look at the connectors present on the board and their intended usage. Here we may also go into more detail where the interface is unique to the NavQPlus carrier board design and where it may differ from the i.MX 8M Plus EVKs. For complete in depth details regarding the IP block providing the specified interface please refer to NXP.com and the datasheet and reference manual for the i.MX 8m Plus system on a chip.

Additional T1 Ethernet boards

The following boards also from the NXP Mobile Robotics team may be helpful when working with 100BaseT1 2-wire Automotive Ethernet. They are an adapter and a network switch. In addition to these baords, you may find other NXP EVKs and 3rd party boards that can also be used. In some cases you may need to adapt the two wire, two pin connector to match your own requrements.

This is a small dongle like board for quickly evaluating T1 Ethernet or to connect a laptop or sensor or companion computer with an RJ45 port into a 100BaseT1 port.

This is an 8-port switch using the automotive Safe and Secure 10 port Gigabit ethernet switch component. Two of the interfaces availeble on this switch IC that are typically used for direct bridging to MPUs are not used. Note that this board is for evaluation and not development. A full EVK board is available for development. The IX industrial interface is designed to directly connect with the Gigabit IX connector on NavQPlus.

Introduction

UART2 by default is the Debug or Console port into the main A53 processors running Linux on NavQPlus. It is possible to reassign its use by modifying the Linux configuration and .dtb files.

UART2 Locator

UART2 interface and voltage

The signaling from the SOM to the NavQPlus carrier board on J10 is at 3V3. Full handshaking with CTS RTS lines is provided:

Console connection

Normal configuration and usage of UART2 is a console for bootup and Linux. The benefit of using the debug/console is that you can observe all details from powerup.

Details of the console connection including the Baud rate are provided under "Serial Console" in the Quickstart section of this gitbook. See the link below:

Introduction

100BaseT1 2-Wire Automotive Ethernet provides 100MBPS connections over simple twisted 2 wires for a distance of up to 15 meters. The line signaling on the wire is not directly compatible with traditional 100BaseTX (RJ45) connections, but a physical adapter may be used. Otherwise it is the same as traditional Ethernet.

T1 is lightweight and reduces the cabling weight. The interface also does not require the use of magnetics, so it also saves weight and cost in that regard. Typically you will find T1 Ethernet used on Radar, Cameras, MR-CANHUBK3 and NXP flight controllers for drones.

This interface is compatible with the T1 Adapter for PC or other embedded devices and the network switch for robotics. and FMURT6 also include T1 Ethernet

T1 Ethernet Locator

J18 is the T1 Ethernet connector and it should not be confused with the similar SE050 Secure-Element NFC connector at the opposite corner of the board. This is a JST-GH 2 pin heade. Technically there is a polarity associated with T1 Ethernet, but the TJA1103 Phy is configured to automatically and transparently swap the polarity as needed. It is still a good idea to attempt to maintain the correct polarity.

NavQPlus uses the TJA1103 T1 Ethernet Phy

is the third-generation product of NXP’s successful family of 100BASE-T1 Automotive Ethernet PHYs. It is perfectly suited to support the rapid expansion of Ethernet to the edge of the network or provide robust connection to domain controllers in the center of the car.

complies with all state-of-the-art conformance test specifications and is designed according to ISO 26262 to meet ASIL B, providing enhanced monitoring and diagnostic features

No magnetics

Unlike traditional Ethernet, a heavy coupling transformer is not used. A small common mode choke and simple passive RC network is used for noise filtering. There is an ESD protection diode used and the communications signals are capacitively coupled. This overall lightweight, small size and cost optimized solution lends itself well to mobile robotics applications.

The Ethernet PHY itself is also extremely small:

T1 Ethernet LEDs

There are two LEDS that connect directly to the TJA1103 PHY.

<TODO - additional description during operation>

T1 Ethernet Schematics

There are several ports which may have or may be configured for GPIO connection. In addition there are several SMT pads designed to allow access to GPIO and signals such as the PMIC controls. Refer to the schematics for details.

<<TODO - add more detail here, and pictures of the schematics. Add an example pin access if available>>

UART4 interface voltage

The signaling from the SOM to the NavQPlus carrier board on J11 is at 3V3

Alternative output is on the AUX connector at location J12 also at 3V3 signalling. However this is not the default linux BSP, and would require changes to the dtb files.

Schematic

Note that J11/UART4 is the default location for UART4 signals. Also by default UART4 is assigned to the M7 Core on the i.MX8M Plus. An RTOS such as FreeRTOS or Zephyr would normally use it as the default console to the embedded MCU. You may note that the signal names are differed on J11 vs J12. This is only a labelling detail, since the pinmuxing on the chip is used to "move" the UART4 interface from one set of pins on the MPU (and board to board header). In order to route these signals independently on the carrier board, they need their own net names.

All the UART signals are protected from ESD using the Nexperia IP4292CZ components. This is part of an optimized BOM as they are also required for the USB interfaces. In additional to its exceptional performance the board layout may be optimized because of being able to route traces straight under the component.

There are multiple UARTS on NavQPlus.

Because of pinmuxing these can sometimes be assigned to different uses and locations depending on the specifics of the Linux BSP and DTB files. The default configuration for NavQPlus LInux image provided at time of publication will be described here. Please double check any notes on your specific Linux Image if something varies from this configuration.

Port configuration

NavQPlus includes two USB 3.0 Type C ports that are capable of acting as PD devices.

PD modes, Controller, Peripheral mode, USB Gadget Mode are configured at compile time, and may change depending on what image you are using.

The default image as of the date shown here configures the USB ports as follows. (Last updated 10/13/2023 )

USB 1:

USB-C port closest to the edge of the board.

This port is used for connecting devices, such as USB-C hubs, cameras, sensors, and more.

USB 2:

USB-C port closest to the middle of the board.

This port is used for powering the board, as seen in the Power page in the User Guide. This port accepts USB-C PD, and also allows data transfer.

USB Gadget Ethernet is supported over this port with the interface usb0.

Accessing the external I2C bus

The i.mx 8M Plus has a number of I2C busses on board. Internally they are connected to a variety of onboard peripherals. Normally you will not need to address these peripherals directly, and they will be handled by Linux drivers.

• I2C1 - SOM only for PMIC control

• I2C2 - MIPI CSI1, LVDS1, DSI

• I2C3 - MIPI CS2, LVDS2, PCIe

• I2C4 - USB1 TCPC, USB2 TCPC, Secure Element, RTC

  • TCPC1 I2C ADDR: 1010001X

  • TCPC2 I2C ADDR: 1010010X

External I2C #6 on AUX Connector

AUX connector: I2C bus #6 is pin-muxed with UART4 to the six pin JST-GH J12 connector and is the external I2C bus is enabled on the AUX port of the NavQ+. By default these are configured for I2C and not UART4 (internal MCU)

A table of the J12 pinout is below. Note that pin 1 is on the left side of the connector:

You only need to use pins 1, 2, 3, and 6 for I2C. These GPIO are 3.3 volt tolerant only.

I2C device detection

To detect that a device is present on the bus, you can run the following command:

You may need to add the 'user' user to the i2c group to access the bus. To do this, run the following command, then log out and log back in:

Secure Element and i2ddetect

The SE050 or SE05x secure element will not respond to an i2cdetect command. "Plug and Trust" software library should be used to interface with the external Secure Element.

I2C (I2C6) Locator

Schematic

A Micro-HDMI interface is provided on the NavQPlus. This may be used to drive typical monitors or small LCD displays. Note only typical display timing and resolution is enabled/supported by default. A standard micro-HDMI cable may be used to connect to a typical monitor, or HDMI embedded displays.

Introduction

The AUX port contain is by default configured for I2C6 + GPIO. Alternative pinmuxing is available on AUX for UART4. Any alternative configurations are not default and need to be configured in the Linux Image and .dtb files

AUX interface voltage

The signaling from the SOM to the NavQPlus carrier board on J12 is at 3V3

Any alternative pinmuxed output configurations on the AUX connector would also be 3V3 signaling.

Aux Locator

Schematic

UART

Note that J11/UART4 is the default location for UART4 signals. Also by default UART4 is assigned to the M7 Core on the i.MX8M Plus. An RTOS such as FreeRTOS or Zephyr would normally use it as the default console to the embedded MCU.

GPIO

J12 "AUX" is includes two pins for GPIO labelled GPT1_CAPTURE1 and GPT2_CAPTURE2

ESD Protection

All the UART signals are protected from ESD using the Nexperia IP4292CZ components. This is part of an optimized BOM as they are also required for the USB interfaces. In additional to its exceptional performance the board layout may be optimized because of being able to route traces straight under the component.

Software

<TODO- describe how to access these GPT pins in software>