Greetings,
Although this is my first post I did a lot of research on this and other forums before buying a used 2006 King Quad. I purchased one that had a ERR code on the trip odometers. I decided to attempt a fix before buying a new display.
A little background on myself. I am an electrical engineer with a masters in engine design. I wrote engine management software for a marine engine company. So after seeing the issue and putting a lot of thought into it I thought maybe I could at least figure out how to prevent it.
I wanted to post my findings and what I did to fix it so others will at least understand to some level what is happening. I disassembled the display all the way down to the PCB and tried to identify some of the components. There is a little 8-pin chip on there. I couldn't read the markings on it but based on the circuitry around I did determined it to be an I2C EEPROM chip. So I de-soldered it and put it an EEPROM reader. I was correct. It is a simple 1k bit EEPROM chip. Regardless of the manufacturer the pin out and communication protocol is the same on almost all of these little things. So I purchased a Microchip 25AA01, programed it with the value I pulled from the factory one, and powered everything back up. Same problem. But it did work the same otherwise which told me I could move on to mapping out what all the parameters did.
I hooked up an oscilloscope and monitored what addresses the factory system was searching for on keyup and found it reads the following address ranges and through some experiments found out what some of them do. (note these are hex values)
0x00-0x0F:
The kmh/mph setting is stored at address 0. Screwing these up also affects the fuel gauge. Byte 0 gets written immediately after changing the setting by holding both buttons. The last two bytes 0x0E and 0x0F affect the top speed the display will show.
0x10-0x17:
These also affect the fuel gauge. I suspect there is a lookup table in here. They likely use this same software on other ATVs and calibrate it here. It is read but never written.
0x20-0x25:
This is the main odometer storage. Setting the values to 0,0,0,0,0,FF changed the reading to 0. It also gets written about every 1 mile or at keyoff. The number stored in here appears to be a counter so the main display processor is doing some math to convert this count to distance. This is likely the best solution since it must handle both miles and kilometers.
0x28-0x2D:
This is trip A and is more or less the same as the odometer.
0x30-0x35:
This is trip B and works the same.
0x38-0x3D:
This is the engine hours. Once again its a counter of some sort and is not stored as actual hours. The display converts it.
0x40-0x58:
The first byte, 40, contains some value used to calculate speed. Likely pulses per distance. I know setting it to 0 causes the speedometer to quit working and setting it to FF causes it to display way to fast. The rest of these bytes are unknown. I suspect trouble codes from the engine ECU might be stored here.
So, what is the odometer failure? Each of the four counters (Odometer, A,B,hours) uses a 6-byte number where the last one or two bytes are a CRC check. Or a checksum of some sort. I haven't figured that out yet. On a key off these parameters get written and while being written they are VERY susceptible to corruption due to voltage issues.
So, the reason any of these display ERR is because the data stored on the EEPROM does not pass the CRC check. When this happens they no longer assume the data can be trusted and display ERR.
I know this is not much of a solution but I still wanted to explain what is happening. I was able to load the "new" values into mine and get all the meters back to 0. So it is essentially what you get after paying big $$$ for a new display. In the near future I would like to help others fix their unit but I need someone to volunteer one first.
Some other things that might be useful info:
-There is a header on the circuit board for programming this chip. It is likely clamped into a fixture at the factory and data "burned" into this chip based on the specific application.
-The EEPROM on mine was not actually broken. Just has bad values in it. I was able to reflash it using this header so there was no need to de-solder anything.
-The I2C bus runs at 40kHz. Slow for I2C but still the entire write cycle is around 4 ms.
That's all I have for now. I hope someone finds this information useful. And if anyone has a bad display laying around and would be willing to let me borrow it please let me know. I would like fix these for people for really need verify a few things.
Aaron
Although this is my first post I did a lot of research on this and other forums before buying a used 2006 King Quad. I purchased one that had a ERR code on the trip odometers. I decided to attempt a fix before buying a new display.
A little background on myself. I am an electrical engineer with a masters in engine design. I wrote engine management software for a marine engine company. So after seeing the issue and putting a lot of thought into it I thought maybe I could at least figure out how to prevent it.
I wanted to post my findings and what I did to fix it so others will at least understand to some level what is happening. I disassembled the display all the way down to the PCB and tried to identify some of the components. There is a little 8-pin chip on there. I couldn't read the markings on it but based on the circuitry around I did determined it to be an I2C EEPROM chip. So I de-soldered it and put it an EEPROM reader. I was correct. It is a simple 1k bit EEPROM chip. Regardless of the manufacturer the pin out and communication protocol is the same on almost all of these little things. So I purchased a Microchip 25AA01, programed it with the value I pulled from the factory one, and powered everything back up. Same problem. But it did work the same otherwise which told me I could move on to mapping out what all the parameters did.
I hooked up an oscilloscope and monitored what addresses the factory system was searching for on keyup and found it reads the following address ranges and through some experiments found out what some of them do. (note these are hex values)
0x00-0x0F:
The kmh/mph setting is stored at address 0. Screwing these up also affects the fuel gauge. Byte 0 gets written immediately after changing the setting by holding both buttons. The last two bytes 0x0E and 0x0F affect the top speed the display will show.
0x10-0x17:
These also affect the fuel gauge. I suspect there is a lookup table in here. They likely use this same software on other ATVs and calibrate it here. It is read but never written.
0x20-0x25:
This is the main odometer storage. Setting the values to 0,0,0,0,0,FF changed the reading to 0. It also gets written about every 1 mile or at keyoff. The number stored in here appears to be a counter so the main display processor is doing some math to convert this count to distance. This is likely the best solution since it must handle both miles and kilometers.
0x28-0x2D:
This is trip A and is more or less the same as the odometer.
0x30-0x35:
This is trip B and works the same.
0x38-0x3D:
This is the engine hours. Once again its a counter of some sort and is not stored as actual hours. The display converts it.
0x40-0x58:
The first byte, 40, contains some value used to calculate speed. Likely pulses per distance. I know setting it to 0 causes the speedometer to quit working and setting it to FF causes it to display way to fast. The rest of these bytes are unknown. I suspect trouble codes from the engine ECU might be stored here.
So, what is the odometer failure? Each of the four counters (Odometer, A,B,hours) uses a 6-byte number where the last one or two bytes are a CRC check. Or a checksum of some sort. I haven't figured that out yet. On a key off these parameters get written and while being written they are VERY susceptible to corruption due to voltage issues.
So, the reason any of these display ERR is because the data stored on the EEPROM does not pass the CRC check. When this happens they no longer assume the data can be trusted and display ERR.
I know this is not much of a solution but I still wanted to explain what is happening. I was able to load the "new" values into mine and get all the meters back to 0. So it is essentially what you get after paying big $$$ for a new display. In the near future I would like to help others fix their unit but I need someone to volunteer one first.
Some other things that might be useful info:
-There is a header on the circuit board for programming this chip. It is likely clamped into a fixture at the factory and data "burned" into this chip based on the specific application.
-The EEPROM on mine was not actually broken. Just has bad values in it. I was able to reflash it using this header so there was no need to de-solder anything.
-The I2C bus runs at 40kHz. Slow for I2C but still the entire write cycle is around 4 ms.
That's all I have for now. I hope someone finds this information useful. And if anyone has a bad display laying around and would be willing to let me borrow it please let me know. I would like fix these for people for really need verify a few things.
Aaron
. Maybe in the future do some cool projects.
