Introduction

Note: In this document, the terms Client, Server, Query, and Response refer to specific roles and message types and are capitalized accordingly.

TinyTAP is a lightweight, embedded tool that monitors Modbus RTU serial communications, streaming frame level raw data in real time for analysis via Wireshark.

Offering a smarter way to observe and filter serial traffic, it is ideal for the diagnostics, development and reverse engineering of Modbus RTU based systems.

A minimal command line interface tool, TinyTAP Client, receives the data stream from the TinyTAP Server, which can then be analysed with Wireshark.

There are already several approaches for capturing and analyzing Modbus RTU frames, but none of them met my expectations. Since Wireshark is the de facto standard for Ethernet analysis, my first idea was: why not analyze serial data with Wireshark as well?

Unfortunately, reality had other plans. Virtual COM ports, special drivers, and convoluted setups turned the process into a frustrating experience.

TinyTAP was born out of a desire to simplify that, with an embedded friendly approach that delivers raw, usable data directly. No driver headaches, no unnecessary complexity.

Yes, it involves a small embedded board and a CLI tool, but everything is designed to work seamlessly together. Hardware, firmware, and tooling come from a single source and are tested as a complete system. That’s what makes it simple.

The required hardware is affordable:

• FRDM-MCXN947 development board from NXP (~30 €)

• Micro SD Push-Push connector from Mouser (~2 €)

• Preferably the RS485 Isolator 2 Click from MIKROE (~50 €) for robust galvanic isolation,
  or if isolation is not required, the more affordable RS485 8 Click (~20 €)

TinyTAP offers a transparent and streamlined solution that integrates smoothly into existing Wireshark workflows, whether you’re debugging, reverse engineering or developing.

The name "Tiny" doesn’t mean limited or minimal; it stands for the exact functionality I needed.

TinyTAP continues this philosophy, offering a focused, embedded-friendly solution with only the features that matter - no bloat, just purpose.

Unlike conventional USB/RS485 adapters, TinyTAP simplifies galvanic isolation in high-voltage lab setups:

• With USB-based solutions, either the RS485 line or the USB cable must be routed through a galvanic isolator to exit the test chamber, often resulting in long, interference-prone stub lines.

• TinyTAP, on the other hand, uses Ethernet for data transmission: the RS485 connection can remain short and local, while the galvanically isolated Ethernet link can be safely routed outside the chamber.

• When paired with a galvanically isolated RS485 Click Board, such as the RS485 Isolator 2 Click the setup becomes even more robust, protecting against electrical noise and potential ground loop issues.

• The result is a compact, reliable, and EMI-resilient system, ideal for safety-critical testing environments.

Hardware

Important Note Before Starting: Please be aware that the Micro SD card connector is not pre-installed on the FRDM-MCXN947 evaluation board. For this project, it’s essential and must be soldered onto the board manually. If you’re unsure about the soldering process or need a helping hand, consider reaching out to someone with experience - a working Micro SD interface is critical to getting the project up and running smoothly.

After soldering the Micro SD card connector, it looks like this:

Right now, you can only get the "RS485 Isolator 2 Click" directly from MIKROE. That’s where I bought my adapter. You can configure the firmware for the adapter in "project.h". Because the "RS485 8 Click" adapter is easier to get, this is set as the default in "project.h." here. When you use the "RS485 Isolator 2 Click" adapter, it looks like this:

Bootloader

This bootloader is a very simple version that programs a file named "fw1.bin" or "fw2.bin" from the SD card into the CPU’s flash memory. For integrity, the firmware header and the CRC are checked first. With the help of xbin, the "fw1.bin" or "fw2.bin" file was prepared before and the header and CRC was added.

The file is not programmed every time the device is started, but only if the file on the SD card differs from the contents of the flash memory.

This shows why the micro SD card is so important. If you later perform an update via Ethernet, the SD card will also be used as temporary storage. The update will then be temporarily saved there.

But how do you get the bootloader onto the CPU? There are three options:

• With LinkFlash from the LinkServer for Microcontrollers package,

• or with J-Flash Lite from the J-Link Software and Documentation Pack, or

• with SEGGER Embedded Studio.

