This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LM8330: Unable to initialize chip

Part Number: LM8330
Other Parts Discussed in Thread: , TCA8418, TCA8418E

I've created a board design (schematic) with an LM8330 and I cannot seem to be able to establish any I2C connection to it. Here is my initialization code - the first call to `WriteByte(Register::KBDSETTLE, k12msec)` fails. Sorry, that code uses an I2C library, making it harder to follow, but I have used that in a few other projects. I can decode the 1.8V I2C signals just fine with my oscilloscope, but the LM8330 never seems to ACK the address write.

Is there a specific initialization sequence that I need to follow for the LM8330? Is there any sample code anywhere? I am currently using a BGA breakout board, so the decoupling cap is further from the VCC pin than it would be on a board, but aside from that I can't see where my mistake is. I've compared my schematic to the LM8330EVM and don't see any significant difference.

Any help would be very much appreciated.

  • Christopher,

    Thanks for bringing this to E2E. An applications engineer has been notified of this post and will respond accordingly.

    Regards,

    Eric Hackett

  • Hey Christopher,

    "I can decode the 1.8V I2C signals just fine with my oscilloscope"

    Do you have any o-scope shots so we can analyze and see whats exactly going on?

    The schematic looks okay.

    Is there any reason you chose the LM8330 device? I usually try to steer customers to the TCA8418/TCA8418E device since its easier to use.

    -Bobby

  • Hi Bobby:

    Here's the capture, and the same capture zoomed to a smaller timescale.  My first prototype used the TCA8418 (which worked great), but my keyboard has > 80 keys, so I switched to the LM8330.

  • Hi Christopher,

    Your scopeshot looked okay to me.

    I noticed that the datasheet seemed to state the I2C address was 0x88h (though as a byte this was acceptable) but it seems this is a mistake (max 7bit I2C address can be is 0x7Fh). I looked at the User's guide for the EVM and found in the GUI it showed 0x44h as the address so the I2C transactions you sent should have worked.

    I couldn't access your zoomed in smaller time scale scopeshot (requires permissions it looks like) but juding from the one I could see, the VoL of the SDA/SCL lines looked acceptable as well (about 0.4V while the device's ViL states 0.35*Vcc at 0.63V).

    This leads me to believe there may be an issue with the set up somewhere. Things I would probably double check:

    • Device is soldered on properly (not rotated 90, 180, 270 degrees)
    • SDA/SCL of your host are connected to the SDA/SCL of the device (a not so common issue I see people accidentally make)
    • Device #RESET pin is biased correctly to Vcc logic level when communication occurs

    I've checked your schematic to ensure the device pins for the LSF and LM device match the datasheet pin out (looked okay). Maybe there was a trace connection error? (double check this for SDA/SCL connections)

    Let me know if you're able to check the above. If everything seems like its okay then I'll try to modify the EVM I have and see if I get a NACK when I send the I2C address 0x44h.

    -Bobby

  • Hi Bobby:

    I fixed the sharing on the small timescale. I agree that (due to the small size) this chip can be difficult to use (for me). When I couldn't talk to my first LM8330+breakout (which I soldered myself) I ordered one from Proto-Advantage (maker of that board). They have a service where they source and solder the IC, and that failed to communicate just like the first LM8330.

    I was just about to go with using two TCA8418's (one on each I2C bus), but I think I found another IC that meets my requirements. Thanks very much for reviewing my design/code and your suggestions.

  • Hi Christopher,

    Thanks for getting back with me. Sorry that we weren't able to find the root cause here. I agree, if you found a one chip solution, this would be the best approach. (Using 2x 8418s would not work well since you wouldn't be able to tell which button press came in which order since both FIFOs are separated from each other)

    Thanks,

    -Bobby