Wiren BoardDocumentation
Reference · English

WB-MIR v.3 known issues

revision 102436

ERRMODBUS003: Unexpected behaviour when invalid values are written to some registers

Affected devices

WB-MIR v3 devices with firmware earlier than 4.32.1.

Description

When values in the range [256 ... 65535] are written to some registers, the upper 8 bits are discarded and the firmware receives the value modulo 256. For example, writing 257 has the same effect as writing 1.

The device address register (128) is one affected register.

All registers work as expected within their documented ranges. The issue occurs when invalid values above 255 are written.

Remedy

Update firmware to 4.32.1.

Resolution

Fixed in firmware 4.32.1.


ERRMODBUS007: Lost events when two devices transmit simultaneously on one bus

Affected devices

WB-MIR v3 devices with firmware earlier than 4.35.1.

Description

When two devices on one bus have pending events simultaneously, one may transmit an incomplete event packet.

Cause and details

In Fast Modbus, the master requests events. All devices with pending events arbitrate; the winner replies, while the others wait for the next request.

A generated event waits for transmission. After the device places its frame on the bus, the event is marked sent. The master's next acknowledgement for that device removes the sent events from its queue. This is the normal acknowledgement mechanism.

The defect marked events as sent too early, on receipt of the event request, before arbitration finished. If the device won arbitration, operation was normal. If it lost, no packet was transmitted, but its events were already marked sent. A subsequent acknowledgement for that device also acknowledged these unsent events, removing them from the queue before they ever reached the master.

The web-interface value does not update and no MQTT message is published, although the device registers remain correct. The change notification is lost.

For example, if inputs on two relay modules on the same bus close simultaneously, one module may update correctly in the web interface while the other loses some events and still appears in its previous state despite physically switching.

Workaround

Temporarily disable event-based operation for affected registers by setting sporadic to false in the device template. The registers will then be polled at the configured interval.

Resolution

Fixed in firmware 4.35.1.


ERRMODBUS008: Unexpected behaviour with long request frames

Affected devices

WB-MIR v3 devices with firmware earlier than 4.35.2.

Description

Receiving a frame longer than 265 bytes, the maximum Fast Modbus frame length, can freeze and reboot the device; settings may also be lost in some cases.

Cause and details

The receive algorithm did not handle oversized invalid requests, causing a buffer overflow and corruption of adjacent memory. The device freezes and the watchdog restarts it. Very large frames, above approximately 500 bytes, can also corrupt settings, causing a restart with default communication parameters: 9600 8N2, address 1.

Workaround

  • Do not send requests exceeding the limits of Modbus RTU or Fast Modbus (265 bytes for Fast Modbus).
  • Do not connect the device to a bus carrying non-Modbus traffic or messages longer than 265 bytes.

Resolution

Fixed in firmware 4.35.2.


ERRMODBUS009: Unexpected behaviour when reading near address 0xFFFF in continuous-reading mode

Affected devices

WB-MIR v3 devices with firmware earlier than 4.35.2.

Description

With continuous-reading mode enabled, a read range reaching or crossing address 0xFFFF can freeze and reboot the device.

Cause and details

The continuous-reading algorithm did not handle overflow of the 16-bit register-address counter. Reading 0xFFFF wrapped the counter and caused an infinite loop, followed by a watchdog reset.

Workaround

With continuous-reading mode enabled, do not read a range including 0xFFFF. Wiren Board devices have no implemented register at that address.

Resolution

Fixed in firmware 4.35.2.


ERRMODBUS010: Incorrect request validation and handling of invalid requests

Affected devices

WB-MIR v3 devices with firmware earlier than 4.35.2.

Description

The device may accept or mishandle syntactically invalid requests, return an incorrect exception code, or impose an incorrect register-count limit.

Cause and details

The validation algorithm mishandles these cases:

1) Requests to read zero registers succeed with an empty-data reply containing only a header and CRC. Modbus requires exception 0x03 (ILLEGAL_DATA_VALUE).

