GenBoard/Firmware/BootLoaderLoopback (2019-01-23 12:40:23)

Loopbacking the controller's RS232 (serial port)

In special, rare cases, eg. when firmware upload is interrupted or unable to communicate with firmware for some other reason,

one usually sees VemsTune Boot Mode Detected => Stay

good ?
  • Is the (driver+USB/) serial port reliable in both directions ? Eg. not dropping leading bytes after some silence ? The firmware upload also involves error detection and resend, but ECU => PC(VT) runtime data tolerates high error rates (very high error rates in the PC(VT) => ECU direction might go unnoticed during daily use, that results PC(VT) => ECU fw upload error.

Otherwise (to get to the "Boot Mode Detected"), use RS232 loopback to force ECU stay in bootloader mode after bootup:

If executing the above procedure very precisely at least twice, and still not getting "Boot Mode Detected", the boot loader might be damaged. That is extremely rare (but not impossible), and if happens, usually experienced soon after some external circumstance (eg. welding, or disconnecting ECU while powered up; injectors or other inductive solenoid loads without flyback path, etc...)


Loopbacking the PC RS232 (serial port) - to test the PC RS232 port


Prevent unintentional loopback (staying in "boot mode" if RS232 is not connected to BT-RS232 or PC at powerup)

Capacitive coupling can cause unintentional loopback detected (very likely with long RS232 cable,less likely with short cable or no cable, but not impossible), staying in bootloader with stayreason 0x37 (instead of starting firmware).

To prevent unintentional loopback: when Vemstune or BT-RS232 is not connected,

Summary