What is SLCAN?

SLCAN is an interface for CAN communication over a serial line.

Assuming you have successfully connected via the UART and are seeing the PX4/NuttX nsh> prompt, you can try a few things using PX4/NuttX

nsh> help

This will show you basic help as well as list the Builtin Apps.

Try running some of the builtin apps: (Lines beginning with # below are just comments)

As you can see there are also a number of other builtin apps ready to test servo's, I2C devices, SPI devices, and even a GPS when attached.

Testing CAN between two UCANS32K146 boards using PX4 CAN utilities

If you followed the instructions on the previous page to enable CAN utilities in PX4, then follow the steps below to test CAN communication between the boards.

1. Connect two UCANS32K146 boards with the included CAN cable (yellow and white twisted pair with red and black power lines)

2. Connect a termination resistor to each board on the same bus

3. Boot up each board and connect to them using the included debuggers

Once you run the cansend command on the sending board, you should see some output on the receiving board indicating that it received a message with arbitration ID 0x123 and data 0xDEADBEEF.

If this was successful, you have now successfully demonstrated CAN bus communication on UCANS32K146 running PX4.

What is SocketCAN?

SocketCAN is a set of open source CAN drivers and a networking stack contributed by Volkswagen Research to the Linux kernel. Formely known as Low Level CAN Framework (LLCF). -- Wikipedia

Important Notice

NXP provides the enclosed product(s) under the following conditions:

This reference design is intended for use of ENGINEERING DEVELOPMENT OR EVALUATION PURPOSES ONLY. It is provided as a sample IC pre-soldered to a printed circuit board to make it easier to access inputs, outputs, and supply terminals. This reference design may be used with any development system or other source of I/O signals by simply connecting it to the host MCU or computer board via off-the-shelf cables. Final device in an application will be heavily dependent on proper printed circuit board layout and heat sinking design as well as attention to supply filtering, transient suppression, and I/O signal quality.

The goods provided may not be complete in terms of required design, marketing, and or manufacturing related protective considerations, including product safety measures typically found in the end product incorporating the goods.

Due to the open construction of the product, it is the user's responsibility to take any and all appropriate precautions with regard to electrostatic discharge. In order to minimize risks associated with the customers applications, adequate design and operating safeguards must be provided by the customer to minimize inherent or procedural hazards. For any safety concerns, contact NXP sales and technical support services. Should this reference design not meet the specifications indicated in the kit, it may be returned within 30 days from the date of delivery and will be replaced by a new kit.

NXP reserves the right to make changes without further notice to any products herein. NXP makes no warranty, representation or guarantee regarding the suitability of its products for any particular purpose, nor does NXP assume any liability arising out of the application or use of any product or circuit, and specifically disclaims any and all liability, including without limitation consequential or incidental damages.

Typical parameters can and do vary in different applications and actual performance may vary over time. All operating parameters, including Typical, must be validated for each customer application by customer’s technical experts.

NXP does not convey any license under its patent rights nor the rights of others. NXP products are not designed, intended, or authorized for use as components in systems intended for surgical implant into the body, or other applications intended to support or sustain life, or for any other application in which the failure of the NXP product could create a situation where personal injury or death may occur. Should the Buyer purchase or use NXP products for any such unintended or unauthorized application, the Buyer shall indemnify and hold NXP and its officers, employees, subsidiaries, affiliates, and distributors harmless against all claims, costs, damages, and expenses, and reasonable attorney fees arising out of, directly or indirectly, any claim of personal injury or death associated with such unintended or unauthorized use, even if such claim alleges NXP was negligent regarding the design or manufacture of the part.

DRAFT

Show image of PC with USB - UART cable(s) and USB mini power cable connected to CAN-TERM-BRD. Show two UCAN boards connected via the CAN wires. The CAN-TERM boards should be at either end. only one CAN-TERM board should provide 5V power via some USB-Micro cable connection.

NOTE - USB-Micro cable is not included.

A sample application based on PX4/NuttX has been prepared that can be flashed to the UCANS32K1SIC boards. The basic premise is to form a two node CAN-FD network, and give you a console terminal available on each board using

the UART/USB cable connected to your PC.

Simple commands can be issued on each node to initiate CAN-FD communications.

The UCAN boards will be powered via 5V injected through he CAN-TERM board microUSB connection.

What are the UCANS32K1 node boards?

UCANS32K146 and UCANS32K1SIC development boards are general purpose CAN node reference designs. They can be used for any purpose, however specific software has been provided for drones, rovers and other small (autonomous) vehicles. This software allows it to act as a bridge between a CAN bus (with ) and I2C, SPI, UART, GPIO or any other pin function of the (80 MHz ARM Cortex-M4F, ASIL-B compliant). This allows sensors, actuators and other peripherals to be controlled by other devices on the same CAN bus, such as the flight management unit reference design.

Use cases

Possible use cases are:

1. PWM output for motor controllers or servos

   • Relieves the FMU of creating RC-PWM signals

   • Can report information about the motors back to the FMU

Board specifications

• (80 MHz ARM Cortex-M4F, ASIL-B compliant)

• Dual

  • OR Dual NXP TJA1463 CAN-SIC transceivers (with dual )

More information is .

Hardware designs and example software

The hardware schematics and board layout for UCANS32K146 and . We encourage you to create your own designs based on our UCANS32K146 board!

We do not only provide hardware designs, there is also plenty of example software available. There are multiple options to use the UAVCAN protocol. We have also worked with the Apache NuttX and PX4 Autopilot communities to enable their open source software projects on the UCANS32K146.

Additional designs and example software might be made available in the future.

Contribute to this GitBook

We would really like to receive your feedback regarding this GitBook. It is synchronized to a , so you can just open an issue. If you want to contribute you can also open a pull request. The pages are written using an extended version of , so it should be pretty straightforward to add sections or even complete pages!

This work is licensed under a .

Introduction

This tutorial aims to explain how to connect an APA102 based RGB LED "pixel led" board and control light intensity via a Joystick with ROS2.

Items needed

For this demo you will need:

• An APA102 based RGB LED "pixel led" board

• UCANS32K146 or UCANS32K1SIC board

• NAVQ board

Shown below is a RGB LED headlight board (as used in ) with 10 leds numerated fom LED1 to LED10.

Daisy chain connection of APA102 LEDs

The 10-LED PCB board has 4 wired connections: DATA CLK, PWR, GROUND. The DATA line(wire) of the board connects to the Data_in of the first LED. Each LED is daisy chained to the next from Data_out pin of one to Data_IN of the next, and so on.

Connecting the LED board to the UCAN board.

The 10-LED "headlight board" shown here is built from an American standard taillight. The internal board has been changed from a simple "on-bright, on-dim" direct DC wiring to the digital connection to these RGB LEDs. Therefore an extra black wire was added to the plastic assembly.

Arbitrary colored jumper wires were used to connect between the 10=LED headlight board and the SPI port pin header on the UCAN board. The colors used on the UCAN side were as follows:

The wires on the UCAN board are shown connected in the following image:

NOTE that the color codes above are non-standard. They should be checked when any different LED boards are being connected.

NOTE that the power 5V may also PREFERRABLY be supplied by using the servo 5V output and providing external 5V power from the BEC header (BEC = 5V DCDC converter) See below for board reference:

Software procedure

NavQPlus software

Connect to NavQPlus via a serial console or though ssh over Ethernet or Wifi. (See NavQPlus gitbook documentation for more details)

CAN tools

Ensure can-utils and Python are installed on NavQPlus, if not, install the required packages:

Configure CAN bus

Then, reset and configure the NavQPlus CAN bus interfaces:

ROS2 setup

If not already installed, Install ros2_orchestrator ROS packages from GitHub.

<todo: change links from rudislabs to NXP>

Build the package:

run the following command in a bash terminal to automatically set up your ROS environment at startup of a bash terminal:

Then source your bashrc to ensure it is effective in the current session.

Now, run the following ROS command. It will install dependent packages:

After it runs re-source your bashrc and re-run the same launch script:

Open a second ssh session, and run the joy node to begin the connection with the joystick:

Operation of the demo

Now your LEDs are ON and you should be able to control the light intensity.

Use the left and right buttons of the joystick (buttons in front of the device - see picture below) to play with the colors.

S32 Design Studio for ARM

Download and install S32 Design Studio for ARM. It's available for Windows and Linux.

UCANS32K146 hardware setup

• Interconnect two UCANS32K146 boards with a single 4-wire JST-GH CAN cable between both CAN2 connectors, and CAN bus terminators in the CAN1 connectors below.

• Connect a 5V supply to the pin headers.

S32 Design Studio example project

1. In S32 Design Studio, go to "File" and then "Import...":

2. Select "Projects from Git" and click "Next":

3. Paste the Git URL () of the demo and click "Next":

4. Select the master branch and click "Next".

5. Click "Browse", select the desired destination directory for the project and click "Next".

6. Choose "Import existing Eclipse projects", click "Next" and then "Finish".

7. Click the small arrow at the right of the build icon (the hammer) in the toolbar and select NODE_A to build the code for the first board (transmitter).

8. Click the yellow lightning shaped icon in the toolbar for flashing the project to the board.

9. In the list located at the left of the popup window, choose the appropriate profile, e.g. "libuavcanV1_demo_Debug NODE_A" if you are building the code for NODE_A. Then click "Flash" with the board connected to the J-Link debugger. Don't forget to power the board (5V)!

10. Repeat steps 7-9 for the other board but with the desired build configuration changed to NODE_B.

11. A green led close to the 5V headers should blink approximately once a second. Also see the description at the top of the src/main.cpp file. If the green LED from both boards is not blinking, try pressing the reset button on the board that got the NODE_A program flashed into, which is the one that starts the transmission.

With an oscilloscope or logic analyzer you can view the frames being transmitted at 4Mbit/s data phase speed and at 1Mbit/s in nominal phase:

What is NuttX?

NuttX is a real-time operating system (RTOS) with an emphasis on standards compliance and small footprint. Scalable from 8-bit to 32-bit microcontroller environments, the primary governing standards in NuttX are Posix and ANSI standards. Additional standard APIs from Unix and other common RTOS’s (such as VxWorks) are adopted for functionality not available under these standards, or for functionality that is not appropriate for deeply-embedded environments (such as fork()). -- Apache NuttX website

NuttX was created by Gregory Nutt and he has been one of the main developers for a very long time. In 2019 the RTOS was accepted as an incubating project under the Apache Software Foundation, which means it is currently undergoing the process to become an official ASF project. There is now a management committee in place that oversees the ongoing development of NuttX.

NuttX is a very versatile operating system with many (optional) features that supports a wide range of microcontroller platforms. This includes support for NXP's S32K1xx and i.MX RT 10xx, as well as many MCUs from the Kinetis and LPC families.

NuttX is licensed under the permissive Apache License 2.0. This allows it to be integrated into other projects without the need to distribute the derivative work under the same license. Parts of the codebase may still be licensed under the BSD 3-clause license that was used previously, but this should not pose any limitations.

NuttX support for UCANS32K146

A board configuration for RDDRONE-UCANS32K146 is available in the upstream Apache NuttX repositories. As of September 2020, the following features are confirmed to be available:

• Basic support for the NXP S32K1xx family (ARM Cortex-M0+ and M4F)

• SPI, I2C and UART are enabled and can be used in your own drivers and applications

• PWM output using the FlexTimer peripheral is available as well

There is currently no driver support in NuttX for the NXP EdgeLock SE050 secure element.

PX4, NuttX or bare-metal?

is build on top of NuttX, so most of the features that are available in NuttX are also available if you choose to . PX4 uses most interfaces that NuttX provides, but adds additional abstractions and in some cases it bypasses the NuttX interfaces and implements its own API. So there's some differences, but you still get most of the features of NuttX, as well as PX4's , their , as well as many .

However, if you do not plan on using any of the PX4 features and do not need to interface with any other PX4-enabled system, you can also use the UCANS32K146 development board with "just" NuttX. This makes it easier to to your liking without having to worry about breaking the PX4 stack.

There is also a third option. NXP offers a "bare-metal" SDK for the S32K1xx family, and . That means you can use the UCANS32K146 board with UAVCAN, but without any operating system or software stack. Or you can integrate it with other software.

Documentation and getting help

Documentation for NuttX is available on their website:

Their online documentation is not exactly beginner friendly. A few volunteers have stepped forward to help improve the available documentation, but there is still some work to be done. Luckily, the code base is pretty clean and self explanatory (and often well documented within the code itself). With a few pointers in the right direction and some patience you can get pretty far on your own.

The community page on the official Apache NuttX website lists a few ways to ask questions, report issues and get in contact with the main developers:

What is PX4 Autopilot?

PX4 is an open source flight control software for drones and other unmanned vehicles. The project provides a flexible set of tools for drone developers to share technologies to create tailored solutions for drone applications. PX4 provides a standard to deliver drone hardware support and software stack, allowing an ecosystem to build and maintain hardware and software in a scalable way.

PX4 is part of Dronecode, a non-profit organization administered by Linux Foundation to foster the use of open source software on flying vehicles. Dronecode also hosts QGroundControl, MAVLink & the SDK. --

Why use PX4 Autopilot on UCANS32K146?

The UCAN board is not an Autopilot, so why consider using PX4 on it? There are a number of reasons for this:

• Building a PX4 distributed architecture. The same peripheral drivers running on an FMU can be reused here on the UCAN board, with only the CAN bus (UAVCAN) separating them. This means a common codebase is developed and used for something like a sensor or actuator.

• PX4 carefully maintains and updates their branch of NuttX, and regularly backports to mainstream NuttX. This means PX4/Nuttx is more stable and there are minimal "surprises" due to untested code making it's way into the OS.

PX4 support for UCANS32K146

The PX4 development team provides basic support for UCANS32K146. A board configuration is available from which . Because PX4 is build on top of NuttX, it supports most of the for UCANS32K146.

There are some additional features offered by PX4:

• PWM generation

• Most PX4 drivers and modules can be enabled

There is currently no driver support in PX4 or NuttX for the NXP EdgeLock SE050 secure element.

Documentation and getting help

Documentation for PX4 is available on their website:

PX4 Autopilot is originally a drone flight control stack, therefore most of the documentation is focused on using PX4 on flight management units. Not all features may be directly available on UCANS32K146, though you can potentially enable all modules in the source code.

Issues can be reported on the . There are various available where you can ask questions and discuss your ideas.

Model Based Design Toolbox

In addition to traditional software tools, we pleased to now also have support for the UCANS32K1SIC board in the MBDT. From the NXP MBDT website page: "The NXP MBDT includes an integrated Simulink®-embedded target supporting NXP MCUs for direct rapid prototyping and built-in support for software- and processor-in-the-loop (SIL and PIL) development workflows, systems and peripherals device interface blocks and drivers, a target-optimized Math and Motor Control library set (AMMCLib) for efficient execution on the target automotive MCUs and Real-Time Control Embedded Software Motor Control and Power Conversion Libraries (RTCESL) for other MCUs, and bit-accurate simulation results in the Simulink® simulation environment."

Example:

This article shows how to develop an application for the UCANS32K1SIC evaluation board in MATLAB and Simulink and NXP’s Model-Based Design Toolbox.

Other links:

Introduction

There is a variety of software that can run on the UCAN boards. This includes NXP bare metal code and examples. New is the ability to use NXP MBDT (Model Based Design toolbox) The Mobile Robotics team has also enabled community supported ROS and autopilot ports for several opensource projects listed below. Typically we use NuttX/PX4 - which is the curated version of NuttX with the PX4 Autopilot tools. While the UCAN board is NOT an autopilot, with this buid, it can be a peripheral to PX4 and even offer distrubuted computing capability. The CAN communication on the UCAN board will mirror the current capabilty and state of CAN on PX4

Model Based Design Toolbox

From the NXP website: "The NXP MBDT includes an integrated Simulink®-embedded target supporting NXP MCUs for direct rapid prototyping and built-in support for software- and processor-in-the-loop (SIL and PIL) development workflows, systems and peripherals device interface blocks and drivers, a target-optimized Math and Motor Control library set (AMMCLib) for efficient execution on the target automotive MCUs and Real-Time Control Embedded Software Motor Control and Power Conversion Libraries (RTCESL) for other MCUs, and bit-accurate simulation results in the Simulink® simulation environment."

Specific information on using the UCANS32K1SIC with MBDT is given here in this article:

UCANS32K146 is a build target for PX4 Autopilot. PX4 is an open source flight control software for drones and other unmanned vehicles. While UCANS32K146 is not a flight controller, it can leverage the PX4 infrastructure to provide communications and portability of peripheral drivers, leading to enablement of a distributed vehicle architecture. For example drivers for secure element SE050 would be identical on the FMU and CAN nodes. PX4 makes use of a managed and maintained version of NuttX RTOS.

In addition to PX4, UCANS32K146 is also a build target in Apache NuttX and can therefore be used without PX4 infrastructure if not needed.

UAVCAN is a lightweight protocol designed for reliable intravehicular communication in aerospace and robotic applications over CAN bus, ethernet, and other robust transports. The name UAVCAN stands for Uncomplicated Application-level Vehicular Communication And Networking. It is created to address the challenge of deterministic on-board data exchange between systems and components of next-generation intelligent vehicles: manned and unmanned aircraft, spacecraft, robots, and cars.

CAN driver compatible with SocketCAN API, takes benefit of POSIX socket API for painless and portable CAN application development.

This software interface supports debugging UAVCAN and CAN on PC reusing an UCANS32K board reprogrammed as a debugger.

UCANS32K146 overview

Powering the board

There are two options when powering the UCANS32K146. The first option is to connect 5V power to the power pins on the board. The second option is to power the board through one of the JST-GH CAN connectors. The middle two pins on the CAN connector are for CAN data, and the outer two are for power. The left-most pin is for 5V, and the right-most pin is for GND.

Flashing and debugging

For flashing firmware and interfacing with the serial console, a 7-pin JST-GH connector with SWD and UART interfaces is present on the board. It is located on the side of the board next to the CAN connectors.

Guides for flashing binaries to UCANS32K146 are available for and Apache NuttX.

The idea is to control a servo motor or ESC via the CAN board using the UAVCAN protocol. This is useful to decentralize the processing from the FMU to multiple CAN boards in case of having multiple PWM units.

Next, we will show how to connect a CAN board to the Ubuntu 22.04 PC and send PWM commands.

Hardware setup

• (1) UCANS32K1SIC board

• (3) USB-TTL-3V3: the GND black wire should be mounted at the top when the serial debug connector is on the left.

• (2) Adapter board

• (4) CAN to USB adapter board

• (5) debug cable: to be able to communicate with the board via nutshell cmdline.

• (6) CAN cable: mount the CAN cable at the top right connector.

• (7) A resistor board: mount this board below the CAN cable connector

• (8) Power supply: make sure to not exceed 5 Volts

• (9) Servo motor for testing

Software setup

Install drone_can_gui tool:

Usage

• Set up can interface

Open a terminal and type these two lines

• Verify can interface

Check whether can0 interface figures in network interfaces list:

Double check by dumping CAN bus traffic

• Verify pwm status

In a nutshell, check the status of PWM in your board

• Start drone gui tool

Press ok

You should see your ucans32 device in the list of nodes:

• Arm the vehicle

Arm the vehicle (using QGC or RC transmitter depending on your setup):

External links:

[1]

[2]

Changes as follows:

Introduction

This tutorial explains how to operate 3-LED APA102 RGB board via UCANS32K146 over SPI.

Items Needed

• An APA102 based RGB LED board

• UCANS32K146 or UCANS32K1SIC

• Jumper wires

APA102 LED Board

Connections

The input connector of 3-LED APA102 board has 4 wired connections: SDI, CKI, PWR, GND. To connect the LED board to the UCAN board, refer the configuration of 'stemma qt / qwiic jst sh cable'. The connections would be as follows:

Network

All the LEDs in the board are daisy chained together. Note: These boards can also be daisy chained from one board to the next. From the software point of view these are just considered one long string of LEDs daisy chained together.

Software Procedure

Note: You may refer the steps for building and flashing PX4 on this gitbook .

Software Setup

Change the value of 'NUM_LEDS' in '/platforms/nuttx/NuttX/apps/examples/apa102/apa102_main.c' to the number of LEDs in your APA102 board. For our case, it will be '3'.

Building PX4

After compilation is done, the new firmware is available under: build/nxp_ucans32k146_default/deploy/34.bin

Flashing PX4

Flash the firmware and bootloader, if the board already doesn't have one, using 'jlink.exe'.

Operating the LEDs

Connect your board and access to the terminal using MobaXterm, minicom,...

Type the following command:

Production Schematics UCANS32K146-01

Production Version 01 Schematics

Schematics for the production version UCANS32K146 are published on NXP.com at the link below under <Documents and Software><Design Resources><Design tools and Files>:

Prototype Schematics UCANS32K146

Prototype pre-release hardware schematics, board layout and bill-of-materials.

S32 Design Studio and S32K1 SDK

Application Note AN12842

Repositories

NuttX consists of two repositories. The main operating system and an additional set of applications. Both repositories need to be in the same parent folder, with the main operating system being in a folder named "nuttx" and the applications have to be in a folder named "apps".

• NuttX -

• Apps -

Let's start by creating a parent folder to store both repositories. The following command will create an "apache-nuttx" folder if it doesn't exist already and makes it the active working directory.

We can now clone the Git repository that contains the main operating system. We'll immediately name the folder "nuttx" because the build system might get lost if it has a different name.

Similarly, we'll clone the apps repository:

You should now have a "apache-nuttx" folder located at ~/src/ that contains two folders: "nuttx" and "apps". That's all you need.

Checkout a stable release

By default Git will checkout the latest commit in the master branch when you clone the repositories. This is the latest development version at that point in time. Keep in mind that if you want to keep up with any changes you should use git pull to pull in any new commits. Keep in mind to do this for both the "nuttx" and the "apps" repositories.

You can also checkout the latest stable release. Change your working directory to the first repository, and fetch the available tags.

Now that the tags are available locally, you can checkout a particular release. At the time of writing the latest stable release is NuttX 9.1.0. You can checkout this particular version with the following command:

Don't forget to do both steps for both repositories! A particular version of the NuttX OS always should be matched by the same version of the NuttX Apps.

Toolchain

The online NuttX documentation provides an overview of possible development environments, but the README file in the main NuttX repository is also a good starting point. In general you're good to go if you are using Linux with a standard GNU toolchain.

Within the NXP Mobile Robotics team we often use PX4 Autopilot as well. They have their own toolchain preferences (which are compatible with NuttX), so we often install their preferred toolchain. This is also easy to do because they provide some scripts that take care of most of the work.

Building NuttX

Building NuttX is very easy when you have all required tools installed. You just have to select a canned configuration, change the configuration to your liking and just run make. If you want to throw away the current configuration and select another configuration you first have to run make distclean. That's all.

Flashing NuttX

Download and install the . It is available for all major operating systems, but we will assume here that you are using a Linux-based OS. Open a terminal and navigate to the main nuttx directory, which contains nuttx.bin after a successful build. Then you can start the J-Link tools by entering:

Make sure that the debugger is plugged into both the UCANS32K146 board and your computer. If you are using a virtual machine, the debugger USB device should be made available inside the VM. Also do not forget to power the board. Now enter:

You are now asked to specify a device. It is quickest to manually enter the device:

The target interface needs to be specified, which is SWD:

Finally you have to specify the target interface speed. It is recommended to use 1000 kHz:

Now flash the binary with:

The binary will be programmed and this process will also be verified. It should then mention if everything went OK. You can quit the J-Link tools with:

You may need to power cycle the device afterwards. The debug console should now be available on LPUART1 (115200 baud) - which is also accessible on the debugger breakout board.

Install Kconfig frontends

NuttX uses a similar configuration system as the Linux kernel. There are Kconfig files that define the different options and you can generate a configuration file that can be used by the build system with a Kconfig frontend.

NuttX provide their own fork/back-up of the Kconfig-frontends, to make sure that they always have access to a compatible version. It is still hosted on their old BitBucket repository.

First, make sure you have gperf installed:

Then download the source code by cloning the NuttX Tools repository from BitBucket:

Change the working directory to the kconfig-frontends folder:

Configure the build to include (at least) the menuconfig and qconfig tools. The Kconfig frontends will be installed into the /usr folder.

Now build the tools according to the configuration that we just created:

And finally install the Kconfig-frontends that we just build from source:

Once you have a "default" configuration in place (we will get to that in a second), you can edit the configuration with make menuconfig or make qconfig. Both tools have their pros and cons, just give them a try and see which one you like the most!

Start with a canned configuration

Make sure you are inside the "nuttx" folder:

Then use the configure script to select the "nshdebug" configuration for the "rddrone-uavcan146" board:

Make sure to first run make distclean if you still have another active configuration.

Configuration

Menuconfig is the "default" tool to configure the NuttX build. Once you have a board configuration selected (see above) you can edit the configuration with:

You can also use qconfig, which shows the configuration as a nested list instead of different menus. This might make it a bit easier to navigate through the many options that are available:

Menuconfig and qconfig are easy to use tools, but NuttX is very configurable and you can easily got lost in the hundreds of menus and options that it provides. Take your time to explore the options that NuttX has to offer, but don't try to enable many options at once. Just select a few, build the code and give it a try on the hardware itself.

Prerequisites

You need a build environment that can build PX4 Autopilot. You can generally use the same environment as with Apache NuttX, but you will need to install some additional packages. To get started, you can use the HoverGames virtual machine, or install your own Linux (virtual) machine. When you have a basic Linux environment, you only need to install the PX4 toolchain to continue.

More information is also available in the PX4 Developer Guide.

If you have not yet cloned the PX4 source code as part of the toolchain installation, you should do so now:

Adding CAN utilities to PX4

If you want to add the can-utils apps to PX4 (candump and cansend applications), you will need to perform an extra step.

Here are the steps:

1. From the root of your PX4 directory, run make nxp_ucans32k146 menuconfig

2. Navigate to Application Configuration --->

3. Navigate to CAN Utilities --->

It should look like this:

Once you've finished this, exit the menuconfig and save, then continue to build PX4 below.

Building PX4 Autopilot for UCANS32K146

Change your working directory (cd command) to the PX4-Autopilot Git repository that you just cloned. Next we will build the bootloader and firmware for our UCAN board.

Bootloader

Downloading the Bootloader

If you don't want to build the bootloader, you can download it by clicking the file below.

Alternatively, run the following command to build the bootloader:

The binary file will be located at PX4-Autopilot/build/nxp_ucans32k146_canbootloader/nxp_ucans32k146.bin. Keep this file handy for flashing later.

PX4 Firmware

A prebuilt version of PX4 for UCANS32K146 is linked below. This is the latest build of PX4 master.

Alternatively, you can build the firmware by running the following command in the root of the PX4-Autopilot repository:

The .bin file for flashing the firmware will be stored in build/nxp_ucans32k146_default/deploy. The file you're looking for is 34.bin. You can leave the file there or copy it to another location for flashing the board in the next section.

Flashing PX4 Autopilot to the UCANS32K146 board

Download and install the . It is available for all major operating systems, but we will assume here that you are using a Linux-based OS. Open a terminal and navigate to the directory which holds the nxp_ucans32k146.bin file that we build in the previous step.

Now start the J-Link tools by entering:

Make sure that the debugger is plugged into both the UCANS32K146 board and your computer. If you are using a virtual machine, the debugger USB device should be made available inside the VM. Also do not forget to power the board. Now enter:

You are now asked to specify a device. It is quickest to manually enter the device:

The target interface needs to be specified, which is SWD:

Finally you have to specify the target interface speed. It is recommended to use 1000 kHz:

Now flash the bootloader with:

The binary will be programmed and this process will also be verified. It should then mention if everything went OK.

Next, flash the PX4 firmware binary with:

And you're good to go.

You can quit the J-Link tools with:

You may need to power cycle the device afterwards. The debug console should now be available on LPUART1 (115200 baud) - which is also accessible on the debugger breakout board.

More information

The PX4-build for UCANS32K146 is in an early state and not all features may be available. More information about PX4 Autopilot is available in their and . Their software development is managed on . There are also various available.