Controlling Initial State of GPIO Output Pin

I remembered this exact issue - yet am surprised by its 6 year age.

May we assume this is not the intrusion of "WPD" (weak pull-down) via the PadSelect function?

Purely a swag - might your initializing that GPIO as, "Open Drain" - rather than "Push-Pull" - along w/deployment of an external pull-up R - eliminate that unwanted, "initial drive to low?"   Our firm uses ARM MCUs from many - I believe this "has" worked - yet I can't recall which vendor's MCU(s) accepted this method.  

Note that it was possible to (later) switch from Open-Drain to Push-Pull - w/that "drive to low" remaining suppressed.

Hi Amit,

Thanks for your quick reply.  We discovered this problem on an open drain output that IS pulled up.  We could NOT find a way to change the pin to an output without it driving low EVEN IF we set the data register to 1 before changing from an input to an output.  I decided to have my programmers check to see if they could change ANY GPIO pin to an output without it driving low and it does not seem possible - any write to the data register before the pin is configured to an output appears to be ignored.

I don't understand what you mean by, "break the pad configuration"?  The code we are using, and the code I originally posted is -

// processor boots up and pins are inputs....

.

.

   GPIOPinWrite(GPIO_PORTM_BASE, GPIO_PIN_3, GPIO_PIN_3) ;

   GPIOPinTypeGPIOOutput(GPIO_PORTM_BASE, GPIO_PIN_3);

As you can see above we are writing the pin to a 1 and then calling the library function to set the pin as an output, BUT at this point it is DRIVING low.  We also see this same behavior on another pin we are configuring as an open drain output.

NOTE, the library code for the function GPIOPinTypeGPIOOutput sets the Pad first and then sets the Dir.  I pasted it below -

GPIOPinTypeGPIOOutput(uint32_t ui32Port, uint8_t ui8Pins) {

    //

    // Check the arguments.

    //

    ASSERT(_GPIOBaseValid(ui32Port));

    //

    // Set the pad(s) for standard push-pull operation.

    //

    GPIOPadConfigSet(ui32Port, ui8Pins, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD);

    //

    // Make the pin(s) be outputs.

    //

    GPIODirModeSet(ui32Port, ui8Pins, GPIO_DIR_MODE_OUT); }

Does our code above look correct to you?  Can you post some sample code that you think works?  Thanks for your help,

Brett

Brett Preston said:

unfortunately, that order isn't very intuitive, but that just speaks to the fact this is a fairly complicated part.

"Isn't very intuitive" (to be extremely) kind.    You Sir, qualify as tech able AND a diplomat...   (some here would argue/propose that such critical tech data should replace the uber important, "Blogs, Groups, Videos" which imposes/infests itself (most always, unwanted) atop each forum page!)

Amit Ashara said:

Of course the ROM version shall be unavailable.  

And (of course) that's unfortunate.   Users - in the (hope) of saving (some) flash space:

• preclude themselves from any/all (flash) code updates, bug fixes & improvements
• soldier on w/"code current (only) when that ROM mask was created"
• find that "flash savings" is less than hoped for due to new "calling overheads" and the necessity to test to confirm that the function is resident w/in ROM

Yes the ROM (sometimes) giveth - yet it (too often) taketh away!

Might the "golden glow" of "ROM benefits" be entering the (same) "down-elevator" as the various "Code-Security Implementations - which never (really) protect?

Was it "just rumor" which reported an, "under-age/undocumented work crüe" - arriving earlier - resistors in hand - and then "scowling/departing?" And - do not most all "brand new boards" bear a full complement of "whoops" component additions & several, "correcting" wire tacks?