ISO-TP addressing formats

ISO-TP is a transport protocol defined in the ISO-Standard ISO15765-2. It defines a transport layer protocol on top of CAN or CAN FD to transfer payload larger than 8 resp. 64 bytes which is the maximum frame length of CAN resp. CAN FD frames.

Normal addressing

Normal addressing use the CAN identifier only to address a device. Both 11-bit CAN identifiers and 29-bit CAN identifiers may be used.
The definition which CAN identifiers shall be used is not in the scope of the ISO-TP standard, but defined by higher layers using ISO-TP.

Normal fixed addressing

Normal fixed addressing requires the use of 29-bit CAN identifier only. It basically follows the J1939 addressing scheme using the J1939 PGNs 0xDA00 and 0xDB00 and a J1939 priority of 6. The source address is encoded in the lower 8 bit of the CAN ID and the target address is encoded in the bits 8-15 of the CAN-ID.

Extended addressing

Extended addressing extends the normal addressing format by an additional byte. The first byte of the CAN frame is part of the address.
Illustration of UDS payload embedded into ISO-TP in CAN frames
The definition which CAN identifiers and data byte shall be used is not in the scope of the ISO-TP standard, but defined by higher layers using ISO-TP.

Mixed addressing

Mixed addressing is used for remote diagnotics and can be used with both 11-bit CAN IDs and 29-bit CAN-IDs. When using 29-bit CAN-IDs it basically follows the J1939 addressing scheme using the J1939 PGNs 0xCE00 and 0xCD00 and a J1939 priority of 6. The source address is encoded in the lower 8 bit of the CAN ID and the target address is encoded in the bits 8-15 of the CAN-ID.

Additionally, the 1st byte of the CAN frame is used as an address extension.

Known implementations

emotas’ ISO-TP stack supports Normal addressing, Normal fixed addressing and Extended Addressing.

Read LoRaWAN data from TTN server

TTN – The Things Network

https://www.thethingsnetwork.org/

Our LoRaWAN sensors use the service of The Things Network. So our LoRaWAN gateway sends the sensor data to the TTN server. The sensors are registered with an ‘application id’ and a ‘device id’.

https://console.thethingsnetwork.org/

Now I want to receive the data on my PC. The TTN server allows to use MQTT.

https://www.thethingsnetwork.org/docs/applications/mqtt/quick-start.html

Note: Currently only the up-topic is working and get the data in JSON format.

https://status.thethings.network/

 

mosquitto – https://mosquitto.org/

Please read the base information on

https://www.thethingsnetwork.org/docs/applications/mqtt/quick-start.html

We want to subscribe using TLS. The access schema seems to be a little bit different. In our case only with the option ‘-L’ it was possible to switch to TLS communication:

mosquitto_sub.exe -L mqtts://<AppID>:<AppKey>@<region>.thethings.network:8883/+/devices/+/up –cafile mqtt-ca.pem

We receive

{
  "app_id":"stm32_example_usi_expansion_board",
  "dev_id":"sensor-ro-20200522",
  "hardware_serial":"E24F43FFFE44C1EF",
  "port":99,"counter":605,
  "payload_raw":"AHMnSwFnARYCaFADAGQEAQAFAdc=",
  "payload_fields":{
    "barometric_pressure_0":1005.9,
    "digital_in_3":100,
    "digital_out_4":0,
    "digital_out_5":215,
    "relative_humidity_2":40,
    "temperature_1":27.8
  },
  "metadata":{
    "time":"2020-07-03T14:02:59.272943586Z",
    "frequency":868.1,
    "modulation":"LORA",
    "data_rate":"SF9BW125",
    "airtime":246784000,
    "coding_rate":"4/5",
    "gateways":[
      {
        "gtw_id":"eui-3133303735005600",
        "timestamp":920207212,
        "time":"",
        "channel":0,
        "rssi":-44,
        "snr":11.75,
        "rf_chain":0
      }
    ]
  }
}

 

Python

Our solution is based on the package paho-mqtt.

https://pypi.org/project/paho-mqtt/

