This was quite an interesting and Fun bug to track down, as it was a mix of software and hardware issues that led to it.

I first noticed this bug after running my oven with its LCD for the first time. I could send it commands well enough, and I could read and write data, but... There was corruption in just the video data going to the LCD. I initially thought it was a bad LCD, however that was quickly proven false after testing it outside of the oven.

It was a fairly distinctive corruption however, and I soon figured out what it was - every time I tried to read a block of data from the display a single bit of information would somehow be skipped. Everything would be shifted left a bit and the resulting data, after being read in and modified (ex for text rendering) would be written back to the display corrupted. The number of bits it was shifted by, amazingly, appeared to be related to the number of separate read/write commands I sent to the LCD!

After writing some software workarounds that fixed the data (thankfully the missed bit would always be 0 and thus wasn't worth worrying about) at the expense of performance, I set about trying to figure out the issue. There was a software component to it, but.. the culprit seemed to be in the hardware, as the code worked fine outside of the oven!

There were only 3 devices on the SPI bus. The LCD, and the two thermocouples. Process of elimination meant that the SPI thermocouple breakouts were to blame, but how? I went over their circuits looking for an answer, and found it. The thermocouple units had pull-up resistors attached to the clock and data lines!

Now it started to make sense. Because the SPI code on the Netduino was in MSIL, it meant that it had to run through an interpreter in the board's firmware before anything could be executed... which was just long enough between the command-write and the data-read that the Netduino's SClk pin would be left floating instead of pulled down.. and the pull-ups on the thermocouples would then take over and assert the bus HIGH.. and then the Netduino would finish executing enough code and pull the bus low in preparation for the read.. which made the LCD output a single bit that the Netduino would never read.

In the end, I fixed it. By using a transistor on the SClk line to isolate the pullups from the LCD and Netduino. The problem went away, the workaround wasn't needed, and all was happy.

And I'm not going to use those thermocouple modules again.