ADAU1701: unable to use MP8 as an input?
Hi,
My current SigmaDSP project uses four GPIO pins - MP2,3,8 and 9 - as digital inputs. Their read values are scaled and used to control various switches and multiplexers.
MP2,3 and 9 work perfectly. However, MP8 always reads as low. I have monitored it using the read/write window and there is no change when voltage is applied.
If I link MP8 to MP11 on the PCB and alter SigmaStudio to read MP11 instead, it works perfectly.
My input pins are pulled down by resistors, but I can see a small residual voltage from the internal pullups on all of them, so MP8 must be correctly configured as an input.
My initial thought was that the DSP must have been damaged during prototyping, or something similar, but I have built three prototypes and they all behave in an identical way.
Can anyone replicate this behaviour? Am I doing something silly (I never rule that out)? If it IS an "unintended feature", are any other pins similarly affected? It isn't actually a problem on this project (there are many other GPIO pins I can use), but I am worried in advance about my next project (quad micro-assisted ADAU1701s) where I need all the GPIO pins available.
Thanks and kind regards,
Steve L.
Audio Signal Processors
SigmaDSP Audio Processors
adau1701
Hi Steve,
I am working remotely today, so I have my laptop and SigmaStudio, but no hardware! So, I won't be able to try this out until Monday.
My first thoughts were "DSP Failure", but the fact that you have three boards behaving the same way is puzzling. I'm going to try it on my board on Monday, and if I'm seeing proper operation, maybe we can start by looking at your PCB schematics / layout.
Hi Steve,
Is it possible the MP8 pin configuration is not set to GPIO input in register 0x0821, what happens if you explicitly write the correct configuration in that register?
Hi awalshe and Brett,
Thanks for your replies.
Config reg 0x821 reads as all zeroes (i.e. all debounced inputs) using the read/write window and displays as such in the Hardware Configuration tab.
Explicitly writing the same value to it does not change the observed behaviour.
However...if I configure MP8 as an input without debounce, it works fine. With the input tied high, I can switch back and forth between debounced/non-debounced for MP8 and see the readback value change. I tried all the available debounce times to see if that made a difference but it does not - when debounced, the input permanently reads zero.
Would be grateful if somebody could confirm that they see the same behaviour.
Kind regards,
Steve L.
Hi Steve,
I was able to observe the behavior you describe. The MP8 input always reads low with the GPIO debounced setting. I think the best work around for now is the one you describe by making the GPIO no debounce. We will need some time to investigate this further here.
Best Rgds,
Alan
Is this issue resolved?
I have different ADAu1701 with different serial numbers with this same behaviour.
This question has been assumed as answered either offline via email or with a multi-part answer. This question has now been closed out. If you have an inquiry related to this topic please post a new question in the applicable product forum.
Thank you,
EZ Admin
I have actually run across this same issue and experienced the same behavior discussed previously.
Hello Cham,
Yes, this must be a silicon bug and the design team decided there was not enough reason to re-spin the part for a new revision. This was reported and discovered in 2011 and the part originally was released in 2007. So it would be VERY expensive to revise the part that long after release for a bug that has a work-around.
Not many people run into this because this pin is also used for I2S data and for the Aux3 pot so it is rarely used as a GPIO.
Sorry for the problem. Glad you were able to find this post.
Dave T
Hi Dave,
It's surreal that you're responding to this. I was watching your videos on YouTube to learn how to use the processor, haha. I hear what you're saying about respinning the part. I was hoping there was some software bug that could be fixed easily, but the workaround works well, I suppose.
Best,
Please log in to reply.