• State
  • Locked Locked
  • Replies 14 replies
  • Subscribers 31 subscribers
  • Views 614 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TAS5805M: Biquad equalizer not working

Vincent Hamp
Prodigy 30 points
Part Number: TAS5805M

Hello

I can't seem to get the 15x "equalizer" biquads in the TAS5805M amp to work. I've a otherwise working configuration header created by purepath which uses the "3-band DRC 96k" process flow. I then set the first biquad of both, left and right channel, to 50Hz low pass which should flatten my sound to... well mumbling mostly, yet everything plays just like without any filtering. The DSP_MISC register is set to 0x8E and I couldn't find any other register which would disable the biquads altogether. I can also read and write the biquads registers just fine when switching to book 0xAA, page 0x24. Again this seems to have absolutely no effect.

Also, one more question regarding the coefficient scaling. The process flow appnote (SLOA263A) mentions that coefficients B1 and A1 get halfed but I couldn't verify that using the purepath app. For example, a 50Hz low pass has an A1 coefficient of 1.995(and some...). The configuration header for this coefficient on the other hand contains the value 0x0FF6D114. This is exactly what A1 * (1<<27) is, where did the factor of 0.5 go? Following the appnote I would have calculated the register value as (A1 / 2) * (1<<27)?

Best regards

