Skip to content

Target protocols

Several types of wireline links are possible between TapNLink and the target microcontroller. IoTize Studio offers 4 target protocols:

  • SWD
  • S3P
  • Modbus
  • Standard Serial

The first three are managed in very similar ways. Standard Serial is different, it depends on which Modbus physical level is being used, it is placed here because it is often chosen by TapNPass users.

Electrical connection and characteristics

Please look at the TapNLink user's manual for more information about the hardware aspects (connectors, cable and electrical characteristics).

Protocol levels

Protocol management is structured in several levels. Three levels of abstraction can be considered:

  1. Access to communication functions ('physical' level).
  2. Access to addressable spaces ('protocol' level).
  3. Access to variables ('application' level).

These levels can be characterized by API functions:

Level Type of access Reading Writing
1: Physical Communications char getchar () ; putchar(val) ;
2: Protocol Addressable spaces int read (addr) ; write(addr, val) ;
3: Application Variable Sets Int readvar(" xvar ") ; witevar(" xvar ", val) ;

In practice, the application level calls the protocol level which calls the physical level, so for example:

  • When calling up the function readVar (COUNT) level 3,
    • the TAP searches the list of registered variables for COUNTs addr_count address.
    • It then calls the read (addr_count) function that corresponds to the lower level.
  • If we assume the protocol used is Modbus,
    • the TAP translates the function read (addr_count) level 2 by sending a frame that asks the target for the value of the register whose index is addr_count.
    • the TAP uses the putchar function of the UART to send the frame { 1, 3, ...} and uses the getchar function to receive a frame containing the desired value.

Cross-reference of levels and IoTize Studio protocols:

Target Protocols

Note that three entry points have been added (see IoTize Studio config for details):

  • Serial
  • SWD-Direct
  • Modbus Direct

They differ from the general entry points (S3P / SWD / Modbus) because they allow you to manage the protocol levels directly using addresses (not variables), manage the physical level for Serial, and provide debug access for a target firmware update using SWD-direct.

Access protocols for variables

IoTize Studio offers three protocols to access variables:

  • SWD 
  • S3P
  • Modbus

The table below compares their main characteristics:

SWD S3P Modbus
Target core Cortex-M only Any Any
HW resources Debug port 2 GPIOs + one IRQ (could be debug port) UART (incl. 2 GPIOs and IRQ)
Implementation time A few minutes A few hours A few hours
Intrusivity (CPU resources) None Typ. 100 us per access Typ. 100 us per access
Intrusivity (ROM resources) None Typ. 2 KB Typ. 3 KB
Security Debug port could be an issue Good and scalable Good and scalable
Distance (TapNLink to target) Max 1m Max 1m Max 1m
Special features Make easy FW update and remote debugging - -
Variables access Absolute Indexed or absolute Indexed

The interest of accessing variables

TapNLinks direct management of variables has several advantages:

  • The developer simply retrieves the variables from his firmware.
    • for SWD, S3P and Modbus, IoTize Studio directly reads ELF files (application firmware) and retrieves both variable names and types.
    • for S3P and Modbus, IoTize Studio automatically generates the files necessary to take into account the protocols in the firmware of the embedded application.
  • Bundle management allows to group and organize the variables according to their use.
  • Access control applied to each bundle allows easy distribution of access types: read and/or write.
  • API functions allow these variables to be immediately retrieved from GUIs, regardless of their type (or size).
  • Special functions such as datalog and alarm detection are available.

All these points are managed at TapNLink level in order to facilitate and secure the construction of the global application.

Absolute vs Indexed access

S3P and Modbus allow indexed access. This means that instead of addressing a variable at address 0x2001ABC8, TapNLink looks for the nth variable in an array of predefined variables.

This index is unaffected by firmware changes that could lead to a new mapping of variables, and configuration changes, because IoTize Studio maintains the indexes as long as the variables are not deleted from the list.

Indexed mode therefore has the advantages of:

  • stability and reliability.
  • security, because only the variables in the table are accessible, regardless of the profile and rights of the connected user.

SWD protocol

The SWD protocol is the debug protocol most often used with microcontrollers with a Cortex-M core.

The main advantages are:

  • Access through this port is non-intrusive: you can read or write a variable without the target application noticing.
  • This port is often physically available (and not used) because it is only useful for initial programming.
  • No software or hardware modifications are required normally (except to make the debug port available when it is not).
  • SWD allows you to easily perform software updates remotely. It is therefore perfect for creating a PoC by integrating a TapNLink in a few minutes on an existing system.

The main disadvantages are:

  • Leaving the debug available on a final application would also allow a competitor to review the binary code. Depending on the application, this can either be considered as inconsequential or as a potential security breach.
  • Synchronization between the TapNLink configuration and the target firmware is required because indexed mode is not possible in SWD.

S3P protocol

The S3P protocol is an alternative to SWD and improves certain features:

  • Like SWD, it requires two GPIOs. Very often, when the debug port is disabled, the two SWD GPIOs remain unused (this is true on all STM32s, but not on all Cortex-Ms).
  • S3P allows an indexed mode.
  • Security procedures are easily implemented in S3P.

In general, it is recommended to start with SWD, then move to S3P for an industrial version. For implementation, an application note and examples allow you to easily add the S3P agent within your application. This is a summary:

  • Add files to your project (including a file generated by IoTize Studio)
  • Validate the interruption associated with the S3P-CLK signal.

It should also be noted that two "sub-modes" are available for IoTize Studio:

  • Indexed mode: the preferred mode.
  • SWD-emulation mode: variables are addressed by their absolute addresses. It is therefore very close to SWD and has the same potential security vulnerabilities. It is provided as it offers an intermediate step in a migration between pure SWD and indexed S3P.

Modbus protocol

Modbus is considered as the industry standard and is generally integrated into serial interfaces used for equipment control and configuration. The physical support is then an RS-485 or RS-232 link (as with TapNPass). When TapNLink is connected to a target microcontroller the link is also serial, but compatible with the voltage levels of the GPIOs (between 2.5V and 3.3V).
IoTize Studio has source files and an application note that allow for quick implementation.

Additional resources are required:

  • An available UART,
  • Reception must be managed by interruption. The sources provided are based on the standard implementation specified by modbus.org. They must be complemented by a hardware-specific configuration to provide low-level communication and timer functions.

Communicate "without variables".

It is possible to bypass the management of variables by:

  • Direct access to the address map. This mode is of little interest except for debugging in SWD, or allowing global Modbus access (independent of the target) with a product like TapNPass.
  • Direct access to the physical communication port. In principle, only UART is available so TapNLink becomes a simple secure communication relay. The protocol content is therefore unknown to the TapNLink because it is managed at the target firmware level.

Configuration from IoTize Studio

Target protocol can be selected in the "IOTZ Explorer" panel: IoTized Application | Target | Link TargetTap | Target Protocol.

You can select SWD, S3P, Modbus or Serial (see the central row in the cross-reference diagram).

Extra rights can be added by adding the protocol directly to a bundle (from features in the "Resource view" panel):

  • SWD Direct: allows a debugger to establish a debugging or programming session for the target firmware (if the users profile is associated with the bundle).
  • Modbus Direct: the authorized user can execute API functions that give access to any Modbus register (regardless of variables access rights).
  • Serial: gives associated profiles rights to use this generic serial link.