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
- That is promising.
- Just skip the first few steps and continue with Stay step below, very easy !
- However, first make some measurements and review/verify basic things.
- Is DSUB9/pin5 really connected to ECU EC36/26 GND ? (EC18/17 is NOT always GND, especially if dual WBO2 or 2nd WBO2 heater FET was requested, so verify connectivity to EC36/26, or the the relevant motronic GND pin). Are GenBoard/Manual/GroundConnections
- 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:
- power down the controller (GenBoard ECU or round)
- remove fuelpump, injector and ignition fuses (or relay), and remove injector connectors.
- disconnect any device (usually PC) from the controller (GenBoard or round)
- connect the ECU RS232 (serial port) DSUB9 pin2 to pin3, with a wire, a conducting paperclip, or a dedicated loopback connector (=intentional ECU RS232 loopback at powerup)
- power up GenBoard
- remove the loopback
- connect PC to GenBoard RS232 (serial port)
- as a test, you can try to talk to GenBoard bootloader via TerminalProgram in 19200,8n1 say S (uppercase!),p,v and get AVREFI1, 20, 20 or alike.
- normally not needed, but do it if you have problem with the steps.
- Disconnect from TerminalProgram (or exit) to free up the serial port.
- run VemsTune to upload firmware from PC (the above steps not needed if you see "Boot Mode Detected"
- Boot Mode Detected => Stay ; Tools / Firmware / Firmware upload (VT might recommend the multifunction "upgrade wizard", but the old upload is best in this case: saving old vemscfg would likely not succeed anyway if you're doing this)
- OBSOLETE: or edit upload_firmware.bat to set COM port. (This runs megaloader. Found in MegaTune distribution)
- you might need to reboot (turn +12V supply OFF and ON)
- get (or prepare) the new configuration that matches your setup (firmware, wiring and other)
- IMPORTANT: if you are upgrading from a working different firmware, read GenBoard/UnderDevelopment/FirmwareChanges and update configuration to match the new firmware.
- upload configuration and tables
- either [vemstune] Firmware / Download Config / Upload Config
- or the old generate_config.bat (or the even older make mtt, see InitialConfig) create config.mtt with the global.h of the new firmware might have changed.
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
- important: disconnect any active device (usually a controller) from the PC
- connect the PC RS232 (serial output) DSUB9 pin2 to pin3, with a wire, a conducting paperclip, or a dedicated loopback connector
- start a TerminalProgram (such as bray terminal or hyperterm). Type TESTTEXT. If the terminal keeps echoing what you type (TESTTEXT in this case), than the selected serial port (often USB-RS232 adapter or bluetooth-RS232 adapter and the installed driver) works.
- note that this works in any baudrate setting (9600 / 19200 / other...)
- BEWARE THAT PLUGGING THE USB-RS232 adapter in another USB slot usually results in changed comm-port. Eg. changes from COM5 to COM4
Prevent unintentional loopback (staying in "boot mode" if RS232 is not connected to BT-RS232 or PC at powerup). Obligatory if DSUB9 extension cable is used
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: obligatory when long DSUB9 extension cable is used: (but Vemstune or BT-RS232 is not connected)
- connect a DSUB9/M connector with resistor < 5.6k between RS232DSUB9F/pin3 (ECU RX) and RS232DSUB9F/pin5 (GND).
- it might be tempting to insert a 2k4 throughole resistor and forget about it. It's OK as a test, but not a permanent solution: expected to lose contact.
Summary
- resistor between ECU DB9F/pin3 and pin5 prevent unintentional loopback 2k7 recommended, but 0 Ohm ("short") wire also works.
- This way capacitive coupling (or other noise) cannot cause unintentional loopback. Note that with some random ECUs (having ST232, from 2018-October mainboard batch) we measured 4.17V with 1k pullup to 5.05V indicating 4.17 / (5.05-4.17) = 4.73 k internal pulldown inside ECU (actually inside ST232 chip) which makes unintentional loopback extremely unlikely without real strong capacitive coupling, such as a long DSUB9 extension with no peer device connected. Confirmed by:
- We made tests with long (5 * 1.5m) DB9 cable extension on RS232: ECUs (having ST232) from current mainboard batch (2018-10 picknplace batch): started fw reliably even such abnormally long total 7.5m long cable (capacitive loopback) was attached, unterminated.
- resistor between pin3 and pin2 at powerup causes intentional loopback (see top of this page)
- usually not needed for fw upgrade, or done temporary with a lose resistor (before firmware upload if needed)