Post Go back to editing

ADAU1401 Value Hold odd behavior

Category: Software
Product Number: ADAU1401
Software Version: Sigma Studio Automotive 4.7 x64

Hello,

I'm seeing an odd issue with the Basic DSP Function called Value Hold.

Below is the SigmaStudio schematic; the area of interest are the red outlined Value Hold components, and the DC component in blue outline, that controls them.

(As an aside, my ultimate aim in doing that is to freeze the values, so that I can read them multiple times with different subtracted integers (this is an attempt to gain higher resolution out of the Readback function for the ADAU1401 - I think it is successful in that respect, but the issue occurs even without this).

From the controlling computer, I issue an I2C command to set the DC level to zero, to hold the values, and then I read them a few times, and then I set the DC level to 1 in order to release the hold. I do this repeatedly (perhaps once a second). What I see is that the values go nuts. Here is my pseudocode:

for (i=0; i<100; i++) {

    set_dc(DC1_4, 0); // set to zero, to hold the value

    a=readback(Readback1_5);
    b=readback(Readback1_6);

    set_dc(DC1_4, 1); // set to 1, to release the hold
    print("values are [{a}, {b}]");
}

When I run the above code with the set_dc commands commented out (i.e. no hold functionality), I see stable measurements like this:
values are [0.03828430, 0.04812813]
values are [0.03148270, 0.04825974]
values are [0.03146172, 0.04825974]
values are [0.03146172, 0.04825783]
values are [0.03146172, 0.04825592]
values are [0.03146172, 0.04825592]
values are [0.03145981, 0.04825401]
values are [0.03145981, 0.04825401]
values are [0.03146172, 0.04825401]
values are [0.03146172, 0.04825211]
values are [0.03145981, 0.04825211]
values are [0.03145981, 0.04825211]
All values above are in the ballpark I expect, I expect only a little noise, and the values are correct.
When I run the code with the set_dc commands present (i.e. hold is enabled, values are read, then hold is disabled) I see this (see the fifth line onward to see the discrepancy):
values are [0.03147888, 0.03598213]
values are [0.03147697, 0.03598404]
values are [0.03147888, 0.03598404]
values are [0.03148079, 0.03598404]
values are [0.03147888, 10.40721512
values are [0.03147888, 10.15365219
values are [0.03147697, 10.15165138
values are [0.03147888, 9.64481544]
values are [0.03147888, 9.39127922]
values are [0.03147888, 9.38917542]
values are [0.03147888, 8.88223457]
values are [0.03147697, 8.62869835]
values are [0.03147888, 8.62672424]
values are [0.03147697, 8.11983490]
values are [0.03147697, 7.86619568]
values are [0.03147888, 7.86419487]
values are [0.03147888, 7.35733223]
values are [0.03147888, 7.10379791]
values are [0.03147697, 7.10184860]
values are [0.03147697, 6.59488106]
As you can see, the value shoots high, and then gradually drops. It seems to randomly occur, and quite frequently, I'll see it within 10 or so measurements, and it will occur many times. I can't see why doing a value hold should cause that : ( 
I've tried things like (say) reading twice before and after the value hold and unhold operations, in case one value needs to be flushed out of the system or something, but it doesn't fix it. I cannot find a way to use the Value hold successfully. I have also tested with SigmaStudio 4.6, and the issue is there too.
Is this a bug? If so, any possible workaround? I've tried using a Switch to control the Value Hold, and the same issue occurs. I can't think of what other component to use to perform a similar hold-type function. There is a different function called Advanced DSP Sample and Hold, but there's no documentation for it, and clicking the checkbox for the component doesn't seem to hold a value.

Any help would be appreciated. Apologies if I'm making a silly error - I'm still fairly new to SigmaStudio.

Many thanks!

Edit Notes

Tidied the code formatting
[edited by: shabaz at 12:40 AM (GMT -4) on 10 May 2022]
  • Hello, 

    I think the issue is resolved. It appears that the 'DC Input entry' is quite sensitive, it needs safeload. Once I used safeload for all DC input entry blocks, the problem disappeared. The problem persisted until I replaced all DC entry blocks in the screenshot above.

    Still, it was a strange symptom, I think it's interesting way the problem exhibited itself, with the spikes in values that gradually dropped over multiple reads.