Wiren BoardDocumentation
Documentation / Reference
Reference · English

WB-MR6C v.3 known issues

revision 83447

ERRMODBUS001: Device replies to address 0xFD

Affected devices

WB-MR* with firmware earlier than 1.21.1.

Description

Fast Modbus devices can interfere with third-party devices on the same bus if those devices use special commands beginning with 0xFD.

Cause and details

Fast Modbus reserves 0xFD for special broadcast commands. If a third-party request starts with 0xFD but uses a command outside Fast Modbus, affected Wiren Board devices reply with MODBUS_ERR_ILLEGAL_FUNCTION, disrupting the other exchange. The bus driver incorrectly treats the packet as ordinary Modbus traffic.

Workaround

Avoid sharing a bus between affected Wiren Board and third-party devices.

Resolution

Fixed in firmware 1.21.1.


ERRMODBUS002: Incorrect response to discovery command 0x46

Affected devices

WB-MR* with firmware earlier than 1.20.4.

Description

Fast Modbus originally used function 0x60, later changed to 0x46 because 0x60 was in a reserved range. Backward compatibility retained both request codes, but the device always replied with 0x60. The fix replies with the same function used in the request: 0x46 or 0x60.

Remedy

Update to firmware 1.20.4.

Resolution

Fixed in firmware 1.20.4.


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

Affected devices

WB-MR* with firmware earlier than 1.21.6.

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 to firmware 1.21.6.

Resolution

Fixed in firmware 1.21.6.


ERRMODBUS004: Incorrect bit-field replies

Affected devices

WB-MR* with firmware earlier than 1.20.4.

Description

Replies containing bit fields, including coil/discrete reads and event management, could contain incorrect high bits.

Remedy

Update to firmware 1.20.4.

Resolution

Fixed in firmware 1.20.4.


ERRMODBUS006: Responses to requests with incorrect parity

Affected devices

WB-MR* with firmware earlier than 1.21.4.

Description

The device replied to requests with incorrect parity instead of ignoring them.

Remedy

Update to firmware 1.21.4.

Resolution

Fixed in firmware 1.21.4.


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

Affected devices

WB-MR* with firmware earlier than 1.26.4.

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 1.26.4.


ERRMODBUS008: Unexpected behaviour with long request frames

Affected devices

WB-MR* with firmware earlier than 1.26.5.

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 1.26.5.


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

Affected devices

WB-MR* with firmware earlier than 1.26.5.

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 1.26.5.


ERRMODBUS010: Incorrect request validation and handling of invalid requests

Affected devices

WB-MR* with firmware earlier than 1.26.5.

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 1.26.5.


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

Affected devices

WB-MR* with firmware earlier than 1.26.5.

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 1.26.5.


ERRMODBUS012: Device stops transmitting Fast Modbus events

Affected devices

WB-MR* with firmware earlier than 1.27.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 1.27.0.


ERRMR01: Digital input registers contain 0 after startup instead of the actual state

Affected devices

WB-MR (except WB-MRPS6) and WB-MWAC with firmware 1.9.x or 1.10.x

Description

At startup, inputs are not read and the digital input registers contain 0 even for an active input. They become correct after the first input transition.

Resolution

Fixed in 1.11.1.

With the fix, startup input states are written to the registers. Outputs do not react: they stay off or restore their saved state if register 6 enables restoration. The mapping matrix is not processed at startup, except in input mode 5 (leak sensors with a 20-minute repeat). Other actions occur on subsequent input changes.

ERRMR02: Safety Mode switches relays off regardless of Modbus communication

Affected devices

All WB-MR with firmware 1.15.0 or 1.15.1

Description

Writing a non-zero value to register 8 starts a timer that switches all relays off when it expires. Incoming Modbus packets do not restart the timer.

Resolution

Fixed in 1.15.2.

The timer now restarts after each received Modbus packet.

ERRMR03: Device freezes after approximately six weeks of continuous operation

Affected devices

All WB-MR with firmware 1.15.0, 1.15.1 or 1.15.2

Description

After approximately six weeks, the device stops executing commands and updating register values but continues replying over Modbus.

Resolution

Fixed in 1.15.3

ERRMR04: Incorrect MCU temperature and supply voltage readings

Affected devices

GD32-based WB-MR hardware with firmware 1.16.0

Resolution

Fixed in 1.16.1

ERRMR05: Incorrect supply-voltage monitoring

Affected devices

All WB-MR with firmware 1.16.0

Description

The ADC samples supply voltage every 100 ms. If a relay state changes immediately before power loss, the capacitors may discharge before the next sample detects the failure, so the new state is not saved.

