TAS5805M: Current reduction when entering in Sleep, Hiz and Deep Sleep Modes is less than expected

Hello Juan,

Can you provide the script where the customer is trying to enter the device in hi-z/sleep modes.

Best regards,

Luis

Hi, Luis.

I follow the procedure described in 9.4.5 Device State Control of the TAS5805M datasheet:

Enter/Exit in Sleep Mode:

w 5A 00 00 #Go to page 0
w 5A 7f 00 #Change the book to 0x00
w 5A 03 01 #Change the device into Sleep Mode
----------------------------------------------
w 5A 00 00 #Go to page 0
w 5A 7f 00 #Change the book to 0x00
w 5A 03 03 #Change the device into Play Mode

Enter/Exit Hiz Mode:

w 5A 00 00 #Go to page 0
w 5A 7f 00 #Change the book to 0x00
w 5A 03 02 #Change the device into Hiz Mode
----------------------------------------------
w 5A 00 00 #Go to page 0
w 5A 7f 00 #Change the book to 0x00
w 5A 03 03 #Change the device into Play Mode

Enter/Exit Deep Sleep Mode:

w 5A 00 00 #Go to page 0
w 5A 7f 00 #Change the book to 0x00
w 5A 03 02 #Change the device into Hiz Mode
w 5A 03 00 #Change the device into Deep Sleep Mode
----------------------------------------------
w 5A 00 00 #Go to page 0
w 5A 7f 00 #Change the book to 0x00
w 5A 03 02 #Change the device into Hiz Mode
w 5A 03 03 #Change the device into Play Mode

Regards,

Juan Pablo Novo

Hello Juan,

When you readback the registers do you see it correctly updates.

I will collect some data on the EVM by tomorrow.

Best Regards,

Luis

Hi, Luis.

Yes, when I readback the DEVICE_CTRL_2 Register (0x03) after writing the new state I get correct values. And while in Sleep, Hiz and Deep Sleep Modes I don't get audio in speaker, so it seems not to be in Play Mode as expected.

But I have notice something strange while reading the POWER_STATE Register (0x68): When I return to Play mode (from any other state) this register shows 0x02 (Hiz) instead of 0x03 (Play), although I get audio in the speaker and all seems to work Ok. When I change to Sleep, Hiz or Deep Sleep Mode, this register shows correct values.

---------------------

Edited:

POWER_STATE Register (0x68) shows correctly 0x03 value while in Play Mode when I start clocks and send audio thought SPI.

So I suppose TAS5805M enters automatically in Hiz Mode while I am not playing audio and keep clocks stopped.

That explain why there is no current reduction when I force entering in Hiz Mode: TAS5805M was already in Hiz mode!

And that also explains the low current reduction when entering in Deep Sleep Mode: From Hiz Mode to Deep Sleep Mode the current reduction should be about 10mA. Although I get only 7mA, it makes more sense now.

But this 3mA gap that exists from expected current reduction value when it changes from Hiz to Deep Sleep Mode, is the same 3mA gap that should occur (and doesn't) when going from Hiz to Sleep Mode. This is the only thing that remains unexplained...

Perhaps, TAS5805M actually is in Sleep Mode while no clock are on, although POWER_STATE Register shows Hiz Mode?

Regards,

Juan Pablo Novo

Hello Juan,

Can you try using the state control in the TAS5805 GUI as highlighted in this and redo the current measurements for the different states. It should be more inline for your expectations in current reductions.

Best regards,

Luis

Hi, Luis.

I have just test changing the state from the GUI and the results are the same as if I change it programming with the MCU or switching the registers directly with PPC3 via PC:

a) From auto Hiz Mode to Sleep Mode: 0mA

b) From auto Hiz Mode to Deep Sleep Mode: 7mA

I have tried it in both devices (A and B) with same results.

In your tests do you see a current reduction changing from Hiz to Sleep modes?

Regards,

Juan Pablo Novo

Hello Juan,

When i tested on the EVM, where PVDD is powering the whole system. I saw an overall 6mA current reduction from HiZ to Sleep mode, which would be ~3mA reduction for each TAS5805M.

Best regards,

Luis.

Hi, Luis.

I have been doing some more tests with interesting results. See attached spreadsheet: Current measurements.xlsx