In the root directory of "bootloader" there is a release folder which contains the actual version of "frdmn947-boot-sd.bin". This file can now be used with the "LinkFlash" or "J-Flash Lite" depending which kind of debug probe is installed on your FRDM-MCXN947 board.

By default, a CMSIS-DAP debug probe is installed on the board. In this case, the LinkFlash tool is required, which looks like this:

Attention, the "Address" must be set to 0 here.

As an alternative to the CMSIS-DAP debug probe, a J-Link OB can also be installed. In this case, the "J-Flash Lite" tool is required to flash the bootloader:

Attention, the "Prog. addr." must be set to 0 here too.

Another possibility is to compile the bootloader yourself with SEGGER Embedded Studio and then flash the bootloader with it.

But no matter how the bootloader was installed, after a reset of the board the output should look like this if no SD card is present:

In addition to the error message, the red LED flashes. Afterward, the bootloader automatically performs a reset.

To enable firmware loading, prepare the SD card by formatting it with the FAT32 file system. Then creating a folder named "etc" in its root directory and copy a valid "fw1.bin" file into that folder. When the device starts, the bootloader will automatically detect and launch the firmware if the file is present.

But where do I get "fw1.bin" from? Good question, I’ll explain that in the next section "Firmware".

TinyTAP Server

The basic functionality of the "TinyTAP Server" is based on TinyONE, but currently without the security features. You could also run it with TLS, but that’s too much work for TinyTAP in the first step because of the certificates you need to set up.

Before we get to the actual firmware, we need to take a quick detour to "Tiny Network Explorer (TNE)". The firmware is configured to use DHCP to obtain an IP address when it starts up. But how do you find out which IP address has been assigned? You can check the DHCP server or use
Tiny Network Explorer (TNE). Just take a look at the corresponding page, where you will find a detailed explanation of everything it can do. My TNE window currently looks like this:

After clicking on the IP address, a browser should open and you will be taken to the TinyTAP website. If this is not the case, you will need to open the browser yourself and enter the corresponding IP address as the destination. The first page of TinyTAP now looks like this:

Compared to the TinyONE functionality, there is now also the "Modbus RTU" functionality available:

Currently, it shows that there is no "TinyTAP Client" connection available. I will explain what the TinyTAP connection is all about later in the section "TynyTAP Client". But first, here are some details about the TinyTAP Server firmware.

As already mentioned in the introduction, there are several ways to record and evaluate Modbus RTU. However, I found this too cumbersome, which is why I am now presenting this approach. I will now explain only the "TinyTAP" part (mbrtu_tap.c) of the firmware.

The firmware has its own task for receiving serial communication. This task detects the end of a Modbus RTU message and then forwards this message to connected TinyTAP Clients.

Currently, the end of a message is recognized when no new character has been received for 4 milliseconds. This does not really correspond to the specification and still needs to be changed. However, in my first use case with 9600 baud, this recognition was sufficient and worked.

However, Wireshark still had the problem that it could not clearly identify whether a message was a "Query" or a "Response". That is why an attempt is made to identify this information in the firmware as well. Basically, it can be said that all valid messages with a length of less than or equal to 8 are Query messages. However, there are exceptions, e.g., in the case of a "Write Single Register". In this case, the Query message has the same length as the Response message.

In order to recognize what is a Query and what is a Response in this case, every message with a length of 8 is temporarily stored in the firmware. If we now receive a message with a length of 8 and it is identical to the last stored message, the new message is marked as a Response (or not Query). If it is not identical, it is a Query and is stored again. This may not be 100 percent robust, as it is possible that a Query will not be answered by the server and the client then sends a new Query message. This would now be incorrectly evaluated as a Response, oops. I need to think again about whether that’s such a good idea. But that’s why the software isn’t version v1.00, but only v0.80.

Why am I trying to detect whether it is a Query or Response message in the firmware? Wireshark actually recognizes whether it is a Query or Response based on the source or destination address and the port. However, this information is not available if the Modbus RTU messages are simply forwarded to Wireshark. That is why the TinyTAP Client simulates the communication later on. More on this in the next chapter, "TinyTAP Client".

