Skip to main content
Firmware Stable

Is it really faulty? Checks before returning a device

Applies to​

Any siliXcon device the user thinks is broken, before it is sent back. Many returned devices work in the lab: the cause was the configuration, the wiring, an old firmware, a peripheral or the supply. Go through these checks with the user, read-only, under the rules of the general method; what they find is also what siliXcon needs with a return.

Steps​

1. Does it answer?​

No answer at all: on a motor controller the power and connection playbook first - most controllers that "do not switch on" are powered in the wrong order or have a fuse that can be bypassed. A device that answers is not dead: continue.

2. Identity and firmware​

From list_devices:

  • Name or hwid empty (or shown as NULL): the device's identity data was lost, typically during programming. siliXcon restores it remotely; it needs no return.
  • Old firmware: the version in the swid against the application's changelog. Behaviour fixed in a newer release, or a feature the user misses that came later, is solved by an upgrade (firmware upgrade).
  • A firmware or application other than the user expects: the wrong application or variant for the job, not a fault (getting started playbook steps 6 and 7).

3. A diagnostic report taken right​

siliXcon asks for a diagnostic report first. It shows the values at the moment the user pulls them, so: power the device as in use (battery, not USB alone), reproduce the problem, click Pull values while it is present (for example with the throttle held), then generate the report. A report taken at rest or without pulling shows nothing.

4. Error, limit or disarm​

  • An error (/driver/error, /common/error, a BMS error state) stops the device and is logged (driver error).
  • A limit (/driver/limit, /driver/stat) is the device protecting itself or following its settings - temperature, current, voltage, speed. It is behaviour, not a fault, and it is not logged (motor driver playbook step 5).
  • A disarm reason (on a motor controller's application) says why the application does not drive the motor yet - the throttle not at zero, a brake, a mode. It is not an error.

Only an error that persists after the checks below points to hardware.

5. Motor controller: errors without the motor​

A phase or "CM" error at start-up, or a power-stage error: the user switches off, disconnects the motor phases and switches on again (CM error check). The error gone without the motor: the motor or its cables. Still there: the controller.

6. Motor sensor​

A motor sensor error (/driver/stat, motor driver playbook step 6): the user unplugs the sensor and measures the sensor supply (5 V) at the controller. Present: the sensor or its harness is the problem. Missing with nothing connected: the controller's sensor supply is damaged - usually by a short in the sensor harness, which must be fixed before a repaired or new unit is connected. The same supply often feeds the throttle.

7. Display or other peripheral​

A display error or "no connection" while the controller answers over USB and runs: try a known-good display, check the CAN or UART wiring between them, and check that the controller's application is on (power and connection playbook step 5). Return a part only after the swap shows which one fails.

8. History and supply​

log (general method step 5): overvoltage entries mean energy came back with nowhere to go - typically a BMS that disconnected during braking, or a supply that cannot absorb energy. Fix that before a repaired or new unit goes in, or it fails again (braking and overvoltage).

9. Physical state​

Ask for photos: power terminals and cable lugs (loose, over-tightened, discoloured), connectors (corrosion, water), the housing (mechanical damage). These are not visible over USB.

Report​

  1. Device: name, serial number, hwid, swid.
  2. Each check and its result, values quoted.
  3. Verdict: configuration / wiring / firmware / peripheral / supply, with the fix - or hardware, with the step that shows it.

Escalate​

The checks point to hardware, or they do not explain the problem: the user sends siliXcon the diagnostic report (taken as in step 3) with the findings above, and siliXcon support decides on the return.