I decided to try a newer Arduino library for the Wii chuck and a test sketch to read the buttons and joystick position and surprisingly it worked perfectly.
I then took a Digilent Analog Discovery and used the Waveforms software to have a look at what was happening on the I2C bus on the working Arduino example and then the non-working DesignLab example on the Papilio and I could see a difference in the initialization sequence being sent from each. I guess I should have compared the two libraries and found the issue without breaking out a scope, but where's the fun in that, right?
The Arduino example was sending hF0, h55, hFB, h00 as the init sequence.
The Papilio example was sending h40, h00, hFB, h00 as the init sequence.
After doing a bit more reseearch I changed the following section in the WiiChuck.cpp in the WiiChuck library in DesignLab as below:
int err = 0;
err = -1;
// if (I2C.tx(0x40)!=0) - this is for OEM Wii nunchucks
if (I2C.tx(0xF0)!=0) // for clone Wii nunchucks
err = -1;
// if (I2C.tx(0x00)!=0) - this is for OEM Wii nunchucks
if (I2C.tx(0x55)!=0) // for clone Wii nunchucks
err = -1;
I recompiled the sketch, uploaded to the Papilio and I'm now getting the following results when testing:
No Joystick or button activity - Chuck: 128 127 buttons 0 0
Joystick left - Chuck: 46 127 buttons 0 0
Joystick right - Chuck: 255 127 buttons 0 0
Joystick up - Chuck: 128 255 buttons 0 0
Joystick down - Chuck: 128 46 buttons 0 0
Button C - Chuck: 128 127 buttons 0 1
Button Z - Chuck: 128 127 buttons 1 1
Button C+Z - Chuck: 128 127 buttons 1 0
I was not aware that some (all?) clone chucks do not respond properly to the standard init sequence. The following comment was in the Arduino library that I used (https://playground.arduino.cc/Main/WiiChuckClass):
// instead of the common 0x40 -> 0x00 initialization, we
// use 0xF0 -> 0x55 followed by 0xFB -> 0x00.
// this lets us use 3rd party nunchucks (like cheap $4 ebay ones)
// while still letting us use official oness.
// only side effect is that we no longer need to decode bytes in _nunchuk_decode_byte
Thanks for the advice Alvie, using the scope certainly revealed the issue even if it wasn't due to a hardware fault or misconfiguration.