The basic setup is the same as stated in my first post. Additionally Device A of the EVM is kept in Deep Sleep Mode in all tests.

I will try to explain some aspects of the table but ask me anything you find difficult to understand:

- I2S Clocks:

• Ready before init: Yes, when I start I2S clocks before TAS5805M initialization. No, when I start clocks after TAS5805M initialization.
• Active: Always, when I2S clocks are running continuously. While playing, when I2S clocks are normally stopped and are activated only while playing the audio.

- TAS5805M initialization: PPC3, when I enter Tuning and Audio Processing in PPC3 and it initializes the EVM. '.h dum file', when I use the header file generated by PPC3 Dump Current State option in the CC1310 program.

- Mode changes by: PPC3 (Tuning GUI and registers), when I change the TAS5805M modes manually through the PPC3 interface. CC1310 programming (I2C), when I change the TAS5805M modes through CC1310 program using I2C.

- Play (no audio) current measurement: First, while in Play Mode with no audio and before any audio output. Rest, while in Play Mode with no audio but after some audio played. In comments I explain that it is possible to return to a low Play (no audio) current state if mode is changed to Sleep/Deep Sleep and back to Play again.

I have included some cases with I2S clocks not ready before initializing because it was my starting setup: I only started clocks just before starting playing audio and stopped them just after stopping audio.

In all cases audio is played and listened at the same volume with no problem other than the OC fault that triggers in some of them.

In each case I have highlighted some facts I think related:

- Case 3, 5 and 7: If I2S clocks are not ready before the TAS5805M initialization sequence begins, there is a very big increment of the current drawn while playing audio. Moreover, that current is drawn continuously after the first audio played while in Play Mode although there is no audio playing actually. The only way to return to a low current state is to change from Play Mode to Sleep or Deep Sleep Mode and then go back to Play Mode. Hiz Mode is not an option because, after going back to Play Mode, the current drawn is the same high current.

- Case 8 and 10: Using the header file dumped by PPC3 to initialize TAS5805M though CC1310 has the same effect as if I2S clocks were not ready before the initialization although I have made sure the clocks were running before the initialization.

- Case 3: With fs auto mode and the I2S clock not running before TAS5805M initialization, an OCP triggers every time there is a mode change from Deep Sleep to Hiz or from Hiz to Play.

- Case 4, 6 and 9: Setting manually fs and BCK ratio instead of auto, produce a current drawn reduction while in Play Mode.

- Case 5: Setting manually fs and BCL ratio instead of auto, manages to avoid OC faults like in the Case 3

- Case 6, 7 and 8: When changing modes by programming with CC1310, a minimum delay of 30ms between Deep Sleep and Hiz modes is needed to avoid an OC fault. When manually changing between modes using the PPC3 GUI (cases 1-5) I think it is not apparently needed because the time used to click into the options is bigger.

- Case 9 and 10: If I2S clocks are activated only while playing, the OC fault only can be avoided if the delay is over 12s. Moreover, there is no difference in the current drawn between Sleep and Hiz modes (it is like if while no I2S clocks are running Hiz Mode is the same as Sleep Mode)

The results make me think that all issues I have reported are related: "Over Current Channel Fault when playing audio after exiting Deep Sleep Mode" and "Over Current Channel Fault when using Process Flow 3-Band DRC & FIR (1.0 48k) while not providing fs and BCK ratio manually"

The cases I need to make them work are 8 and 10, as I need to make TAS5805M be initialized by CC1310. Case 10 should be better because it has less power consumption, but case 8 could work too as my power source will not be a battery.

In both cases I need to resolve the initialization problem. It seems like the header file generated by PPC3 does not have the same initialization sequence that PPC3 uses by its own when entering in Tuning and Audio Processing GUI. That makes a very big increment in current drawn while in Play Mode in both cases and the OC fault in the last case. I need them work as case 6: low current drawn in Play Mode and no OC fault. Could you help me to get this?

Regards,

Juan Pablo Novo

Hello Juan,

Can you upload the PPC3 file you are using to initialize your device/generate your header dump file. It will be helpful so I can correlate the results. Also what signal/output power is for the conditions play(with audio) in your table.

Best Regards,

