The assembled circuits get some basic tests (the fully assembled,cased units get thorough tests, but that's another story) so installing them is as smooth as possible. If things somehow don't go smoothly, it's really hard to tell the problem when one is uncertain in his ISP cable, the usage of his GenBoard/Firmware/Upload software and other involved stuff. This is one of several reasons why assembling these circuits at home from ground up is very inefficient. There are enough issues to take care before and during install even with an assembled unit.
Passed tests before shipping:
GenBoard/VerTwo went through mintests before shipping:
Mintest consists of:
- some visual inspection
- Power up (GNDs connected properly!!) with current limiting
- measure current consumption: 45..70mA are common values before the 16Mhz crystal is enabled (depending on board version, level of assembly - eg. knockchip, EGT amplifier, etc...), and it can be slightly >100mA after the ECM application is started.
- ISP upload of boot/main.hex
- ISP setting fuses and verifying fuses. Note that boards shipped before 2004.11.08. the "factory-setting" of fuses enabled overwriting the bootloader with an ISP cable, and maybe by passing bad parameters to prog.pl. This changed, so the fuses must be changed first, should it be neccessary to overwrite the bootloader.
- RS232 GenBoard/Firmware/BootLoader test of main.hex. This tests the crystal, the max232, the RS232 connector, and the integrity of main.hex in flash.
- Uploading a test vems.hex via GenBoard/Firmware/BootLoader
- uploading a config.mtt via TerminalProgram
The v3 versions go through additional tests (called commtest, which includes the mintest as well):
- PS2 keyboard test (say mcd and see if RS232 spits out config.txt that matches config.mtt loaded up in the previous step )
- LCD test (with busypoll configured!) This tests the LBUS infrastructure, which means anything around the I259, P259 can be catched easily (should anything not go smooth at preinstallation-tests). The S259 and 74HC243 control is tested (those are involved in LCD operation).
From v3.2:
- 5V supplies (there are 6 populated regulators - the 7th 3.3V regulator is not populated)
- pump- (appr. 3.96V)
- internal 2V for pump
- MCP3208: just by touching an open input (on the 2x2 header) and check as the EGT on LCD changes
- ign259 testing using a DVM on the gate-signal and use the menu-debug-hardware menu: mdh82 (for I259_0) .. mdhf2 (for I259_7). Actually, mdh82 switches on the gate of the 2nd IGBT from the EC36 in the rightmost line. mdh02 switches off the same signal. Note that the h[2] configuration line (otherwise used for ignition signal mapping) is NOT used here.
- injdriver testing mdh80 (for h[0][0]) .. mdhf0 (for h[0][7]) is useful to test FETdrivers. Note that the h[0] configuration line is used here (see GenBoard/Manual/Config/HwMap)
- other outputs, like P259_n, S259_n ... etc... according to GenBoard/Manual/DigitalOut. Actually, mdhf6 / mdh76 switches on / off the S259_7 (S259 is the nickname for the 74HC259 chip above the stepper driver) where S259_7 is the enable signal for the stepper driver. However the success (if you see the change from 0V to 5V on your DVM) of this depends on configuration (eg. with stepper enabled or a dummy-blank full-0xFF config the running application might overwrite your output signal state very soon - remember that stepper will try to move a bit even before trigger is applied, unlike ignition - so the result of your mdh.. command might not visible). Consider similar effects before declaring HW failure.
- pump1 offset test is done by checking pump1+ voltage against pump- voltage without pump (or anything related to WBO2) connected. If the voltage is 4.36V-3.96V, I change pump_pw_zero from 0x66 to 0x64, save with mcs and check again after reboot (or mde02). +-0.1V here means +-0.01mA pump current because of the onboard 10k pump-shunt resistor.
Since v3.3:
- triggerinputs 2, 3 or 4
- minimum input threshold also (for VR inputs)
- supply current
- analog inputs (TPS, CLT, MAT)
- mcp3208 analog inputs
- wheelspeed input(s)
Since v3.6:
- knock (if ordered with knock)
- SD card (if ordered with SD card); SPI is tested anyway during initial reflashing
- flyback (all channels)
- GenBoard/VerThree/Testing/InjectorOutputs
- ...
[[Manual: Basics.Install.Mechanic]]
What is in the AVR flash on the mintested boards besides the BootLoader?
If you really want to know (which is probably a waste of time, once you made your RS232, LCD and PS2 work with it you should upload your own firmware)
- read the date with the mdv menucommand
- checkout a firmware at the given date from CVS if you really need it. The global.h can be important, if you want to change config from etc/config.txt textfile (make mtt step needs it). If you are unsure you used the right global.h, just compare mcd output to config.txt you uploaded.
- read back vems.hex with the help of the bootloader or ISP if you really need it (why would you??)
- [http://www.vems.hu/files/genboardv3/MinTest/my_make. my_make usually used for mintesting.] Note: the wiki added a '.' to the end of the file.
Planned tests:
- a special firmware could test if there is a short between 2 adjacent AVR pins (most such errors would be catched by other tests, but some not).
See also:
GenBoard/VerThree/RescueKit to find what it contains