Tyler Riddle

Hello fellow techies,

This is my first post here ; I'm embarking on some mods for my S2000, starting with a custom gauge face using a non-linear tach:



I'm also interested in solving problems people have when dealing with the S2k instrument cluster, such as the driving 06+ coolant gauges, the outside temp indicator, and the oil life indicator (if it can be individually addressed anyway).

Since that part of the cluster is updated through CAN-bus the information gleaned from figuring out how to drive those indicators will go a long way towards reading data from and feeding data into the CAN-bus for the entire vehicle. While doing my initial research I've found that there is very little information on Honda's CAN-bus usage so I'm hoping to scrape up what ever information exists into one thread.

Personally I'm a software and server infrastructure guy far more than I'm a hardware guy or mechanic but in dealing with CAN-bus this is actually a major win. To the best of my knowledge no existing aftermarket electronics manufacturer has been able to deal with the Honda CAN-bus: Modifry from the S2000 camp doesn't support the 06+ instrument panel when it comes to the coolant temp gauge, Hondata needs the original S2000 CPU in place to allow it to deal with the CAN-bus (pretty sure on this in any case) while it offloads engine management functions to another ECU. As well the coolant temp gauge has frustrated every hobbyist I can find off the project.

I have a good theory why as well as some insight from the computer industry as a whole that can apply here; the caveat is that this information is general theory and I have not embarked yet on studying the actual data stream that is on the S2000 CAN-bus. However when we look at what CAN-bus offers and what Honda actually needs to do with it we can see why dealing with CAN-bus can be (but is not necessarily so) far more complicated than the earlier signaling interfaces such as PWM or analog signals on a wire.

First off a good understanding of what exactly CAN-bus does is important: it's an electrical and data format specification for providing fault tolerant communication from individual components or systems that can each have their own unique identifier. What the hell does that mean? Basically it lets all the parts talk to each other with out having to worry about if they are stepping on each other's toes; each message sent across the bus has an identification number and then a data section which is also just a number. The ID can be a value between 1 and 2046 though some specific numbers are blocked out due to the electrical encoding used. The range for the data field is 1-18446744073709551616 (1 to 8 bytes) again with some specific numbers blocked out due to the electrical encoding used. If we hooked up some device such as http://www.mouser.com/ProductDetail/...xbYTQl6l2UvYCC and displayed the data on the CAN-bus we would see values such as this (note that I am not correcting for the blocked out numbers, these are example values only); the ID number is on the left of the dash and the value is on the right.

1-8
2011-80
4-254
*lots and lots and lots more data, somewhere around 14,000+ identifier and data values per second*
99-21

*checkpointing this post, will continue on another one*

edit list:

• Originally confused 0-8 bytes of data values with 0-8 bits.

Tyler Riddle

We have worked our way to actually reading data off the CAN-bus but how do we interpret that data? This is where things can get very tricky. Lets stick with the coolant gauge and study the details of how information is sent across CAN-bus to see where the gotchas are. The coolant sensor is most likely writing the data values to the CAN-bus somewhere around once a second (maybe less, maybe more, this is actually not too critical). Even though we are reading and writing standard CAN-bus data in a standard way the actual vendor implementation of how to interpret the data is not specified in the standard. Because of this a small subset of the different ways that Honda could have encoded the coolant temp data would be like this (and this is assuming things are dead simple):

1) Honda reads the temp of the coolant and puts the data on the CAN-bus as the actual temp of the coolant in degrees C. Over time a warming up car might output data that looks like this on the CAN-bus reader (time here is not represented to scale, each reading is not 1 second apart):

4-4
4-8
4-20
4-25
...
4-90

as the engine warms up from a cold day to operating temp slightly under boiling temp of water. The instrument panel would then take the temp in C and convert it over to the proper number of bars to be displayed on the temp indicator. This is as straight forward as possible and if Honda actually uses this mechanism then modders luck out big time as this is an extremely easy (with a CAN-bus transceiver chip) signal to read or generate as the need may be. I personally find this particular scenario to be unlikely though of all the places you would find this encoding mechanism I think the temp indicator would be one of the most likely. This is also overly simplistic because of the block-out numbers; certain temp values just can't be indicated at all because when those values are written onto the bus it generates an error. However if 40 degrees is blocked out and 39 and 41 are not, this is not an issue in this specific case because we don't need that kind of resolution.

