Issues with BV4627-B

I'm working on a project using an Arduino Micro and a BV4627-B, communicating over i2c. Had everything successfully prototyped on a breadboard, and then successfully made a custom PCB for some of the additional circuitry. Put the BV4627-B aside for a while and worked on the rest of the project in isolation.

I've now come to plug the BV4627-B back in and it just seems.... dead. The bv4627 library hangs when trying to do something simple like bv4627.deviceid(). With the board removed calls to functions at least are non-blocking and don't prevent the execution of the code.

Things I have tried

- Running a simple i2c scanner to see if anything is listening. Nothing.
- Removed the BV4627-B, wired a simple RTC into the i2c bus. Run the i2c scanner. Finds it immediately.
- Prototyped a simple circuit to talk to the BV4627-B over the binary interface - sending a 1Hz digital signal to A0. Nothing.

Any suggestions for what I might try debugging next before I give up and accept that I must have damaged the BV4627-B in storage somehow and need to buy a new one?

Thanks in advance, still a bit of a beginner at this.

James

James,
as I understand it you have lost communication to the bv4627 via I2C. I would not trust the binary prototype unless it was working before as there are too many variables to go wrong it is not possible to say that the interface is working or not.

There seems to be no reason not to doubt the I2C master on the hardware side and the software was working before so I have a couple of suggestions.

1) Make sure there are pull up resistors on the I2C lines about 5k
2) Do a factory reset.
This should be but is not documented in the data sheet so:
1) remove power
2) short pins 3 and 4 [*]
3) apply power
4) remove power
5) remove short

[*] There is a row of 5 holes to near relay H, marked JP2. The square pad is pin 1
Let me know how you get on
Jim

Jim,

Thanks for the tips. I shorted out pins 3 and 4 and followed your process, then plugged the board back into the project and it's working again. Do you know what can cause this issue? Is it worth me wiring a switch across those pins so I can short them out when the board is in situ without taking it out (it'll eventually be in the dashboard of my car)?

I also noticed that the bv4627.deviceid() function in the library doesn't return the correct result unless I've waited around 1500ms after my sketch starts.

Thanks once again,

James

James,
its nearly always caused by power supply noise which disrupts the EEPROM contents that hold the i2c address and thus communication stops. I have no direct evidence but think this occurs on switch on. A large capacitor (1000uF 16V) on the power line at the entry to the device would help.

I can supply the firmware with a fixed I2C address which would also eliminate the problem but you would need a pic programmer, or send it back and I can do it from here.

Jim

Thanks. I've been powering the project through a OKI-78SR switch-mode power supply (currently the input is a benchtop power supply, but eventually the much noisier environment of output of the car's alternator). I'll keep an eye on things and if I get issues again I'll look at improved filtering of the output from the power supply.