So I got a qwiic buzzer bob-24474. and in a week’s time it has changed address 4 times. I have never tried to change the address myself. I will restart my project and get an error, run a i2c scan see the new address, change the source code, recompile, and it works again for a day or so. Simple to fix but a pain.
any ideas on what I can check? I would just write it off, but 4 times in about as many days is just to much. I would like to place this project and forget about it.
If possible, try to use a different Qwiic cable or connector.
Does it reset after power cycling the MCU?
I never thought to much about it, I was treating a reset the same as a power cycle. But I think at least 3 of the 4 may have been from a dead cold start. Once if a remember was just from a reset.
To the first response, I have tried different cables. I tried alone or daisy chained
After a few days it did it again, this time I know it happened after a reset, whats more after running i2c scan, and updating the address in the code, it still says it is freezing. I cut ot the while(1) to keep testing, but it is not working at all now.
Same issue here. The address went from 52 to 54 and while the led still turns on and off, no more sound is produced. Power cycling and changing cables does nothing, does anyone know a solution ?
I have the same issue here. The device went from address 52 to 54, and makes no more sounds. The led still turns on. Is there anyway to recover the device ?
Can you share a photo of your setup? How many devices are on the i2c bus, and how long are the cables?
Here is a picture as you asked. The problem is the same if I disconnect the sensors after the buzzer (there is still be the imu from the XRP controller board on the line). The cable should be ok, because if I replace the buzzer with another buzzer, it works.
The firmware (the sketch) on the Qwiic buzzer is SparkFun_Qwiic_Buzzer/Firmware/QwiicBuzzerFirmware/QwiicBuzzerFirmware.ino at main · sparkfun/SparkFun_Qwiic_Buzzer · GitHub
There is a triggerpin, which when detected LOW for 1 second during startup(), will reset the saved /updated parameters (including I2C address) in EEPROM. The Triggerpin is set as input with pullup, but maybe that is not enough. See whether adding a 10K pull-up on the triggerpin makes a difference..
Hi All, Sorry for my delay in response here.
@paulvha , I think you are on to something here, but FWW, we didn’t have any units incorrectly/randomly execute a factory reset during our testing during product development. I would hope that the internal pullup on the ATTINY84 would be able to hold the line high. Your idea to try an external pullup resistor is worth a shot, though.
@PlantagoLabs Have you ever noticed the stat LED blink three times? (This would indicate a factory reset). Also, can you double check the address you are setting, and the address it is randomly changing to? (0x54 seems really strange to me, the factory reset address should be 0x34)
@Darin_Dugger Have you ever noticed your buzzer blinking its stat led three times to indicate a factory reset? What microcontroller are you using? Anything else on your qwiic bus?
Another idea: 0x54 and 0x52 are very close (there’s only one bit difference),
I’m wondering if it might be worth adjusting your code to try some slower I2C clock frequencies (like lower than 100KHz, the default).
Related to clock speed, If you have a lot of things on the qwiic bus, then it also might be worth ensuring that you only have one set of pullups. You can cut both sides of the “I2C” jumper on the qwiic buzzer to remove the pullups. If there are too many pullups, that can effect the reliability/functionality of the I2C message transfers.
Please let us know if any of these ideas work and thanks for your patience as we get to the bottom of this.
Meanwhile, I’m gonna dig up some hardware, and see if I can replicate the issue on my end.
-Pete
I will try that, thank you 
Might clean it with isopropanol, it is just dried flux I think. The issue is the same if I disconnect the cable on the buzzer that go to the other sensors, so it cannot be that.
I have no noticed the leds blinking 3 times fast, but it is blinking the duration of a buzz I sent it to do when I try to use it. When I mean 52 and 54, it is in dec, not in hex, and 52 == 0x34.
I already tried to only have the buzzer, same issue.
One thing that might help debugging: I think the issue appeared after I left the batteries (NiMH) plugged in the robot to a point where they were fully discharged. Could it have corrupted the eeprom/flash ?
The weird thing is that I send a 3 values to play a sound at each time: pitch, volume and duration, and looking at the code, the eeprom should not affect this. But I will do a reset and let you know how it went
