LM48560 Register Setting Changes "On-the-Fly"

Hi Chris,

Welcome to E2E

The LM48560 does not support multiple register write sequences. Writing to device registers must be made one register at a time.
The changes can be made on the fly but these must be made one after another.

Best regards,
-Ivan Salazar
Texas Instruments

Hi,

Some things to check...

Obvious one first; you have pull-up resistors on both the SDA and SCL lines? If not, bad things are going to happen...

You are waiting for the ACK before continuing to send data? If it's not ACK'ing (like in "Mars Attacks" - ACK-ACK)...

Slow everything down... I've found some TI devices (I won't mention which in polite company) don't like max speed on I2C. Slow things down and see how it performs. 

Good luck.

Mike T.

Hi Mark,

Thanks for the reply.  We do have pull-up resistors on our I2C bus and know it is functioning correctly.  The LM48560 shares the bus with our radio and it is properly functioning streaming audio data.at around 363 kHz.  The writes to the LM48560 are scheduled and interleaved between transactions from the radio.

I have verified that the I2C transactions are being received by the LM48560 using both a I2C bus monitor as well as a logic analyzer.  The slave address and register address + data that follow are ACK'ed as expected, and no transactions are shown in error.  The correct registers and data and shown on the bus monitor.

There are about 350 us between the two I2C transactions according to the bus monitor.  There is are proper stop and start conditions in between transacitons.  I've also tried to add up to a 3-5 ms delay between the two register writes, but that does not work either.  Even tried writing the registers twice, and also reverse order, but neither has an effect on changing the result.

Our current implementation of the LM48560, we 'set it and forget' to a configuration of boost enabled and 21dB during bootup.  The only difference now is we need to switch between boost enabled + 21dB and boost disabled+18dB while audio is on-going.  There is no audio during boot.  

We are using the same code to set up during boot as the code we're using to setup on the fly.  It's the exact same function.

I will try slowing down the bus for the I2C transactions to the LM48560, and then speed up for our radio.  Will update tomorrow.  Not sure if this will change anything because the LM48560 already functions at boot operating at the 363 kHz speed.  The only real difference is the ongoing audio.

Thanks,

Chris

I know how this sounds before I say it... have you tried stopping the audio, sending the code and starting the audio again? You *shouldn't* hear the drop out in audio. This will tell you (though so will a scope) whether the audio isn't corrupting the data. 

MIKE T.

It sounds like you guys are on top of things; I know how frustrating these things can be. If you don't mind me asking, are you really driving "ceramic speakers, piezo"? The reason I ask is I have a fair amount of experience with "piezo benders" used as "speakers". I am the guy that invented the "singing balloon" you might find at Party City, etc. called "Sing-A-Tune" balloons. The original version of this used a custom double-sided "bender" as they say, in a custom "enclosure I designed. There's been about 10 million of them produced to date (though the newest version uses a small flat speaker; the price of piezo elements has gone up substantially since the inception of that device). I also know a bit about audio "stomping" on digital streams. To that point...

I'm sure you guys have put a scope on the digital lines to see if the audio is effecting the stream? If you can set all the things you want with the audio off, and not when it's on, then perhaps it's a board layout issue. These kinds of things are my "specialty" (www. scarydesign .com - remove the space, with them in it's doing weird things).

Or perhaps its power supply. I worked on a battery operated "sound device" years ago in which the device was turned on/off by RF remote. When it was playing, the audio was modulating the power supply rail, making it so the device would turn on, but not off. A simple way to test this is to put a big cap, bigger the better right at the power input to the board. If possible, a big cap for Cs as well. See if that helps things.

I'm intrigued, and hope you get this worked out.

Mike T. 

Hi Ivan,

Thanks for the reply.  I also just figured this out 5 mins ago.  

Very strange result through.

It appears that if all three registers are written, then the behavior works as expected. If only registers 0 and 2 are written, then the behavior is as previously described.  We don't make any changes to the no-clip register 1, but we just rewrite it anyway.

It doesn't make any sense why this is the case.  I was thinking it could be a timing issue, but I also previously tried a large delay of several ms between the two writes, and that did not work.  Or it could still be the bus speed being too fast for the LM48560.

In any case moving forward with this approach.  

Thanks for checking for us.

Thanks,

Chris