Wait, there is still the question of where to get the "fw1.bin" file. To do this, open the firmware project "firmware/prj/frdmn947-mbrtu-tap.emProject" with SEGGER Embedded Studio and compile it in "Flash Release" mode. The file "fw1.bin" can then be generated using "firmware/_create_fw.bat". This creates a new directory called "build" under "firmware" which contains the file "fw1.bin".

I already know your next questions: why are there still "fw2.bin" and "frdmn947_tinytap_v080.bin" in the "build" directory?

You asked, and here is the answer. It is possible to save two different firmware versions. Internally, these are saved as "fw1.bin" and "fw2.bin". You can select which buffer a new firmware version should be saved to during the update:

The file "frdmn947_tinytap_v080.bin" is then used for an update via the website. You can then select the buffer in which the new version should be saved. After that, you can activate the buffer and a reset will be performed. This gives you the option of reverting to an older version if you have not overwritten it. However, the website and the update must still be working for the new version. As an alternative in an emergency if nothing else works, you can also perform the update via the SD card as described for the bootloader.

TinyTAP Client

The TinyTAP Client is the connection between the TinyTAP Server and Wireshark. After starting the TinyTAP Client, it searches for a TinyTAP Server on the network and connects to it:

The Client has connected to the Server here, which is now also displayed on the website:

The default values for a connection are 9600,8,N,1. However, these can be changed when connecting from the TinyTAP Client to the TinyTAP Server. The corresponding parameters are available at start:

The Client receives Modbus RTU messages from the Server with additional information indicating whether it is a Query or Response message. The messages are then sent to 127.0.0.1 (localhost) accordingly. For a Query message, port 32502 is used as the source port and port 1502 as the destination port. For a Response message, port 1502 is used as the source and port 32502 as the destination.

With this trick, the Query and Response messages are now correctly decoded by Wireshark.

The Modbus RTU frames that the Client receives from the Server are also output in the terminal:

But what does it look like now in Wireshark?

Wireshark

Ensure that the TinyTAP Client is connected to the TinyTAP Server and, of course, that the correct communication parameters for the Modbus RTU connection have been selected. In Wireshark, the "Adapter for loopback traffic capture" must now be selected:

If port 1502 is not yet assigned to the Modbus RTU protocol in Wireshark, only the normal UDP packets will be displayed without any corresponding Modbus RTU interpretation:

Next, we will configure the port-to-protocol mapping. To do this, select "Edit / Preferences...":

In the next window, select "Protocols". The window should look like this

Scroll down to "Modbus RTU" and set the "Modbus RTU UDP port(s)" to 1502. Ensure that "Validate CRC" is also selected. And press "OK":

And this is where the magic begins, and Wireshark now decodes the Modbus RTU messages:

Frame 1 is here a Query request at address 9 which requests 10 registers. And frame 2 is the Response which will look like:

I have now demonstrated that the description from the introduction could be implemented, and that this is now hopefully a simpler system for displaying and analyzing Modbus RTU frames with Wireshark.

I would say that the task is now completed.

Windows, Linux, macOS

Can I also use this on Windows, Linux, or macOS? Yes, that should be possible, because Wireshark is available for all of these operating systems. And the TinyTAP Client can also be compiled and used on these operating systems.

When using MSYS2-MINGW64, the following packages must also be installed with pacman:

pacman -S mingw-w64-x86_64-gcc
pacman -S mingw-w64-x86_64-cmake
pacman -S mingw-w64-x86_64-gdb

And when using MSYS2-UCRT64, the following:

pacman -S mingw-w64-ucrt-x86_64-gcc
pacman -S mingw-w64-ucrt-x86_64-cmake
pacman -S mingw-w64-ucrt-x86_64-gdb

Unfortunately, Tiny Network Explorer (TNE) is currently only available for Windows. I don’t yet know how I can make such an application available for Linux and macOS.

SEGGER Embedded Studio is also available for all these operating systems, so you can also put together the Bootloader and firmware for the TinyTAP Server here. However, there is still a problem with the firmware, as it uses small tools that I only have for Windows. But I’m almost ready to make them work on Linux and macOS too.

Download

The repository can be found on GitHub at tinytap.