Luis

Hi, Luis.

I have attached a ZIP with next files inside:

• 0000.wav: Audio file used under play condition
• Ampli - Modified startup sequence.h: Header file generated by PPC3 dump file utility modified with the suggested start up sequence to try to avoid OC faults
• Ampli - Original startup sequence.h: Original header file generated by PPC3 dump file utility
• AVJDS_flujo2.ppc3: PPC3 file with the setup used for the tests (as you probably know you must set fs and BCK Ratio manually through the Register Map page as there is no option to set this through the Tuning and Audio Processing page and then it is not saved in the PPC3 file)

Test files.zip

I have tried with both headers files with same results.

I have not set a power objective for the tests, just played the audio test file with these gains (already set up in PPC3 file):

• Analog Gain = -4dB
• Digital Gain = 0dB
• DAC Gain = -20dB

Regards,

Juan Pablo Novo

Hello Juan,

• What would be the expected output power you are seeing with the Play(with audio) condition with that audio file given your gain configuration.
• Also when the I2S signal is off(when audio is not playing) what state do you have the device in, deep sleep/sleep/or hi-z.
• What are you writing to the device on i2c when you enable the i2s clocks again to play audio.
• In your .h dump file do you see the current spike when in both the original and the modified where you introduce the delays from my previous suggestion.
• For your mode changes can you post the i2c scripts you are writing

Best Regards,

Luis

Hi Luis.

• What would be the expected output power you are seeing with the Play(with audio) condition with that audio file given your gain configuration.

With Analog Gain=-4dB and Digital Gain=DAC Gain=0dB, I expect 40W. So the tests with DAC Gain=-20dB should be 0.4W

• Also when the I2S signal is off(when audio is not playing) what state do you have the device in, deep sleep/sleep/or hi-z.

When audio is not playing I have tested every state. You have in the sheet the column Current measurements (mA) in each state: Play (no audio), Hiz, Sleep and Deep Sleep

• What are you writing to the device on i2c when you enable the i2s clocks again to play audio.

In cases 9 and 10 (the only ones not running clocks always):

# Before stopping clocks after playing audio
w 5A 00 00 #Go to page 0
w 5A 7f 00 #Change the book to 0x00
w 5A 03 0A #Change the device into Hiz Mode and mute
--------------------------------------------------------
# After starting clocks before playing audio
w 5A 00 00 #Go to page 0
w 5A 7f 00 #Change the book to 0x00
w 5A 03 03 #Change the device into Play Mode and unmute

• In your .h dump file do you see the current spike when in both the original and the modified where you introduce the delays from my previous suggestion.

When initializing with .h dump file (cases 8 and 10), I see OC faults with both files in both cases. In case 8 it is prevented just waiting al least 30ms when changing from Deep Sleep to Hiz. In case 10 it can't be prevented with a small delay.

• For your mode changes can you post the i2c scripts you are writing

Enter/Exit in Sleep Mode:

w 5A 00 00 #Go to page 0
w 5A 7f 00 #Change the book to 0x00
w 5A 03 09 #Change the device into Sleep Mode and mute
----------------------------------------------
w 5A 00 00 #Go to page 0
w 5A 7f 00 #Change the book to 0x00
w 5A 03 03 #Change the device into Play Mode and unmute

Enter/Exit Hiz Mode:

w 5A 00 00 #Go to page 0
w 5A 7f 00 #Change the book to 0x00
w 5A 03 0A #Change the device into Hiz Mode and mute
----------------------------------------------
w 5A 00 00 #Go to page 0
w 5A 7f 00 #Change the book to 0x00
w 5A 03 03 #Change the device into Play Mode and unmute

Enter/Exit Deep Sleep Mode:

w 5A 00 00 #Go to page 0
w 5A 7f 00 #Change the book to 0x00
w 5A 03 0A #Change the device into Hiz Mode and mute
w 5A 03 08 #Change the device into Deep Sleep Mode and mute
----------------------------------------------
w 5A 00 00 #Go to page 0
w 5A 7f 00 #Change the book to 0x00
w 5A 03 0A #Change the device into Hiz Mode and mute
d 40 #Delay 40ms
w 5A 03 03 #Change the device into Play Mode and unmute