Just as easily though you could see data like this (again, each reading is not one one second apart):

4-0
4-0
4-0
4-0
4-0
4-0
4-1
4-1
4-1
4-1
4-1
4-2
4-2
4-2
4-2
4-2
4-2

or perhaps (abbreviated data over time)

4-8
4-16
4-32

This is the same data with a different encoding, almost as easy to work with, but a whole lot harder to identify if you don't know what's going on. So what is going on? This example does not encode the temperature of the coolant, instead it encodes the number of bars that should be lit on the indicator inside a binary value. With out going into a lot of detail on how binary numbers work, when we see a number show up as 8 it's an interpretation of the binary value that was read. Interpreting it as a number may not be right. The binary values of those various data fields are represented like this:

0 - 000000
1 - 000001
2 - 000010
4 - 000100
8 - 001000
16 - 010000
32 - 100000

Each number is actually built up from 6 individual values of being on (1) or off (0). In this example we interpret the on/off value from the position in the number as the position that the light bar should be indicating (on my S2000 there are 6 leds on the meter). Two possibilities exist, representing the same thing, but showing different numbers on the bus: we can use the left most or the right most 3 positions in the binary number to tell the gauge which positions to light up. There is another way to encode this same thing where each of the 6 positions corresponds to an individual LED being lit up, such as

10000 - show one bar on the indicator
11000 - show two
111111 - if you actually see all 6 LEDs on an S2000 your engine is already on fire, it's not just overheating
100001 - turn on the left most and right most LED
101010 and then 010101 - if you send these two values over and over, maybe 1/3rd of a second apart, you'd make the LEDs crawl along left to right kind of like the moving christmas lights.

If we convert those binary numbers over to human readable values we wind up with 1, 3, and 63 for the first 3 values - if you were watching the stream of data coming out of the CAN-bus even after isolating the specific ID for the temp indicator with this encoding it would be difficult to decipher what is going on with out looking at the binary data.

Again I do not think this encoding mechanism is what Honda uses but it is possible that it could be used. Again if this is the encoding mechanism we luck out - this can be pretty easy to deal with. I think Honda does some other magic though, next post explains why.

Tyler Riddle

If the data on CAN-bus was that simple I think this issue would have been solved already by others. All though the open question so far on the temp indicator is "what exactly is it's CAN-bus identifier" I think once that question is answered the next question is going to be "what is the encoding method for the values sent to the temp indicator." And while we have seen some simple encoding mechanisms I'd wager (though not a whole lot) that the actual encoding done is far more complicated.

CAN-bus offers an 8 bit data value (11111111) but anything with the same 6 bits in a row is an invalid number. 8 bits normally gives you 256 unique combinations of values and with the block out numbers that's even less - what happens if this is not enough? The answer is to break up the larger message (with more than 8 bits) into more than one message. The actual details of how this works are totally up in the air; there's no real industry standard or accepted practices for this that I'm aware of. Using nothing but the 8 bit values (and some extra information that can be encoded in a CAN-bus data burst that has not been talked about at all) Honda would need to build a system that can transfer larger chunks of data through those smaller data bursts. On the Internet this is the job of TCP/IP but inside a Honda they are free to do what ever they want.

I suspect Honda has created a suite of differing protocols for use on top of the CAN-bus architecture to solve the short-comings I've discussed. Because the details of this protocol can vary widely it'd basically be impossible to continue with out reverse engineering the protocol or protocols. I think this protocol is what has stopped the aftermarket manufacturers from supporting Honda CAN-bus and not just finding identifiers of components. As well we looked at the simple case of the coolant temp gauge - the complexity of a protocol qualified to handle data for a human-rated control system, such as the DBW and the antilock brakes are completely unknown to me. It is very possible Honda borrows the same human-rated protocol for communication on the non-human rated devices, such as the temp gauge, just to save some time. As well it's possible Honda has specifically designed the system to resist tampering in which case they can encrypt the communication in a way that'd make it nearly impossible to access the data with out either some flaw in their implementation (this is more common that you might want to believe however actually breaking crypto is beyond my means) or by actually going after the chip itself which is also beyond my abilities. Though once this layer is broken (if it exists) and is well known it would be an open system as Honda can't go back and change the crypto on existing models.

I'll come back and update this thread as I gain more information from tapping into the CAN-bus but for now I hope this gives people an understanding on why this particular issue might be so hard to crack.

