This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Establishing GPIO immediately after power up in Boot Loader

Other Parts Discussed in Thread: TM4C1294KCPDT

Hello,

I work with TM4C1294KCPDT Microcontroller

In Boot Loader I need to turn off certain GPIO pin immediately after power up.

In Reset Vector I moved my function call to the first place to be performed, but still visible a light blinking of peripheral that connected to this GPIO.

Here is related Boot Loader code:

#define BL_HW_INIT_FN_HOOK      GPIO_WLS600_Configure

.thumbfunc ResetISR
ResetISR: .asmfunc
    
    ;; Call the user-supplied low level hardware initialization function
    .ref    BL_HW_INIT_FN_HOOK
    bl      BL_HW_INIT_FN_HOOK

    ;; Enable the floating-point unit.
    movw    r0, #0xED88
    movt    r0, #0xE000
    ldr     r1, [r0]
    orr     r1, r1, #0x00F00000
    str     r1, [r0]

    ;; Initialize the processor.
    bl      ProcessorInit

void GPIO_WLS600_Configure()
{
	// init and turn laser GPIO off
	ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOC);
	ROM_GPIOPadConfigSet(GPIO_PORTC_BASE, GPIO_PIN_7, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD_WPU);
	ROM_GPIOPinTypeGPIOOutput(GPIO_PORTC_BASE, GPIO_PIN_7);
	*((volatile uint32_t *)(GPIO_PORTC_BASE + 0x3FC)) |= GPIO_PIN_7;	// invert logic

	// init Heartbeat LED
	ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOM);
	ROM_GPIOPinTypeGPIOOutput(GPIO_PORTM_BASE, GPIO_PIN_6);
	MAP_GPIOPadConfigSet(GPIO_PORTM_BASE, GPIO_PIN_6, GPIO_STRENGTH_12MA, GPIO_PIN_TYPE_STD);

	// Default the LED to ON.
	ROM_GPIOPinWrite(GPIO_PORTM_BASE, GPIO_PIN_6, 0);
}

I looks like processor does not sets the value in time.

How can I get rid off GPIO slow response on power up?

Sergey

  • If this issue is confined to your bootloader operation - does that occur with enough frequency to (really) justify such speed-up?

    Most MCUs have bit delayed response, "coming out of reset" you may have to "gate off" that GPIO by external means until the MCU has fully "launched."    (we've past done that via external - non MCU based HW - which "escapes" any/all such MCU reset issues)

  • I specifically chose this option to work by BL_HW_INIT_FN_HOOK.
    Frequency is not relevant here.
    Here is the comment from header file:

    // Performs application-specific low level hardware initialization on system
    // reset.
    //
    // If hooked, this function will be called immediately after the boot loader
    // code relocation completes. An application may perform any required low
    // hardware initialization during this function. Note that the system clock
    // has not been set when this function is called. Initialization that assumes
    // the system clock is set may be performed in the BL_INIT_FN_HOOK function
    // instead.
  • From your writing, "this function will be called immediately after the boot loader code relocation completes."

    Is this the delay you note?     This appears to be unresolved via this technique - does it not?

    I much doubt your claim of relevancy - you've avoided (any) explanation of (real) need for an (assumed) infrequent usage/event.

    My suggested "work around" remains...

  • In the past when I've needed a specific state of pins on power-up I've always used HW rather than rely on the SW, especially if the processor has built-in code/micro-code that runs before the user boot.  This has the additional advantage of working even while the processor is still in reset.

    Since most pins are default input one of the following should work

    • Add appropriate pull-up/dn to ensure the proper state until the pins are actively driven
    • Add pull-up and add inverter to any pins that need to be driven low on output
    • Use an additional pin as an enable for external logic that holds the output at a default until the enable is released.  This can also be used to turn off inputs.  Additionally you can hook up the reset line to this and ensure the state whenever the reset condition is active.

    Robert

  • cb1- said:
    (we've past done that via external - non MCU based HW - which "escapes" any/all such MCU reset issues)

    Let the record show that posters Robert & cb1 - once more - agree...

  • I understood, thank you