I am quite sure I am doing the mode changes well, as in case 6 every thing works well. Things get twisted when initializing through the .h dump file (instead of the PPC3 internal initialization) and/or when not playing I2S clocks continuously.

Regards,

Juan Pablo Novo

Hello Juan,

Can you use this sequence for your deep sleep to play toggle and see if you see the same issue with the OC fault

w 58 00 00 #Go to page 0
w 58 7f 00 #Change the book to 0x00
w 58 03 02 #Change the device into Hiz Mode
w 58 03 00 #Change the device into Deep Sleep Mode

w 58 00 00 #Go to page 0
w 58 7f 00 #Change the book to 0x00
w 58 02 00 #change to bd mode
w 58 03 02 #Change the device into Hiz Mode
w 58 02 02 #change to hybrid mode
w 58 03 03 #Change the device into Play Mode

Also before you halt I2S you should go from play to deep sleep mode and wait 6ms before you stop the I2S signals. When you re-enable I2S signal you wait wait 9ms before you go from deep sleep to play.

Best regards,

Luis

Hi, Luis.

I have tried with next code as I use 384K and PBTL:

w 58 00 00 #Go to page 0
w 58 7f 00 #Change the book to 0x00
w 58 03 02 #Change the device into Hiz Mode
w 58 03 00 #Change the device into Deep Sleep Mode

w 58 00 00 #Go to page 0
w 58 7f 00 #Change the book to 0x00
w 58 02 14 #change to bd mode (384K and PBTL)
w 58 03 02 #Change the device into Hiz Mode
w 58 02 16 #change to hybrid mode (384K and PBTL)
w 58 03 03 #Change the device into Play Mode

I have tried this with case 8 (non stopping I2S clocks) and the OC fault rises again if I don't wait the 30ms after switching Deep Sleep to Hiz. Nothing changes here.

And I have tried this again with case 10 (stopping I2S clocks when no audio is played) and the OC fault rises again if I don't wait 30ms. But now I don't need to wait more than that: not the 12 seconds needed before!!!

Even more, I have tested that I don't need to stop clocks being in Deep Sleep mode as you suggested as a possible requirement. I can do it also being in Hiz. So I can use Hiz as the chosen mode while not playing audio during some little time, and reserve Deep Sleep mode only for when I need a real standby state in my device after a bigger time of inactivity. The trick is the BD/Hybrid change when exiting Deep Sleep mode you exposed.

I can assume a 30-40ms delay when leaving Deep Sleep so this solves the problem of OC Fault after exiting Deep Sleep mode while stopping the I2S clocks when not playing audio. Thank you!

Now the only but critical problem that remains is the TAS5805M initialization by the .h dump file which makes the abnormal current consumption while playing (400mA) in cases 8 and 10 compared to the PPC3 direct initialization (140mA) in cases 6 and 9. Have you discovered anything about it?

Regards,

Juan Pablo Novo

Hello Juan,

In your startup sequence the 400mA case you have the I2S clocks running before running I2C, i'm unable to replicate the abnormal current consumption. Can you provide a waveform of your startup sequence.

best regards,

luis

Hi, Luis.

I have attached a ZIP with the binary files from the oscilloscope (SCL and SDA).

I2C init waveform - bin.zip

This is the link to the SW to read Promax OD-624 oscilloscope files. I don't know if you have another viewer, but the SW from Promax is nearly useless as it takes an enormous amount of time to refresh any setting change while viewing.

I have also the CSV files but they are 58MB zipped...

I have also tried to record the I2C commands from the I2C Monitor of PPC3 while in-system debugging, but it doesn't seem to be able to record the I2C commands sent by CC1310, only seems to be able to read the TAS5805M registers and record I2C commands from the PPC3 itself.

Regards,

Juan Pablo Novo

Hello Juan,

I am unable to view the files you posted. In regards to the high current draw, I only see the higher current draw in the case where the I2S clocks are not present during I2C initialization. If you have the I2S clock ready when you are writing I2C and are still seeing this issue there must be an issue with the device that is driving the I2C bus so please confirm with a digital analyzer it's working properly and matches what you expect in the initialization Code.

If you are still having issues, please respond the the email thread you have previously started with me.

Best Regards,

Luis