Cheers!

Tyler Riddle

Once I get my hands on the hardware and find someone who doesn't mind having their 06+ S2k tested on I plan on intercepting all of the CAN-bus data going to the instrument panel and feeding it back into the panel after it's gone through some custom software on my computer. The software will filter out specific identifiers (as well as having some other data logging and mining features) to see which ones cause the indicator to stop working. Then I can study the values for the ID and try injecting some of my own custom values and see what happens.

Maybe someone else can get around to that before I do.

DCFIVER

I not a techy by any means however my job does involve trouble shooting CAN networks across the board. So i have at least a rudimentry knowledge of the subject. i know that some aspect of CAN protocol is standardized for automobiles. This is a federal mandate since CAN network is the new OBD system. Also all auto mobiles utilize a host for all communication because they do not have one ecu any more but usually around 30 or more. In Hondas case the host is the MCU. All CAN binary code is processed by the MCU. Maybe if you get your hands on this it may help you.

Tyler Riddle

Ah thanks for the tip! I'm assuming MCU is 'multiplex control unit' and that seems to mean different things depending on the vehicle. For instance I was finding PWM signals coming out of multiplex units on Hondas being talked about on various posts. I would not be surprised however to find a master node on the CAN-bus brokering all communication between the other nodes and having it also be called a multiplex control unit.

I did some digging and there are in fact a number of available standard protocols that operate on top CAN-bus:

• http://en.wikipedia.org/wiki/J1939
• http://en.wikipedia.org/wiki/DeviceNet
• http://en.wikipedia.org/wiki/CANopen
• http://en.wikipedia.org/wiki/CAN_Kingdom

Even if Honda did adopt something like J1939 across the board it still leaves a lot of room for vendor specific customization as the specification itself does not include what specifically the vendor is doing with the data being transmitted, instead focusing on how to send the data.

Does anyone know what protocols Honda is using? Did they roll their own? Does anyone have a CAN-bus data stream that's been read from a Honda?

For posterity I also found the CAN wiki: http://www.can-wiki.info/

Tyler Riddle

Looks like in 2008 the US Federal Government mandated CAN-bus as the communication standard in road going vehicles though I'm unsure at this point of the full extent of that mandate. Thus far I've still been unable to find CAN-bus anything in my 2002 S2000; CAN-bus is one of the signaling mechanisms that the OBD-II port can use for communication to a reader but my S2000 only has the K-LINE wires hooked up according to the data I found.

Some more open questions: on a 2006+ and a 2008+ S2000 is the CAN-bus line in the OBD-II connector electrically active (this can be answered by anyone with the Helm for an S2000 that handles those model years, mine does not)? If so, is it actually an identical bus to what is used for communication inside the cab of the vehicle?