Resolution

Supply voltage is now measured continuously.

Fixed in 1.16.1

ERRMR06: Frequency readings intermittently drop to zero

Affected devices

All WB-MR with firmware 1.15.0 through 1.16.2 inclusive

Description

In frequency measurement mode, readings occasionally drop to zero when the input is around 1 kHz.

Resolution

Fixed in 1.16.3

ERRMR07: Unstable Modbus polling

Affected devices

All WB-MR with firmware up to 1.16.2 inclusive

Description

The device intermittently stops responding to Modbus commands. This was observed at 115200 baud.

Resolution

Fixed in 1.16.3

ERRMR08: Energised relays switch off unexpectedly when module supply voltage falls

Affected devices

All WB-MR and WB-MWAC with firmware up to 1.17.1 inclusive

Description

Observed faults:

  1. When supply voltage falls, for example when switching from a 24 V main supply to 12 V backup, energised relays can unexpectedly switch off.
  2. When powered from the controller Vout with state restoration enabled (register 6 = 1), the module may reboot because of voltage sag.

Workaround

  1. Use main and backup supplies with the same voltage.
  2. Use a separate supply with adequate power capacity.

Resolution

Fixed in 1.17.2.

ERRMR09: Spikes in input frequency readings

Affected devices

All WB-MR and WB-MRWM2 with firmware up to 1.17.4 inclusive

Description

If a high input frequency falls below 1 Hz, readings may briefly jump back to a high value. The issue does not occur when pulses stop completely. Because WB-MRWM2 uses a voltage-to-frequency converter for power measurement, disconnecting a load can similarly cause transient power-reading spikes to the previous value.

Resolution

Fixed in 1.17.5.

ERRMR10: WB-MRWM2 does not count energy

Affected devices

Affects only WB-MRWM2 with firmware 1.19.0 through 1.20.1 inclusive; details: ERRMRWM0001

ERRMR11: Replies to all extended requests at address 0xFD

Affected devices

WB-MRWL3, WB-MR3LV/K(I), WB-MR6LV/K(I), WB-MR3LV/S, WB-MR6LV/S, WB-MRPS6, WB-MR6C v.2, WB-MR6C v.3, WB-MR6CU v.2 and WB-MRM2-mini with firmware earlier than 1.21.1.

Description

Address 0xFD carries Fast Modbus commands requiring a data reply and other broadcast requests. Affected devices replied to every packet at 0xFD, including packets without Fast Modbus commands.

Remedy

Update to firmware 1.21.1.

Resolution

Fixed in firmware 1.21.1.


ERRMR12: Device freezes with all indicators off

Description

Switching some contactors can freeze the module and extinguish all indicators. Cycling its power restores operation.

Affected devices

  • WB-MR3LV/S batch v4.3A
  • WB-MR3LV/I batches v4.0I–v4.2A
  • WB-MR6LV/S batches v4.3B–v4.5C
  • WB-MR6LV/I batches v4.0M–v4.2C
  • WB-MR6C v.2 batches v3.6M–v3.7C
  • WB-MR6C v.3 batches v4.3H–v4.4C, except v4.3H/1
  • WB-MR6CU v.2 batches v1.4A–v1.6A
  • WB-MRPS6/S batches v1.3B–v1.4A
  • WB-MRWL3 batches v1.4F–v1.5B

Cause and details

EEPROM latch-up pulls down the microcontroller supply voltage. Power-cycling the board clears it. The probability is low and depends on several factors.

Workaround

Affected devices exhibiting this fault are replaced under warranty.

Fix

Later batches no longer use or fit EEPROM.

ERRMR13: WB-MR6C v.3 fusible resistor fails in the high-voltage supply

Description

Very rarely, the fusible resistor fails when using the built-in 220 V supply.

Affected devices

All WB-MR6C v.3 before batch v4.4H.

Cause and details

Starting the supply near the mains sine-wave peak can, in rare cases, overload the fusible resistor as the internal capacitance charges. Variation in peak-power tolerance causes the resistor to open and disconnect the internal supply. Operation from an external 9–28 V supply is unaffected.

Workaround

The relay module is replaced under warranty.

Resolution

Fixed from batch v4.4H.

ERRMR14: WB-MR6C v.3 supply-voltage reading approximately 0.3 V too low

Description The reported supply voltage is approximately 0.3 V below the actual value.

Affected devices

WB-MR6C v.3 batch v4.4J/2.

List of serial numbers

Cause and details

On some units, an unused protective diode in the supply circuit was not bypassed during assembly.

Workaround

The relay module is replaced under warranty.

Resolution

Fixed within batch v4.4J/2.