ADAU144x MP pin initialization glitch
Thread Summary
The user observed that the MP pins of the ADAU1445 pull high for ~100ms at power-on, causing issues in their application. The final answer indicates that the pins default to Hi-Z or input mode during initialization, and no control is possible until the program loads. A suggested workaround is to use a pull-down resistor or a transparent latch to manage the pin state until initialization is complete.AI Generated Content
Greetings!
I've been observing the MP pins of the ADAU1445. It seems that no matter what mode they're set to (in a program stored to EEPROM for self-boot), they always pull high for ~100ms when the device is powered on. That's somewhat problematic in our application, which uses one or more of these pins for delayed logic functions that can't have a 'false positive' at turn-on. A pull-down resistor is a band-aid option, but I wonder if there is any way to defeat this behavior in the first place?
Thanks,
Peter
Audio Signal Processors
adau144x
mp pins
adau1445
processors and dsp
SigmaDSP Audio Processors
Processors and Microcontrollers
Show More
Hello Peter,
I am pretty sure this is when the device is waking up and configuring etc. I can ask the designers and find out exactly what is going on so we can both understand the behavior and come up with a work-around. At power up they are either hi-Z floating or setup as an input. So it has to load in the register settings to make the pins be a GPIO output so during that period of time there would be no way to control the port until the booting is complete.
You may be able to setup a GPIO pin to enable a transparent latch or an analog switch to disable the output until the program starts running. Then it will change the GPIO pin to enable the other outputs.
I also have had this issue in some of my designs in the past where I was using a uC to drive LEDs and relays. When power is applied the uC ports all float high because they default to inputs. This made ALL the LEDs and relays turn on for a half second or so which causes quite a turn on surge. To solve this I simply had to change my design to make the "ON" state be a low out of the uC and "OFF" be a high out of the uC. This worked like a charm and since I had to buffer the output anyway I simply used an inverting buffer.
So I will ask around but I am pretty sure the answer is that it has to power up in a safe configuration of Hi-Z, or as inputs, and there is no control until the program is loaded and starts running.
Dave T
Thanks Dave,
That makes perfect sense that there must be some default initialization state that persists until the program is loaded and the MP pins can be set to their run-time mode. We noticed this phenomena because some of the pins are used as active-high LED drivers, which flash ON briefly when power is applied, just as you described. By trying various values of pull-down resistor and observing the resulting voltage, it appears that there is a pull-up current of 42.5 uA for a duration of 92 ms on each of the MP pins that I probed (I didnt' check 'em all, but I presume they behave the same). It would be nice if they simply went Hi-Z instead, but <50uA is relatively easy to swamp with a pull-down resistor, which I've added to the design (probably should have done so as a precaution in the first place!). Good thought on a workaround using a switch to disconnect the pin from its destination until initialized; I'll discuss that with my colleagues.
Do let me know if there's any other insights from the designers, and thanks for your quick reply!
Peter
HI Pete:
Let me look at the code to see if there is a way to preinitialized the code to avoid this problem.
Miguel
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
Please log in to reply.