For posterity the full ODBC-II pinout is as follows (from http://en.wikipedia.org/wiki/OBD-II#...stic_connector:

1. Manufacturer discretion. GM: J2411 GMLAN/SWC/Single-Wire CAN.
2. [[Bus (computing)|Bus]] positive Line of [[Society of Automotive Engineers|SAE]]-J1850 PWM and [[Society of Automotive Engineers|SAE]]-1850 VPW
3. Ford DCL(+) Argentina, Brazil (pre OBD-II) 1997-2000, Usa, Europe, etc.
4. Chassis ground
5. Signal ground
6. CAN high (ISO 15765-4 and [[Society of Automotive Engineers|SAE]]-J2284)
7. K line of ISO 9141-2 and ISO 14230-4
8. -
9. -
10. Bus negative Line of [[Society of Automotive Engineers|SAE]]-J1850 PWM only (not [[Society of Automotive Engineers|SAE]]-1850 VPW)
11. Ford DCL(-) Argentina, Brazil (pre OBD-II) 1997-2000, Usa, Europe, etc.
12. -
13. -
14. CAN low (ISO 15765-4 and [[Society of Automotive Engineers|SAE]]-J2284)
15. L line of ISO 9141-2 and ISO 14230-4
16. Battery voltage

However on my S2000 only lines numbered 4, 5, 7, 9, 14, and 16 are electrically active. Honda uses pin 9 as the communication for "circuit F28" and 14 as "circuit F54" and "ABS/SRS input/output".

I didn't catch this before but since pin 14 is supposed to be a CAN pin and Honda is using it specifically for SRS/ABS communication this might actually be a real CAN-bus signal here; seems like pin 14 on the DLC goes through to pin 10 on the ABS modulator control unit though I can't confirm yet what the ABS MCU expects to see. For some reason Honda would have only used 1/2 of the signaling wires of standard CAN because pin 6 is still unused. Odd but another thing to investigate.

Tyler Riddle

Wikipedia has a great page on OBD-II PIDs and also how to send and receive OBD-II information over CAN-bus, see http://en.wikipedia.org/wiki/OBD-II_PIDs#Standard_PIDs which has a lot of good information on the different ways to encode the data. It looks like in OBD-II the coolant temp value is interpreted as a number however to get the proper value you have to subtract 40 from it, so instead of being from 0-255 the range is -40 to 215 degrees C. There is also the http://en.wikipedia.org/wiki/OBD-II_PIDs#CAN_Bus_format section of that page which details the protocol for OBD-II communication on top of CAN-bus.

Conceptually Honda may share the CAN-bus with the OBD-II reader and the instrument panel by turning the panel into a fancy OBD-II reader. This is simple for them and simple for us.

DCFIVER

Right, CAN protocol was mandated for all vehicle use starting in'08. Before that time is was manufaturers descretion as to whether or not they chose to use the format. Honda cars began CAN communication in '03 with the then new Accord. This is why your '02 S2000 doesnt have dedicated CAN lines.

Tyler Riddle

Here is a fascinating research paper on a GM CAN-bus implementation: http://www.autosec.org/pubs/cars-oakland2010.pdf. The researchers looked at the vehicle control system from the angle of trying to injure the occupants. I'll do a quick translation to human:

The scientists used some relatively inexpensive off the shelf components to read and write data on the OBD-II port of a 2009 GM vehicle. The found an instance of a standard protocol used on top of CAN-bus and that protocol includes some authentication and authorization features but does not seem to include any encryption. The access control mechanisms in use on the vehicle were either unimplemented or so easy to bypass as to be irrelevant to the researchers (specifically, the entire space for the authentication keys can be searched in 7 days with out even having to modify the vehicle; 2 days if you want to move parts to the bench to study them).

The researchers were able to gain near complete control over the vehicle. Aside from sending in signals and doing things that are obvious they were able to disable the brakes completely with out the driver being able to override the action by placing the braking controller into a testing mode. They were able to have the ECU provide power to the ignition and had control over the entire engine even without the key being in the run position (they were also able to command the system to refuse to spit out the key). They had the locking subsystem under software control and they sent lock commands to the doors as fast as possible but they were unable to trap occupants in the car; consider that not all vehicles have a physical connection to the door locks and this becomes possible.

You might be thinking something like HOLY ****ING **** THIS SHOULD NOT BE POSSIBLE and well you are right. While I love to poke fun at GM by saying they designed their vehicle control system like the head gasket that failed in my S10 Blazer at 60k miles and that's just what GM does it's not so simple. While this specific case study is pretty bad the other vehicles using CAN-bus are probably similarly bad. It's going to take some time to see what's going on with the Honda CAN-bus implementation but I'm both inspired and appalled by what this research paper has found.

In the CAN-bus implementation for that car there are two isolated busses: low speed and high speed. The body is on the low speed bus and the engine, safety systems, and control devices are on the high speed bus. The OBD-II port is physically wired to the low-speed bus and there is no direct physical connection between the low and high speed bus. This is by design as the protocols that GM used consider the low-speed bus to be less critical than the high speed one. The researchers used a rather clever technique to gain access to the high speed bus from the low speed one.

The OnStar device is physically connected to both the low speed and high speed bus because it needs information from both to do it's job. The protocol specifies that devices should be able to have their software updated only on the high-speed bus however the OnStar is updatable only from the low-speed bus. The device is supposed to enforce security on any software updates into it however the researches in essence broke all the security of the vehicle so this is not an issue; the researches injected new software into the OnStar device that turned it into a relay between the low speed and high speed buses. Thus now the researchers have access to the safety critical systems on the car (they could have attained the same thing by connecting to the fast bus but going in through the OBD-II connector adds lots more scary points).

The various controllers on the bus take commands like 'you are in a test, set this value specifically and hold it there.' Again these commands are 'secured' but the security is so poor that it does not matter. The protocol also says that systems like brakes should restrict testing modes to only when the vehicle is not actually being operated; obviously they failed to implement that bit.

Keep in mind that I'm confident the researches attained or would have been able to attain full control over the vehicle via the OBD-II bus. The focus on the paper was specifically security of the vehicle control network and how that effects occupant safety. While all the various ways to configure the car to kill people exist the level of control possible shows there is a lot of room for vehicle tuning and custom behavior of the body.

DCFIVER

Yes I read that paper.. They were talking about the possibility of malware being introduced into the vehicles control systems and demonstrated how easy it was to infiltrate the system and making it operate outside of its protocols by spelling out things on the dash info center and making the brakes apply,among other things. it was an interesting read and one that is very feasible.

Tyler Riddle

Specifically the OnStar device is both trivial to install new software into and uses a well documented and understood commercial operating system. Aside from flashing a small program the researchers created to the OnStar that turned it into the bridge between the OBD-II port and the high speed bus they also modified the OnStar software while the device was running. They set it up to do something arbitrary (run the windshield washer fluid) when the car hit 20 mph and then when it came to stop the OnStar would reboot itself and remove any trace of a modification.

There is an extremely real scenario of building a box with some pig tails that hooks up to an OBD-II port and automates everything the researchers did to literally create a Christine mod-chip for that car. So real that it is only waiting for someone to do it. You don't need the NSA to do this, you need a Linux hacker. They also point out that the audio system is on CAN-bus and that access to the bus itself means you can modify the OnStar to do your biding later. Malware could leak in to this system if it was planted at any vendor who connects onto the bus, such as suppliers to GM, or aftermarket parts. Considering digital cameras and USB memory sticks have been shipping out infected with malware direct from even extremely reputable vendors it's very conceivable Alpine (or anyone else) could accidentally have a part supplier plant a software package that would later infect the OnStar of a GM vehicle it was integrated into (assuming integration involving can-bus of course). You need to worry about the kid at the car wash plugging into the OBD-II port for a minute while you aren't looking if you are going to be sufficiently paranoid to keep someone from infecting your car with out you knowing it.

Eagle_Phoenix

I believe that there's no another way for we to find out this than sniff and decode the data that flows into the b26 wire on cluster.

Any attempt to create something to hit something against the nature, it will be a completely waste of time and money.

We must to hack the signal flow that goes to that wire and develop something able to generate the same signal variation to supply the lights that is on f-can and the coolant temp gauge addresses code variable.

Once we get what addresses and how they are sent to cluster, we will be able to develop some kind of circuit on pic language and burn the hex file with precision and manage to transform a "variable resistance" into "f-can messages" to enable the coolant temperature full on in relation to coolant variable resistance.

I am quite good in this stuff to convert electric signals, but I confess that this f-can is a completely "pain on ***", but as much hard is something, as much will be our pleasure when we win at the end of this battle with rocks and wood.

Cheers M8.

Eagle_Phoenix

It works on k-line, I opened the cluster and wrote the names of parts and searched around internet the datacheet of them ....

The can bus chip is "mc33290" and the mcu is 64325439 from "Renesas" this processor connects with uart single k-line on pin 37 and 38 HPX_D1 and HTX_D1Usage Notes

(1) Reset

The HCAN is reset by a reset, and in hardware standby mode and software standby mode.

All the registers are initialized in a reset, but mailboxes (message control (MCx[x])/message data (MDx[x]) are not. However, after powering on, mailboxes (message control (MCx[x])/message data (MDx[x]) are initialized, and their values are undefined. Therefore, mailbox initialization must always be carried out after a reset or a transition to hardware standby mode or software standby mode. Also, the reset interrupt flag (IRR0) is always set after reset input or recovery from software standby mode. As this bit cannot be masked in the interrupt mask register (IMR), if HCAN interrupts are set as enabled by the interrupt controller without this flag having been
cleared, an HCAN interrupt will be initiated immediately. IRR0 must therefore be cleared during initialization.

(2) HCAN sleep mode The bus operation interrupt flag (IRR12) in the interrupt register (IRR) is set by bus operation in HCAN sleep mode. Therefore, this flag is not used by the HCAN to indicate sleep mode release. Also note that the reset status bit (GSR3) in the general status register (GSR) is set in sleep mode.

(3) Interrupts
When the mailbox interrupt mask register (MBIMR) is set, the interrupt register (IRR8,2,1) is not set by reception completion, transmission completion, or transmission cancellation for the set mailboxes.

(4) Error counters

In the case of error active and error passive, REC and TEC normally count up and down. In the bus off state, 11-bit recessive sequences are counted (REC + 1) using REC. If REC reaches 96 during the count, IRR4 and GSR1 are set.

(5) Register access Byte or word access can be used on all HCAN registers. Longword access cannot be used.

(6) HCAN medium-speed mode HCAN registers cannot be read or written to in medium-speed mode. Controller Area Network (HCAN)

(7) Register retention during standby All HCAN registers are initialized in hardware standby mode and software standby mode.

(8) Usage of bit manipulation instructions
The HCAN status flags are cleared by writing 1, so do not use a bit manipulation instruction to clear a flag. When clearing a flag, use the MOV instruction to write 1 to only the bit that is to be cleared.

(9) HCAN TXCR Operation

1. When the transmit wait cancel register (TXCR) is used to cancel transmission of the
message in a mailbox waiting for transmission, the corresponding bit in TXCR and the
transmit wait register (TXPR) may not be cleared even after the transmission is canceled.

This occurs when the following conditions are all satisfied.
[Conditions]
⎯ The HRxD pin is tied to "1" because of a CAN bus error, etc.
⎯ There is one or more mailboxes waiting for transmission or transmitting.
⎯ Ongoing message transmission from a mailbox is canceled by TXCR.
If this occurs, the transmission is canceled but TXPR and TXCR continue to indicate a
wrong status telling that a message is being cancelled. As a result, transmission cannot be restarted even after the HRxD pin is released from the tied state and the CAN bus has
recovered. If there are two or more messages for transmission, a message which is not
being transmitted is canceled and a message being transmitted retains its state.
To avoid this, take either of the following countermeasures.

[Countermeasures]
⎯ Do not cancel transmission by TXCR. Transmission will be completed after the CAN
bus has recovered, then TXPR is cleared and the HCAN operates normally.
⎯ To cancel transmission, write 1 to the corresponding bit in TXCR repeatedly until the
bit becomes 0. TXPR and TXCR are cleared, and the HCAN operates normally.
2. When the bus-off state is entered while any mailbox is waiting for transmission with TXPR set, transmission cannot be canceled even if TXCR is set because the internal state machine does not operate during the bus-off state. Because of this, on recovery from the bus-off state, one message will be transmitted or the message will be canceled with a transmission error. For message clearing on recovery from the bus-off state, take the following countermeasure.

Controller Area Network (HCAN)
[Countermeasure]
⎯ Reset the HCAN during the bus-off period to clear the messages in the mailboxes
waiting for transmission. To reset the HCAN, set the module stop bit (MSTPC3 in
MSTPCRC) to 1 and then clear it. In this case, the HCAN is entirely reset. Therefore
the initial settings must be made again.

(10) HCAN Transmit Procedure
When transmission is set while the bus is in the idle state, if the next transmission is set or the set transmission is canceled under the following conditions within 50 μs, the transmit message ID of being set may be damaged.
• When the second transmission has the message whose priority is higher than the first one

• When the massage of the highest priority is canceled in the first transmission
Make whichever setting shown below to avoid the message IDs from being damaged.

• Set transmission in one TXPR. After transmission of all transmit messages is completed, set transmission again (mass transmission setting). The interval between transmission settings should be 50 μs or longer.

• Make the transmission setting according to the priority of transmit messages.
• Set the interval to be 50 μs or longer between TXPR and another TXPR or between TXPR and TXCR.

Table 16-6 Interval Limitation between TXPR and TXPR or between TXPR and TXCR
Baud Rate (bps) Set Interval (μs)

1 M 50
500 k 50
250 k 50

(11) Note on Releasing the HCAN Reset or HCAN Sleep Before releasing the HCAN reset or HCAN sleep (MCR0 = 0 or MCR5 = 0), confirm that the GSR3 bit (the reset status bit) is set to 1.

(12) Note on Accessing Mailbox during the HCAN Sleep
Do not access the mailbox during the HCAN sleep. If accessed, the CPU might halt. Accessing registers during the HCAN sleep does not cause the CPU halt, nor does accessing the mailbox in other than the HCAN sleep mode.

Eagle_Phoenix

UART: K-Line, J1708, ISO9141, GM CGI, RS232


The UART is a very common serial protocol. This type of serial communications is used for the popular RS232 protocol. Also, because of its wide availablity and low cost it is used in many automotive protocols such as J1708, ISO9141, K-Line, GM CGI, and RS232. More at Wikipedia.

Eagle_Phoenix

NOW WHAT?

Eagle_Phoenix

pics

championx

Hi! im developing a can bus logger, i logged this data on a honda civic si

MODO SELECCIONADO 2 - CAN BUS 250kbps

FORAMAT: DECIMAL ID | 8 bytes data | number of data bytes

Datos: | 373854793 | 074 094 000 000 000 000 000 000 | 02 ***
Datos: | 373854793 | 078 010 000 000 000 000 000 000 | 02 ***
Datos: | 00001684 | 074 094 036 157 071 249 109 124 | 09 ***
Datos: | 00001684 | 079 010 036 188 191 000 000 014 | 15 ***
Datos: | 00001684 | 075 126 036 157 071 249 109 124 | 08 ***
Datos: | 00001684 | 074 094 036 188 191 000 000 014 | 14 ***
Datos: | 00001684 | 078 010 036 157 071 249 109 124 | 08 ***
Datos: | 00001684 | 079 094 036 188 191 000 000 014 | 08 ***
Datos: | 00001684 | 075 126 036 157 071 249 109 124 | 11 ***
Datos: | 00001684 | 074 094 036 188 191 000 000 014 | 08 ***
Datos: | 00001172 | 078 010 036 157 071 249 109 124 | 09 ***
Datos: | 00000404 | 079 094 036 188 191 000 000 014 | 08 ***
Datos: | 00001684 | 075 126 036 157 071 249 109 124 | 08 ***
Datos: | 00001684 | 074 094 036 188 191 000 000 014 | 10 ***
Datos: | 373854793 | 078 010 000 000 000 000 000 000 | 02 ***
Datos: | 289968713 | 078 144 000 000 000 000 000 000 | 02 ***
Datos: | 303615711 | 075 126 036 157 071 249 109 124 | 09 ***
Datos: | 373854793 | 074 094 000 000 000 000 000 000 | 02 ***
Datos: | 373854793 | 078 010 000 000 000 000 000 000 | 02 ***
Datos: | 373854793 | 079 094 000 000 000 000 000 000 | 02 ***
Datos: | 373854793 | 075 126 000 000 000 000 000 000 | 02 ***
Datos: | 00001684 | 079 094 036 188 191 000 000 014 | 08 ***
Datos: | 00001684 | 074 094 036 157 071 249 109 124 | 08 ***
Datos: | 00001684 | 078 010 036 188 191 000 000 014 | 08 ***
Datos: | 00001684 | 079 094 036 157 071 249 109 124 | 15 ***
Datos: | 00001172 | 075 126 036 188 191 000 000 014 | 09 ***
Datos: | 440963657 | 074 048 000 000 000 000 000 000 | 02 ***
Datos: | 00001684 | 078 010 036 188 191 000 000 014 | 08 ***
Datos: | 00000404 | 074 048 036 157 071 249 109 124 | 08 ***
Datos: | 00001684 | 075 126 036 188 191 000 000 014 | 11 ***
Datos: | 00001684 | 074 094 036 157 071 249 109 124 | 08 ***
Datos: | 00001684 | 078 010 036 188 191 000 000 014 | 09 ***
Datos: | 00000404 | 079 094 036 157 071 249 109 124 | 09 ***
Datos: | 00001684 | 075 126 036 188 191 000 000 014 | 08 ***
Datos: | 00001684 | 074 094 036 157 071 249 109 124 | 10 ***

Eagle_Phoenix

Great dude! this really gives an idea of what data does it flow into "MAIN ECU" and how data flows on canbus protocol, but we are talking about a ISO k-line "mc33290" that WORKS WITH A HCAN CONFIRMED BY DATASHEET, ISO9141, one wire for comunication from cluster.

The information you got is the full network log, "MCU" from "ECU Module" is a completely different processor from "s2000 Cluster ECU Processor (mcu is 64325439 from "Renesas"), both mcus connect to each other via k-line network, (this is the way "s2000 ap2 2006+ ecm" communicates with the s2000 cluster over k-line communication translated from "mc33290" in cluster to cluster processor using SCI.

Serial Communication Interface (SCI) uses port SCIRxD SCITxD and DX using logic 1 and o to turn on\off the k-line "mc33290".

My idea is to develop a circuit that from max232 on db9 com port I can log into this SCI port SCIRxD - SCITxD, using some software and testing all the possible commands in oder to see what really works.

Then, the final project converter idea will be a pic with sci port programmed on data related to cluster bargraph and on another pic port an adc (analogic to digital converter) based in some variable resistence that it will receive from any coolant sensor, converting it to digital data that pic mcu will forward into s2000 mcu tx, rs ports and making the temp goes up and down.

It is a such small circuit to do this job and I want to bite my hat if I cannot finish it for people dont waste their brain like I did.

Well, people could help me giving ideas on how data is sent in a max232 to SCI, I got already some diagram and I am working on circuitry.........

I will create a circuit that will communicate straight with cluster processor as I will weld the tx rx straight on input output processor removing the k-line chip, then I will send .... receive commands via hyperterminal.

This is the path.


CAN SOME ONE TELL ME HOW TO CONNECT TO (SCI) AND SEND COMMAND LINES ON HYPER TERMINAL???

Well, I think nobody will ... then I will come back here and post the commands.

nutnut

It doesn't work like that. There are more than 5 consecutive 1's banned on the wire, but not in the CAN protocol. The transceiver inserts a 0 in such condition, and the receiver discards it (or if it sees more than 5 1's it knows there was an error during the transmission). Yes, that means that the various fields of the frame can take more bits on the wire to transmit than what is their specified lenght. Still the CAN controller that sits behind the transceiver sees them like specified.

http://en.wikipedia.org/wiki/Control...k#Bit_stuffing

To the coolant temperature sensor ID search, just log all the data and then search with a script for an ID whose data changes corelate with the gauge changes, or you can even force the changes by unscrewing the sensor and bottles with cold and hot water ;-)

Eagle_Phoenix

You mentioned that I could unscrew the sensor from engine block and test the resistance, later on searching on Engine ecu addresses code... it is a good and easy idea;

I thought that when ordered this cluster one year ago!

However, I haven’t got an s2000 year 2007 ap2 Car, even though an “ECU”,

I got only the cluster!

If I got the "ECU" things would be different!

The reason I am doing this is because, I just wanted to add this cluster into my Eagle DSM.

It is really confused what do you mean is not like that? This last information here I got from Datasheet.

I am doing reverse Engineering of this cluster and all those electrical information’s are true and really the parts on cluster.

If you don’t believe me, just go and buy a cluster and only with cluster, try to make the coolant gauge to work… by yourself.

Can you be clear on what you are saying?

Kind Regards.

Eagle_Phoenix

HERE WE ARE!!!


https://honda-tech.com/attachment.ph...1&d=1295845978

IT IS VERY CLEAR ON DATASHEET! .... MC33290, YOU CAN SEARCH AROUND! IT IS IMPOSSIBLE TO CREATE SOMETHING WITHOUT KNOWING WHAT KIND OF CIRCUITRY IT HAS! IMPOSSIBLE ...........


https://honda-tech.com/attachment.ph...1&d=1295845978

nutnut

The part I quoted, there are no numbers blocked in the CAN protocol, the so called "blocked" are just transmitted differently on the wire.

If you don't have the ECU, ask someone who has an S2K to record a log from cold start to warmup and search it for suspect values.

Eagle_Phoenix

This is the problem m8, (NOBODY HAS A S2000 AP2 YEAR 2007) and there is hundreds of wenkers that lie that has one.

It is quite expensive this model ..... I never found some one who has it!

Basically, I am deeply studying the protocols of how this "hcan" works and will try all the possible and logic method, but for this time only I just developed the circuitry part of this project.

I found something to use and log,

https://honda-tech.com/attachment.ph...1&d=1295884514

high speed ISO9141 interface based on not opto-isolators but a dedicated ISO driver IC, the Motorola MC33290D.

Using a dedicated IC gives many advantages:

HARDWARE CIRCUITRY

High speed operation, upto 115.2kpbs

Electronics protection against bus short circuit.

Wide operating voltage

Pin 6 and 5 can inteface directly to a microprocessor but to connect to a PC's serial

port a voltage level converter as such a MAX232 must be used.

Eagle_Phoenix

My idea was to jump this circuit and try to communicate straight away on cluster mcu!!!! it will avoid time to find out the code for later on, think how to create a something with a "map curve" in order to make cluster bar usable in this conversion.