Yet even more Pinnacle 800i debugging…

I spent pretty much all evening continuing to debug strobing the xc5000 reset on the Pinnacle 800i. Not to beat the topic to death, but this has proved more of a challenge than ever expected. If nothing else, perhaps you will learn something new about methods for debugging these sorts of issues.

I took several approaches tonight. I loaded the card up on a Windows box, and confirmed that it was setting MO_GP1_IO to 0x10ff using the dscaler’s regspy tool. This is a handy little tool for watching registers, although it gives you a realtime view, which means you are likely not to see rapid changes. It doesn’t provide any real logging capability for seeing changes over time (so for example, you cannot really see that it changed a register and then changed it back). In this case though, it reinforced my belief that indeed the xc5000 reset is on the cx23883’s GPIO12.

Then I basically went back to the code, and retraced my steps, hoping it was some sort of typo. No joy. I added a debug line to print out the state of the GPIO register after each operation (before strobing it low, after pulling it low, and after pulling it back high). The register state matched my expectations.

Then started thinking about whether something else could be interfering with the GPIO line. Could there be two GPIO pins wired together? Could it be tristated by another component? One thing that came to mind is the fact that the s5h1409 has its own onboard GPIO. I checked the code and for the Pinnacle 800i, it is set to “ON”. I changed it to off, recompiled and noticed something: although the xc5000 failed to reset, now the initial state of the pin *before* the reset sequence was low. Bingo!

It seems like the hardware design allows both the s5h1409 GPIO and the cx23883 to be able to reset the xc5000. However, it would appear that the s5h1409 configuring it as an output interferes with the cx23883’s operation of the GPIO. I guess the best thing to do would be to extend the s5h1409 to allow it to configure the GPIO as an input, at which point it should start working properly.

This would go so much faster if I could just take a look at the schematic.

Update: now I cannot reproduce the behavior with the s5h1409 – maybe it was just a fluke.

Leave a Reply