Victoria came out to New York this weekend. We did a walking tour of Union Square, and then had a nice dinner at Hangawi. Today we took it easy and spent a couple of hours at the coffee house.
This evening continued to work on the HVR-950q i2c implementation. It seems that at higher clock rates the au0828's hardware implementation drops the stop bit after certain write sequences. I can see it on the logic analyzer's dump (the master never pulls the signal high and it stays in that state until the next i2c sequence), but I cannot nail down the underlying problem yet. Seems like the au0828 might improperly handling the SCL clock stretching the xc5000 does after some operations (which is why it only starts to occur *after* the firmware load completes).
Update: I think I know what is going on now: The xc5000 *is* stretching the clock for 15 us. Now, when you're running at 100KHz, that means the clock basically gets held low for three cycles, which screws up the au0828 and causes it to not write the stop bit. However, if you turn the clock down to 30 KHz, the normal clock cycle is 17 us. As a result, the au0828 never notices that the clock is being held low by the xc5000, since it's inside the interval it would be holding it low anyway.
In other words, the au0828 has a crappy i2c implementation in its hardware. Basically, my options are to keep the clock at 30KHz, and suffer from the 10 second loading time, or get the au8522's i2c master working and refactor the xc5000 driver, which would allow me to use the au0828's faster bus mode for firmware loading, and a slower clock rate for sending the commands for tuning via the au8522.
