Common mistakes

This chapter covers what goes wrong on any can-mdv, whatever firmware it carries. Anything specific to one firmware is in that firmware's own FAQ.

Read the LED first

The box has one LED and it is worth ten minutes of bus tracing.

The LED	The box is	What to do
blinking once a second (half a second on, half a second off)	running normally	the fault is elsewhere — bus, settings, sensor or switch
off, with the box powered	in standby — see below	normal if the battery switch is open; otherwise check the position feedback
blinking every two seconds	running the hardware-test firmware	that is a production bench tool, not a customer firmware — check ProductId against the catalogue in can-mdv — Overview
off, with no supply at all	not powered	check the supply and the connector

The box went quiet after the battery switch was opened

This is by design. With the power injection enabled, a can-mdv holds the bus alive after the battery switch opens — for PowerInjectionOffDelay, whose value and purpose are in the firmware's own manual — then shuts down its CAN and LIN buses, turns the LED off and waits. It disappears from the boat's screens because it stopped talking, not because it failed.

It wakes on its own as soon as the position feedback says the switch is closed again. If it never wakes, the feedback contact is the first thing to look at — see below.

The box does not appear on the bus at all

Likely cause	How to tell	Fix
It is in standby	LED off, battery switch open	close the switch, or check the position feedback wiring
The MUXEN bus is not terminated correctly	60 Ω across a powered-down bus; anything near 120 Ω or 40 Ω is wrong	one 120 Ω at each physical end, nowhere else
No power, or CAN not wired	LED off, and off it stays	check supply and the CAN connector

The battery is on the bus, but the battery switch device is not

That is a factory-fresh box that has never been told who it is.

The two devices a can-mdv registers do not start out the same way:

Device	Factory state
battery (function 5)	instance 0 — publishes from the first power-up
remote battery switch (function 25)	instance 255, meaning "not addressed" — answers a UID scan but publishes nothing and accepts no commands

Find it and give it a number:

muxen-uds -i can0 uid --scan
muxen-uds -i can0 -d <address> writeconfig --name InstanceNum --value <n> --reboot

A box with no instance number is not broken and does not need reprogramming. It is waiting to be told who it is.

Two boxes fight over the same identity

Two devices with the same function and the same instance number on one bus produce values that jump between two sources, alarms that clear themselves, commands that reach the wrong box.

On a can-mdv this bites before anyone has configured anything: the battery device of every box defaults to instance 0, so a second can-mdv powered up next to a first one collides with it immediately. Fit and number them one at a time.

muxen-uds -i can0 scan

Each function + instance pair must appear once.

The switch will not move, or keeps being driven

The box decides what to do from the position feedback contact, not from what it last commanded. Get that contact wrong and everything downstream of it is wrong.

Symptom	Cause	Fix
the screen says the switch is open when it is closed	the feedback contact is not wired, or is wired to +12 V instead of ground — an unconnected input reads "open"	wire the contact so that it closes to ground when the switch is closed; no external pull-up is needed
the box goes quiet a while after every power-up, without the switch ever being opened	same cause: reading the switch as permanently open, it does what it does when the switch really is open and goes to standby	fix the feedback wiring
a command to move the switch gives up on its own	the box never sees the switch reach the position asked for, so it stops driving the coil when RemoteSwitchTimeout expires	check the feedback contact and the coil wiring
the switch opens when told to close, and the reverse	the two drive outputs are crossed	swap them, or set ReverseSwitchDrive to 1
nothing happens at all	the switch device has no instance number, so no command reaches it	give it one — see above

Nothing arrives from the battery sensor

Likely cause	Fix
The box is in standby	the LIN bus is deliberately dead there — close the battery switch
The sensor type is set wrong	BatteryIbsType selects which sensor the box talks to — see the battery-switch manual
The sensor is not powered, or not on the LIN pair	check the wiring; the box is the LIN master and the sensor answers only when it is polled

A setting I changed has no effect

Some settings are picked up as soon as they are written; the ones that shape the box's identity on the bus — the instance number, and the CAN filters built from it — are only read when the firmware starts.

Do not try to remember which is which. Always write with --reboot:

muxen-uds -i can0 -d <address> writeconfig --name <name> --value <value> --reboot

If you changed several settings without it, one restart at the end applies them all.

After a factory reset, the box has disappeared again

The factory-reset routine restores every parameter to its default. All the calibration, all the pairing, every setting is gone. The instance number can be kept or reset depending on how the routine is called — and if it was reset, the switch device goes back to 255 and stops publishing.

There is no undo. Read the configuration out and keep it before resetting anything:

muxen-uds -i can0 -d <address> readconfig

The firmware update failed

Nothing is damaged. The box is still running the firmware it had before — that is by design, see Loading and updating a firmware. The usual causes, in order: an image without -V2 in its name, which is for the earlier board and is refused by the signature check; a bus interrupted during the transfer; or the wrong product ID. Check what the box currently is, pick the matching image, retry.