Post Go back to editing

ADM6316 !MR Input

I'm using an ADM6316DZ26ARJZ-R7 on a new board I've designed and it's not behaving as I exptected.

Background...

The board is for a voice communications product that is solar powered and is installed in relatively remote areas.

It's important the board operate reliably and recover automatically from 'glitches' or be forced to recover by a 'host' or companion processor (in the form of a GSM/3G wireless module for this product) ..... I wanted the MCU to be able to force a complete power cycle of itself and associated circuitry if it determined some peripheral device wasn't responsive or if requested by the host device.

I've set it up so the watchdog input is driven by an I2C port expander so if I have an I2C lockup, the watchdog won't get polled and the ADM6316 reset output will disconnect power from the MCU subsystem for > 1 second allowing things to restart.  I have other devices on the I2C bus that must be contactable at all times.

I also wanted an instant power cycle option so I connected one of the MCU pins to the !MR input (via 1k resistor).  I have an external 100K pullup and the MCU at reset configures all IO pins as high Z inputs.  The ADM6316 also has approx 60k pullup on !MR.

The problem...

With this configuration, as soon as power is applied, the ADM6316 Reset output is asserted (ok).  I then see activity on the !MR input that looks like data (but can't be) - the input toggles between being high (approx 2.8V) and low (0V) for a while then stops pulsing and returns high.  The Reset output stays asserted the entire time.  If I tie the !MR input to 2.8V, the Reset line de-asserts.  If I remove the connection between the MCU and ADM6316, the device operates properly.  I watched the MCU pin while the !MR input was pulsing and there was no activity at all - it remained at 2.8V (logic supply rail).

It's not critical that I have an instant power cycle option but I would like to know what's going on.

Thanks in advance

Craig

  • Hi Craig,

    I'm not sure exactly what's going on here either but I've added a few suggestions for debug below. Sounds like the problem must be related to how you're pulling up the MRb pin externally or how the MCU is driving the MRb pin.

    When you say you have an external 100k pullup on the MR pin is this pullup to Vcc of the ADM6316 or to some other rail? If it's some other (sequenced) rail is it possible that it's going low in reset and fighting the internal pullup? Is the behaviour the same when you remove the external pullup?

    How about the MCU pin when the MCU comes out of reset - you said it's high Z when the MCU is in reset but what about after reset? If the MCU pin is connected directly to the MR pin (through the 1k resistor) how is the MCU pin staying high while the MR pin is toggling?

    You say that the MRb pin stops pulsing after a while and goes high. Does the reset go high ~1.12secs later or does it stay low? Not sure why the ADM6316 wouldn't come out of reset once the MRb pin is high for 1.12secs.

    Is the MR pin coming up with Vcc? How long after this does it start toggling and what frequency is it toggling at? I'm wondering if the ADM6316 is coming out of reset briefly after 1.12secs but the MCU pin is causing another reset immediately on MRb. Is the MRb pin toggling at 1.12secs?

    When you disconnect the connection between the MCU and the ADM6316 is there any activity on the MCU pin on powerup?

    Sorry for all the questions! I'm just trying to think of all the things that could be going wrong. Is it possible to get a plot of the different signals after powerup?

    Thanks,

    Paul

  • Hi

    Thanks for the suggestions.

    I seem to have fixed the problem.  I'm not sure what was happening with the PIC24 IO pin during power up but it seems to have been pulsing the MR input low at some point.  I have changed the pullup to a much smaller value (1K) so it needs a few mA to pull low.  I also changed the initialisation of my control pin to be an open drain output and made sure it was set high before changing it from input to output.  The board now boots without me having to remove any components which is a much more pleasurable experience.

    I'm still confused why I was getting resets when the PIC was not programmed at all.  One of those great mysteries of science I guess.

    Regards,


    Craig

  • Hi Craig,

    Glad the issue is sorted. As you say sometimes just explaining the problem to someone else helps.

    Rgds,

    Paul