DIYEFI.org Forum

This topic is dedicated to knock detection issues and algorithms using onboard chip HIP9011

Currently we have an issue related to initialization of HIP9011 at startup of firmware. Some times chip does not want to init, while receives SPI commands. When you turn on (or turn off,on) it from manager software manually it accept initialization commands and start to work.
Maybe, there is an unknown issue which was not described in data sheet. SO-terminal indicates success, but it seems internal state machine does not accept SPI commands.

Does anyone faced with such issue?

Did you check for chip errata? It *may* be documented.

Yes. I've searched, but there are no any errata for this chip

I'm not very familiar with that chip, so my suggestions may be way off. I see the XTAL case isn't bonded to GND. I forget exactly why that is common. I want to say it was partly for structure, but also for a cleaner clock signal. I'm not sure if that could perhaps cause the XTAL to fail oscillation's. I seem to recall some caution about heating the case, so small solder joints are better than large ones. For testing purposes, a mechanical clip should work just fine.

The inductor in series on the +5 is jumping out at me. I might recommend following some of the practices found on the FreeEMS 1.0 board. Over Voltage spikes are handled with a diode, over current conditions are handled with a small resistor, ect. The inductor makes me wonder if you are getting voltage spikes or intermittent voltage sags. Also the inductor may dampen the initial ping on the XTAL, which is unlikely, but may prevent the XTAL from oscillation. When it doesn't work, will touching the XTAL pin with a scope probe make the chip start working? A locked XTAL is often hard to identify, because as soon as you try to look at it, that's typically enough of a ping to get it started.

I see the SPI as commands only, and I only see one command that might cause it to fail or appear to fail to produce a result. That's the prescaler. It appears that Fred has removed the hardware files I released from the SF site, and has not reposted them on freeems.org and has not updated the wiki links. I don't know how one would be expected to know they exist. You'll have to get them from my dev copy on github. Here's a link to my copy of what I've called Freeems 1.0.

http://github.com/jharvey/FreeEMS_1.0_hardware

Here's a link to the PDF, see page 2 for the Vreg

http://github.com/jharvey/FreeEMS_1.0_h ... l_A.20.pdf

I have only briefly read the datasheet, I don't see anything that specifies it will start working upon power up. Could it be possible that by design it requires a wakeup of some sort in this case it sounds like it can happen via SPI? Could part of the ECU initialization include a SPI ping?

inductor may dampen the initial ping on the XTAL - agree, theoretically this can be. But data sheet does not give information about required power up conditions.
One of users told me that it also begin to work after he resets microcontroller manually . I've checked and know exactly that redundant call of initialization procedure(knock_module_initialize) makes HIP9011 to work. I will check different conditions with oscilloscope.

Great and keep us posted. I'm interested in hearing more. At this point, I don't see how I can be of much help with out more data. If you can get some scope trace pictures posted or something similar perhaps I can offer some insight.

I'm curious how you know it fails? Have you put a speaker next to the knock sensor, then play a recorded knock, or something similar? I wonder if the ping source could be where it's failing. Perhaps the chips is working well, and ping simply isn't happening, or isn't coupling into the knock sensor. I can't tell from the small amounts of data I've got.

I've observed this behavior on engine, other users report the same behavior. One of users uses external generator to check operability. If initialization fails, analog signal on the integrator's output (INTOUT) is absent.
Anyway, I will investigate this bug myself and publish results, because currently I have digital oscilloscope.

I'm curious, in knock_module_initialize around/below line 88, why the 10 cycles of this function? At a first look, I would expect it to have done it's task on the first pass. I might guess that's done to make sure the data made it into the registers, however that's a guess.

I'm also a bit confused by the use of SO and SI lines. In diagnostic mode (TEST pin low) the SO can be three different things. One is an buffered echo. I don't see where the data sheet spells out what it does when TEST is high. Your code would lead me to believe when TEST is high, it echoes the commands you sent it. An echo under the right conditions could likely ensure the word got there, however, it may not indicate that the word was properly received. I see the datasheet notes "the transition of CS from a low to high transition will cause the data-word in the SPI Buffer to be loaded into the proper addressed programmable register." So the word can't be read from the register until after it has been fully received and the CS line cycled.

If you were to briefly switching to diagnostics mode and read the actual register data, it would appear that would help verify the data was actually received. However, it also appears that the operations under diagnostics mode are not well documented in the data sheet. I know that bits B4B3B2B1 are used for diagnostic purposes, and I know that one can read several different piece of data when in diagnostics mode, but I don't know what those bits do. I'm looking at datasheet fn4367.pdf. Is there a different datasheet that explains the actions that these bits will perform? Perhaps a call or e-mail to Intersil could produce some more information about the diagnostics mode.

I wonder if the problem with the chip is that it's being commanded, but not fully received.

I see that HIP9011ABT, and HIP9011AB are inactive, while HIP9011ABZ and HIP9011ABZT are active. I'm curious, does yours have a Z in the part number?