2) A single limit of 125 registers is applied to all read/write functions; exceeding it returns 0x02 (ILLEGAL_DATA_ADDRESS). Modbus instead specifies limits of 2000 bits for bit reads, 125 registers for input/holding reads, 1968 coils for multiple-coil writes, and 123 holding registers for multiple-register writes. Exceeding the applicable limit should return 0x03 (ILLEGAL_DATA_VALUE).

3) Byte Count is not validated for multiple writes (0x0F and 0x10). A mismatch between Byte Count and register count should return 0x03 (ILLEGAL_DATA_VALUE).

4) Single-coil writes do not validate the value and use the most significant bit of the request value. Modbus permits only 0x0000 and 0xFF00; all other values should return 0x03 (ILLEGAL_DATA_VALUE).

5) Structurally invalid requests with a valid CRC, such as overlong requests, are processed normally. Such malformed requests should instead be ignored.

6) Structurally valid but oversized frames of 257–265 bytes are processed. Standard Modbus frames longer than 256 bytes are invalid and should be ignored.


Workaround

Send only structurally correct requests compliant with the Modbus specification.

Resolution

Fixed in firmware 4.35.2.


ERRMODBUS011: Incorrect handling of invalid Fast Modbus event-configuration requests

Affected devices

WB-MIR v3 devices with firmware earlier than 4.35.2.

Description

An event-configuration command (EVENT_CTRL, cmd=0x46, sub_cmd=0x18) with invalid length fields can configure event notifications incorrectly and produce a reply of unpredictable length.

Cause and details

The Fast Modbus event-configuration handler did not validate the size and internal data-block length fields. Invalid lengths can cause it to process data beyond the received frame, resulting in:

1) Incorrect event notification settings, including spontaneous changes to event priorities or masks.

2) An event-configuration reply of unpredictable length.

Workaround

Send only valid Fast Modbus commands compliant with its specification.

Resolution

Fixed in firmware 4.35.2.


ERRMODBUS012: Device stops transmitting Fast Modbus events

Affected devices

WB-MIR v3 devices with firmware earlier than 4.36.0.

Description

The device stops sending Fast Modbus events and continuously reports no events (sub_cmd=0x12) in response to event requests (cmd=0x46, sub_cmd=0x10). Web-interface controls freeze while device registers continue to change.

The more frequently an event-enabled value changes, the sooner the issue occurs. In testing with 1 ms debouncing, event transmission stopped after 23 minutes at 200 input pulses per second and after several hours at 100 pulses per second. It can also occur with infrequent changes, but is much less likely. The driver logs no error because the device validly reports that no events are pending.

For diagnosis, read the register directly without events, for example the input pulse counter:

modbus_client_rpc -mrtu -pnone -s2 /dev/ttyRS485-1 -b115200 -a1 -r32 -t0x03

If the register increases but the web-interface control stays unchanged, this issue is present.

Cause and details

The unsent-event counter is shared by an interrupt handler and the main loop without correct synchronisation. An interrupt during a read-modify-write operation in the main loop can lose a counter increment. The increment cannot be recovered because it only occurs when an event first enters the queue. The device then believes it has nothing to send despite queued events.

The condition persists until the device reboots. Another event may temporarily flush the accumulated queue and update the control once, but the mismatch immediately returns. An installation with no other changes therefore appears frozen.

The probability increases with event frequency and bus load because concurrent accesses become more likely.

Workaround

Rebooting the device restores events until the issue recurs. Rebooting the controller or restarting wb-mqtt-serial does not help: the state is held in the device, and reconfiguring events does not reset it.

Reduce the probability by increasing input debounce time or disabling events for frequently changing registers. Until firmware is updated, read values directly from the registers.

Resolution

Fixed in firmware 4.36.0.


ERRMIR09: Safe mode is always enabled

Affected devices

WB-MIR v3 with firmware 4.32.1.

Description

Safe mode is always enabled: an IR command is always played on communication loss, even when Do nothing is configured in register 956.

Remedy

Update firmware to 4.32.2.

Resolution

Fixed in firmware 4.32.2.