At the first you have to install it to your python environment. Possible you have to update your paket manager at the first.

example Win10: (of course python should be installed already)

cd Python37-32
python -m pip install --upgrade pip
cd scripts
pip install paho-mqtt

Now start the python shell – IDLE (Python 3.7 32-bit)

Load/create the small script mqtt.py. It print the sensor value temperature.

import paho.mqtt.client as mqtt
import json

# The callback for when the client receives a CONNACK response from the server.
def on_connect(client, userdata, flags, rc):
    print('Connected with result code '+str(rc))
    client.subscribe('+/devices/+/up')

# The callback for when a PUBLISH message is received from the server.
def on_message(client, userdata, msg):
    ergebnis = json.loads(msg.payload)
    values = ergebnis['payload_fields']
    print(values['temperature_1'])

client = mqtt.Client()
client.on_connect = on_connect
client.on_message = on_message
client.tls_set()
client.username_pw_set('AppId',password='AppKey')

client.connect('eu.thethings.network', 8883, 60)

client.loop_forever()

Of course you have to configure your AppId and AppKey.

Output:

Connected with result code 0
27.9
27.9
27.9
27.9
27.8
27.9
27.8
27.8
27.8
27.8
27.8

 

printf() using ST-Link debug interface (SWD, ITM View)

Intention

ARM provides the possibility to use a printf() like a serial output, using the SWD interface (ITM port 0). This example describes the usage using a Nucleo-64 board, ST-Link v2.1 and the STM32CubeIDE.

Note: The Cortex-M0 doesn’t have the required hardware in the mcu. So it is not possible on it.

switch printf() to the debug interface

Often you find the describtion to overwrite _write(). That’s correct. In case of the STM32CubeIDE generated code it is also possible to overwrite the more low level __io_putchar().

/* USER CODE BEGIN 4 */
int __io_putchar(int ch) {
    ITM_SendChar(ch);
    return ch;
}
/* USER CODE END 4 */

Debug Settings

You have to enable the Serial Wire Viewer (SWV). The most relevant setting is the Core clock. You have to configure the correct clock frequency, that you initialize within your application.

STM32CubeIDE Debug Configuration
STM32CubeIDE Debug Configuration SWV

Prepare the Debug view

  • Open the SWV ITM Console
open SWV ITM Console
open SWV ITM Console

printf() uses the SWO connector and the trace port 0.

  • Add ITM port 0
ITM port 0
ITM port 0
  • Enable ITM port 0
ITM port 0
ITM port 0
  • Start trace to view the printf() output
Start Trace
Start Trace

That’s all.

output
printf output

Alternative ST-Link Utility

ST-Link_Utility config
ST-Link_Utility config

 

Using UART3 as virtual COM on Nucleo-64 / STM32L476

Intention

By default the UART2 is connected to the virtual COM of the ST-Link. The same UART is possible to connect to the Arduino connector.

So I want to connect the UART3 to the virtual COM connector and use the UART2 for the Arduino connector (CN9 Pin 1 and 2),

The description is for an Nucleo-64 STM32L476, but should be compatible to some more Nucleo-64 boards, too.

Hardware changes

Switch UART2 to the Arduino connector

  1. open solder bridge SB13 and SB14
  2. close solder bridge SB62 and SB63
Nucleo-64 Uart2 to Arduino
Nucleo-64 solder bridges

Nucleo-64 evaluation board

Switch UART3 to the VCOM of the ST-Link

  1.  connect ST-Link connector TX to PC5 (Uart3 RX, CN10 pin 6)
  2. connect ST-Link connector RX to PC4 (Uart3 TX, CN10 pin 34)
Nucleo-64 UART3 to ST-Link
Wires to connect the UART3 to the ST-Link

Software changes

  • initialize UART3  (e.g. 115200 Baud, 8N1) with PC4 and PC5
  • in case you want to use printf
int __io_putchar(int ch) {
    HAL_UART_Transmit(&huart3, (uint8_t *)&ch, 1, 0xFFFF);
    //ITM_SendChar(ch);
    return ch;
}
  • alternatively overwrite _write()