I am examining communication between NEC K13988 chip and LCD embedded controller on board the control panel of a Canon Pixma MX340 multi-function inkjet. There are five wires between them, and I have candidate roles for all five after running the printer and looking at their behavior with a Saleae Logic 8 analyzer. Armed with this information, I can configure the Saleae Logic SPI decoder module.

Selecting channel numbers for data, clock, and enable was straightforward. I had to go back and look at the waveform some more to determine the next few options: enable is low when active and there are 8 bits per transfer. Clock is also low when active, and data is valid on clock trailing edge. (With active low clock, trailing edge is the low-to-high transition.)

That left one unknown: does this system transfer most significant bit first, or least significant bit first? Saleae SPI decoder says most significant bit (MSB) first is standard, so I tried that first. I compared decoded data against what I saw before and saw no resemblance. I then flipped the decoder over to treat least significant bits (LSB) first, and jackpot! Decoded data matches byte-for-byte.

Looking at scenarios for system power-up, LCD screen update, and LCD sleep/wake, the pattern is clear. Every time the main board sent a two-byte command to the K13988 where the first byte is 0x04, the K13988 passes the second byte on to the LCD as a command. For LCD update bulk transfers, where the first byte is 0x06 and second byte is length of transfer, the command itself is not passed along but all bytes transferred afterwards are passed on to the LCD as data.

The question this raises is: do I have the correct setting? Perhaps the asynchronous serial communication between main board and K13988 was supposed to be decoded as MSB first, and the match here is merely a "two wrongs made a right" situation. I thought about it and decided the octal number pattern visible in button matrix scan code report wouldn't exist if decoded as MSB first, so LSB first must be the correct setting.

LCD Pin K13988 Pin Role Notes
1 28 SPI Chip Select Active Low
2 26 Chip Enable Active High
3 27 Command/Data Low = command
High = data

Valid on first clock trailing edge
(low-to-high transition)
4 9 SPI Clock Active Low

8 bits per transfer
5 10 SPI MOSI Data Least significant bit first

Valid on every clock trailing edge
(low-to-high transition)

It's great when observations from different parts of the system align! It gives me confidence my notes here aren't entirely gibberish. As a practical matter I don't expect to put this knowledge to use, since I don't plan to extract this LCD screen from its control panel assembly. I can only imagine one scenario where it might make sense to do so: if I want to update this LCD at a higher frame rate, I can decouple it from the K13988 and hook it up to something else with higher SPI clock speed. I doubt that will happen. I'm more likely to use another display, especially if I have its datasheet to know how much higher I can run the SPI clock. I lack such technical information for this screen. I only have information on what I can characterize based on change in measurable behavior, and it's time to wrap it up with a summary.

This teardown ran far longer than I originally thought it would. Click here to rewind back to where this adventure started.