Vincent

  • 0
    TI__Genius 14480 points

    Hello Vincent,

    If you use any other other biquads like EQ2,3 etc are you seeing the same issue?

    Can you write this script and confirm if the behavior is the same.

    w 58 00 00

    w 58 7f 00

    w 58 00 00

    w 58 66 84

    best regards,

    Luis

  • 0 in reply to Luis Fernandes de Pina
    Prodigy 30 points

    Sorry for the delay, I've accidentally produced some magic smoke a couple of days ago and had to replace some parts... Face palm

    Anyhow. I assume with "write this script" you simply mean to attach those register writes to my current configuration? If so then no, I still can't here the low pass I've assigned.

    Meanwhile I've also tried to drastically simplify the purepath config and its thousands of register accesses... Here is what I currently write to the amp after boot up:

    write_reg(0x00u, 0x00u); // Page 0x00
    write_reg(0x7Fu, 0x00u); // Book 0x00
    write_reg(0x03u, 0x02u); // Hi-Z
    write_reg(0x01u, 0x11u); // Reset
    write_reg(0x03u, 0x02u); // Hi-Z

    delay(5u + 1u);

    write_reg(0x03u, 0x00u); // Deep sleep
    write_reg(0x46u, 0x01u); // Undocumented
    write_reg(0x03u, 0x02u); // Hi-Z
    write_reg(0x61u, 0x0Bu); // ADR as FAULTZ output
    write_reg(0x60u, 0x01u); // ADR is output
    write_reg(0x7Du, 0x11u); // Undocumented
    write_reg(0x7Eu, 0xFFu); // Undocumented

    write_reg(0x00u, 0x01u); // Page 0x01
    write_reg(0x51u, 0x05u); // Undocumented

    write_reg(0x00u, 0x00u); // Page 0x00
    write_reg(0x66u, 0x8Eu); // EQReg

    // B0-L coeffs
    write_reg(0x7Fu, 0xAAu); // Book 0xAA
    write_reg(0x00u, 0x24u); // Book 0x24
    write_reg(0x18u, 0x00u);
    write_reg(0x19u, 0x00u);
    write_reg(0x1Au, 0x01u);
    write_reg(0x1Bu, 0x51u);
    write_reg(0x1Cu, 0x00u);
    write_reg(0x1Du, 0x00u);
    write_reg(0x1Eu, 0x02u);
    write_reg(0x1Fu, 0xA1u);
    write_reg(0x20u, 0x00u);
    write_reg(0x21u, 0x00u);
    write_reg(0x22u, 0x01u);
    write_reg(0x23u, 0x51u);
    write_reg(0x24u, 0x0Fu);
    write_reg(0x25u, 0xF6u);
    write_reg(0x26u, 0xD1u);
    write_reg(0x27u, 0x14u);
    write_reg(0x28u, 0xF8u);
    write_reg(0x29u, 0x09u);
    write_reg(0x2Au, 0x29u);
    write_reg(0x2Bu, 0xA9u);

    write_reg(0x00u, 0x00u); // Page 0x00
    write_reg(0x7Fu, 0x00u); // Book 0x00
    write_reg(0x02u, 0x00u);
    write_reg(0x30u, 0x00u); // SDOUT is the DSP output
    write_reg(0x4Cu, 0x30u); // Digital gain -14dB
    write_reg(0x53u, 0x60u); // Bandwidth 175kHz
    write_reg(0x54u, 0x16u); // Analog gain -11dB
    write_reg(0x03u, 0x03u); // Play
    write_reg(0x78u, 0x80u); // Clear analog fault

    write_reg(0x00u, 0x00u); // Advise from TI audio forum
    write_reg(0x7fu, 0x00u);
    write_reg(0x00u, 0x00u);
    write_reg(0x66u, 0x84u);

    Can you spot something fishy?

    /edit

    Writing BQ2 or 3 didn't do anything either.

  • 0 in reply to Vincent Hamp
    TI__Genius 14480 points

    Hello Vincent, 

    Is this being done on your system or the EVM?

    best regards,

    Luis

  • 0 in reply to Luis Fernandes de Pina
    Prodigy 30 points

    This is our own design.

  • 0 in reply to Vincent Hamp
    TI__Genius 14480 points

    Hello Vincent,

    Is this issue replicated if you configure the EQ on another process flow or is it isolated to 3-band DRC 96k. I will try to verify this behavior in the lab tomorrow.

    best regards,

    Luis

  • 0 in reply to Luis Fernandes de Pina
    Prodigy 30 points

    Hello

    I guess. I have probably tried before but will do again tomorrow.

    The thing is... and correct me if I'm wrong... does it really matter?
    This "process flow" thing seems like a pure (no pun intended) GUI choice but not really something which matters to hardware? Sure, with specific settings only certain filters might be available to you but it's not like there's an actual "PROCESS_FLOW_CTRL" register in the amp. And even if there was, biquad filters should work one every of the 3 settings. Slight smile

    Best regards

    Vincent

  • 0 in reply to Vincent Hamp
    TI__Genius 14480 points

    Hello Vincent,

    Using a PPC3 configuration and applying the 50 Hz low pass i wasn't seeing the behavior you were observing. I additionally generated an output file and observed the same expected behavior. Can you provide the PPC3 file you are using to generate your process flow configuration so I can generate the proper header file.

    best regards,

    Luis

  • 0 in reply to Luis Fernandes de Pina
    Prodigy 30 points

    Sure, here you go

    https://www.load.to/Xvruuz17MX/tas5805m.ppc3

    Please note that I undertake two changes to the header generated with purepath to get my desired configuration:
    reg 0x53 -> 0x60
    reg 0x54 -> 0x16

    Not that it really matters though, I've tried leaving them both 0x00 as well. Sadly purepath doesn't seem to store any changes made to registers in the "Register Map" window.

    Best regards

    Vincent

  • 0 in reply to Vincent Hamp
    TI__Genius 14480 points

    Hello Vincent,

    So to clarify even with the full header file init sequence, prior to your modified script you were seeing the issue?

    Are you following the startup sequence as stated in the datasheet. Can you provide your startup waveform of PDN, DVDD, and PVDD? 

    When is I2S and I2C ready on your system?

    I used the PPC3 file and the generated header file on the EVM and could not reproduce this behavior.

    best regards,

    Luis

  • 0 in reply to Luis Fernandes de Pina
    Prodigy 30 points

    Yes the issue also occurs when writing the full (unmodified) sequence.

    From looking at our code I'd assume that the startup procedure is followed. It currently goes like this:

    - PDN is pulled high after the both rails (DVDD, PVDD) are stable
    - Then there's a 6ms delay before I2S is enabled
    - Another 6ms delay before I2C commands are sent from the purepath generated header
    - And yet another after the 5th register write after the device is put into Hi-Z mode


    I'm in HO today and don't have the PCB here, but I'll try to capture the waveforms next monday. Although I most likely won't be able to capture I2S because we no longer have pads for those signals. Disappointed

  • 0 in reply to Vincent Hamp
    TI__Genius 14480 points

    Hello Vincent,

    please provide the waveforms as soon as it is available. And to confirm this behavior is seen on multiple boards in your system? I cannot replicate this behavior on the evm. Is there an EVM you can connect to on the I2C bus on this system? Or another option would be driving the i2c bus on your system externally to see if it shows the same behavior. Were you seeing this behavior on previous builds of this board or is this the first step you used the tuning on your system.

    best,

    Luis

  • 0 in reply to Luis Fernandes de Pina
    Prodigy 30 points

    Here's how DVDD (red), PVDD (blue) and PDN (yellow) looks at startup. There is a 250ms delay between PVDD becoming stable and actually enabling the device by pulling PDN high. I2S is started 6ms after PDN is pulled high. I2C is already running at this point as there's an EEPROM we initialize and read from before.

    We do not own an EVM yet but we might consider buying one if this issue can't be resolved at all. We currently only have a single product were we use this amplifier. So far we haven't used any of the post-processing features but customers have approached us with the wish to make the filters available to them.

  • 0 in reply to Vincent Hamp
    TI__Mastermind 36550 points

    Hi Vincent

        Luis is looking into it, will reply you soon.

  • 0 in reply to Vincent Hamp
    TI__Genius 14480 points

    Hello Vincent,

    Were you able to obtain an EVM to confirm this behavior?

    best regards,

    Luis