I2C Networked Play on Defcon32 Badge

[bhass1]

Basic sanity testing of the networked play isn't working when I wire up the SAO I2C (I2C_SDA, I2C_SCL, GND).

Badge code appears to use different pins for I2C, pins 2 & 3: https://github.com/raspberrypi/pico-sdk/blob/master/src/boards/include/boards/defcon32_badge.h#L32.

If I remove the #ifdefs around the I2C PIN related #defines in defcon32_badge.h and compile, I2C begins working. With this change, the client can see the host. However after selecting the "Skill Level" on the host, the host just freezes (including the game loop running in the background of the initial menu). On the client side, the lobby and 2 players are shown, and the game loop continues running in the background (this seems normal).

Nothing is jumping out at me from the piconet_start_host function in piconet.c - except maybe this DMA stuff related to I2C? I will need to hook up a debugger and see where we get held up.

Any recommendations from @kilograham would be greatly appreciated ;)

[kilograham]

Yeah, I would try pins 28-29 which have I2C0 - as my first guess is that the other stuff on the I2C bus is confusing things.

[bhass1]

No such luck with User1 (GPIO28) & User2 (GPIO29) from the SAO either. I reflashed both badges to the defcon32_v0 .uf2, but the client and host don't see each other when User1 & User2 are connected. I didn't connect a logic analyzer to see if anything was happening on User1 or User2, but I'd expect it to at least get as far as the client seeing the host's lobby as in my picture.
Also, after that test, I noticed picotool is showing that I2C is using Pins 18 & 19:

Fixed Pin Information
 18:  I2C1 SDA
 19:  I2C1 SCL

Will try to debug my hack (using pins GPIO2 & GPIO3) later once I get SWD going.

By the way, what is the expected behavior of hosting a multiplayer game without any other players? With defcon32_v0 firmware installed, if I press select after hosting a multiplayer lobby, without any I2C connected, the game just freezes, but the audio continues to play. Actually, I just tested this again and it worked, maybe 1 out of 12 tries with defcon32_v0 firmware. It seems timing related. (Here's a video of the timing bug on defcon32_v0: https://github.com/user-attachments/assets/dd2e587d-99cf-4139-9e69-aa7df27cc03b)

[bhass1]

During the error state, the second core gets stuck in the hardware_arlam_irq_handler & picoflash_sector_program, while the first core is happily playing the music: