ADAU1467 driving outputs during programming?

Our design uses an ADAU1467.  In our software, MP19 is an output that drives the reset line of various peripherals in our circuitry.  During a debug session, we discovered that during the programming process, the bootloader code is deliberately driving MP19 low, which is detrimental to the behavior of our circuit.

Every uC, uP, and DSP I've ever used sets its GPIOs as inputs during programming, so I'm surprised at this behavior.  Can anyone explain to me what the bootloader code is trying to do by driving the GPIOs?  And is this behavior documented someplace?

This behavior manifests itself even if the boot memory has been erased and the system has been powered down (i.e. it's a blank slate).  HOWEVER... It only manifests itself on the first programming attempt after the programming header is plugged in.

  • 0
    •  Analog Employees 
    on Apr 6, 2021 5:30 PM

    Hello S. Mahnken,

    I looked at the datasheet for MP19. That pin is an SDATAIO assignable pin. So looking at the pin drive strength register I see that the pull-down resistor is active as a default. I think this is because it is an SDATA pin usually rather than a GPIO pin. So do you have a pull-up resistor on that pin? What value? The internal pull down will be really weak, around 150K. So it is easy to put in a stronger pull resistor. 

    I will alert some of the other Apps engineers who are directly responsible for this part to see if they have any more to comment. 

    Dave T

  • Thank you, Dave.  We do have a 10k pull-up on that pin.  In the o'scope captures we have, the pin is being pulled to GND hard, so I don't think the behavior is due to just the pull-down.  (We should end up with +3.1V if it was just the pull-down.)

    More detail (in case it helps) -- We are using MP19 to drive a simple N-Channel FET inverter circuit, the output of which is being used to drive the /RESET signal to the peripherals in our system.  So a high or float on MP19 results in the peripherals being held in reset, while driving MP19 low results in the peripherals coming on-line.  MP19 isn't connected to anything else.

    Any thoughts about why this behavior would only happen the first time you plug in the programming header?  I admit, it sounds fishy, but in our testing here, it's absolutely repeatable.  Our observations are that you don't even have to remove the power from the DSP.  Just unplug the programming header, then plug it back in, and MP19 will be grounded for about 40 uS during the first attempt at a memory erase or programming operation.

  • 0
    •  Analog Employees 
    on Apr 12, 2021 6:30 PM in reply to S. Mahnken

    I have not encountered this issue before. I can tell you about the state of the DSP out of RESET:

    • The MP19_MODE register default value sets the pin mode to its primary function and not a GPIO pin.
    • The SDATA3_3_ROUTE register disables the association of the pin with the serial port. It is neither an output nor an input.
    • The SDATAIO3_PIN register enables a pull-down resistor.

    To be honest, I have no idea why the decision was made to enable a pull-down on a tri-stated pin by default. That would not have been my first choice. Regardless, this seems consistent with the behavior you're seeing. When the DSP comes out of RESET, there is a pull-down, but the pin is not asserted low. 

    Are you asking why pin 69 is being asserted low for ~40uS while the DSP is being programmed, or is it while a EEPROM is being flashed through the DSP? These are very different. In the latter case, the programming utility loads a small "write through" DSP program that handles the writes on it's master port as the USBi communicates on the control port. This is only done during development, so the DSP pin states are undefined during this operation.

    The former case, just downloading a program to memory, is entirely possible to do without asserting anything. You can easily do it with your own uC. Without knowing where during the programming cycle the pin is going low, I'd only be guessing why our downloader is doing this (unnecessarily). This is not a normal operation use-case, however, and the behavior is undefined.

    If I understand correctly, the issue is that your peripherals are coming out of RESET for about 40 uS before RESET is asserted again, and this all happen only the first time programming after the USBi is connected. Can you explain why this is a problem in your product? 


  • In the field, our device must be removed from equipment in order to reprogram it.  It thus does not have access to external power.  So for a field reprogramming operation, we'd like to power the device from a USB dongle attached to a PC running SigmaStudio.  That gives our device a theoretical limit of 500 mA of current draw.  Such a limit is ample, provided we're only trying to run the DSP and its boot memory.  When the device's peripherals are pulled out of reset, the current draw spikes to over 3A, pulling down the power rail and causing our voltage monitor to reset the entire system.  This results in a programming failure.

    There is no external uC to assume the programming operation.  Nor is it feasible to provide external power.  Without the ability to guarantee that the GPIOs are either floating or configured as inputs (with or without weak pull resistors), field programmability will be very difficult to realize.

  • 0
    •  Analog Employees 
    on Apr 13, 2021 2:50 PM in reply to S. Mahnken

    Thank you for the context. I hadn't pictured this situation. Unfortunately, the SigmaStudio development team is unlikely to be able to look at this bug very quickly. I apologize for this, but I don't want to set unrealistic expectations. Below are some alternative solutions/mitigation that might work for you. I understand that these are suboptimal, but we need to enable field programmability somehow. 

    1. Click compile-link-download twice. This is not what you want to hear, obviously, but it might be an option in the short term.
    2. Try programming with a Total Phase Aardvark instead of a USBi. The programmer uses the same 10-pin header, and is supported in SigmaStudio. I don't know if this would behave any differently, but it would be a good data point in debugging, regardless.
    3. Build a small, self-contained programmer. For example, you could use the SPI port on a Teensy to write to the DSP's flash. These $20 uC boards have enough flash memory themselves to hold a few full '1467 programs, so they wouldn't need a PC or SigmaStudio once set up. You could connect the Teensy's USB port to any power source, and pass the 5V through to power the DSP. A ribbon cable and 10-pin header would allow the same connection to the target. A rotary encoder and I2C display, for example, could provide additional functionality if needed, such as selecting an image to download. I estimate that this project would take less than a day to get up and running. Each programmer might take a couple of hours to build if soldering by hand but much less with a very cheap PCB (no SMD). We can help with the code.

    The last idea has some advantages, such as removing reliance on SS, but the practicality depends on the number that would be required. How many field apps engineers, approximately, will be doing this programming? A few? Tens? Hundreds?