For those of you that have ordered and use my OBDII module, a software update is available for the STN1110 chip that does all the OBDII protocol handling. The update has some bugfixes and feature additions. See the changelog below for details. All modules I’ll be shipping from this date on will come w/ the latest STN1110 firmware.
If you’d like to update your module, you need to have access to a PC with a Bluetooth adapter/dongle installed. A laptop would be preferable as you’ll need to power the STN1110 to update it (aka have it plugged into your vehicle). Click “continue reading” for the update procedure!
Do the following to update your module:
1.) Install the module into your vehicle and make sure the ignition is off
2.) Wait until the flashing LED is flashing slowly, roughly turning on once a second (the LED will go from fast flash to slow flash roughly 30 seconds after plugging the module into your vehicle)
3.) Pair the module to your laptop/PC and type in the pairing code (1234 unless you changed it to something else)
4.) Make your Bluetooth software create a serial port (COM port) for the module. This process depends on your Bluetooth software running on something other than Windows 7. Windows 7 should automatically create a COM port for the OBDII module.
5.) Determine the COM port number that was created (if the software/Windows didn’t tell you) by doing: XP/2000/98: Control Panel->Device Manager->Click plus sign next to “Ports”. Win7: Control Panel->Hardware Tab->Device Manager Button->Click plus sign next to “Ports”. Your newly created port should say something like “Bluetooth Communications Port COMx” where “x” is the COM port number that you’ll need for the updater.
6.) Download the STN1110 v3.2.0 installer here: http://www.scantool.net/downloads/154/stn1110-3.2.0.zip
7.) Extract the files from the installer zip
8.) Run StnFirmwareUpdater.exe from the folder you extracted all the files to
9.) Select the COM Port number for the OBDII module you found in step 5 and then click the “Upload Firmware” button. Do not remove the module from the vehicle, turn the ignition on, or unpair the module from the PC. Ensure the PC is located close to the module to ensure a stable connection.
10.) The update should be able to connect to the STN1110 onboard the OBDII module and start the update.
11.) Once the update is complete, remove the module from the vehicle, reinsert it, and start using the module w/ the latest firmware.
12.) As with all software updates, there is a possibility of bricking the module. However, the updater and the bootloader in the STN1110 make the possibility of this happening extremely slim. If you feel this is too risky to do yourself, I’d be happy to update your module for free, you’d just need to cover the shipping costs. Or, you can safely stay at the current software version.
13.) I cannot assume any responsibility for any harm the software update could do to your module. Again, while this risk is extremely small, this is a “perform at your own risk” procedure.
v3.2.0 – 2012/09/19
——————-
– NEW: STIX (print extended FW version info)
– NEW: STSDI (set STDI HW ID string)
– NEW: STDICPO (report POR count)
– NEW: STDITPO (report time since POR)
– NEW: STDICES (report engine start count)
– NEW: STDBGM (set debug message level)
– NEW: Implemented engine crank/start detection
– NEW: Added engine crank counter output to STDIX command
– NEW: Implemented cumulative run time timer (returned via STDIX)
– NEW: Added UART RX OVERFLOW error to report UART Rx buffer overflow
– NEW: Added reset and sleep/wakeup trigger messages in debug message level 1 or above
– CHG: Improved voltage measurement precision to 3 decimal places for better accuracy at lower ANALOG_IN voltages
– CHG: Added optional voltage offset parameter to STVCAL command
– CHG: STVCAL command now accepts voltage down to 3 decimal point (1 millivolt) precision
– CHG: Added optional precision parameter to STVR command
– CHG: Maximum value for all voltage measurement-related commands is now 65.534V
– CHG: STVR command will now print –.– when the calibrated voltage exceeds 65.534V
– CHG: Improved voltage calibration (STVCAL/ATCV commands) accuracy by sampling and averaging readings over about 500 ms
– CHG: Renamed STCAFCP/STCCFCP commands to STCFCPA/STCFCPC (old ones still available, but deprecated)
– CHG: STCSWM command now takes mode values from 0 to 8, which independently encode the high speed tool load output
– CHG: Zero length frames that generated “ – CHG: Improved CR+LF handling (ignore only the first LF after CR)
– CHG: Any fatal errors will now be printed again after a reset, to make sure they are not missed
– CHG: Improved accuracy of all timeouts from -1/+0 ms to -0/+0.5 ms precision
– CHG: Removed the possibility of device lockup, while handling a fatal error
– CHG: STSLUIT command will not accept a setting below 5 sec to prevent bricking
– CHG: Updated STDIX command output to include the new device status info
– CHG: Command cancellation via UART character is now much more responsive
– CHG: Device will no longer get stuck receiving OBD messages indefinitely during protocol detection or while handling keep-alives, if connected in parallel with another tester or if message filters are improperly configured
– BUG: UART inactivity sleep timer was not being reset if only CRs were being received
– BUG: UART Rx could lock up or start receiving corrupted data
– BUG: UART Tx could lock up or transmit corrupted data due to silicon erratum and race conditions
– BUG: Rarely, under very unusual conditions, UART inactivity sleep or other timeouts could get triggered prematurely
– BUG: After resetting voltage sense calibration to defaults (ATCV 0000, STVCAL), voltage-based sleep/wakeup triggers would fail to recalibrate until the next device reset
– BUG: ATCV 0000 and STVCAL commands ignored factory calibration saved via STSAVCAL until the next device reset
– BUG: STDIX command printed init month off by one
– BUG: There was a small chance of device lockup after finishing CAN message reception
– BUG: Waiting for CAN responses was not cancellable via UART character
– BUG: STSLUIT command was erroneously accepting 0 as a parameter
– BUG: Some commands that require one parameter would erroneously accept no parameters
– BUG: Protocol was not being saved after being detected via a monitoring command
– BUG: ISO 9141 protocol is now properly detected while monitoring (instead of being detected as KWP)
– BUG: There was a small chance that EEPROM would get corrupted if a device reset interrupted a specific write cycle
