AM2432: Is there a way to disable GPIO_init from syscfg's generated ti_drivers_config.c file?

Hi Hong,

Hong Zhang said:

Is there a way to disable to call GPIO_init() by default?  

This is a derived function based on your inputs from sysconfig GUI. Modifying the code in derived files is not recommended. It is impossible to change the default device initialization sequence in the derived code. But It is possible to comment the GPIO_init() out in System_init() manually.

Hong Zhang said:

I have seen some failures during my SDK 09.00 testing, I would like to rule out whether this GPIO_init() is the root cause. 

All GPIO signals are configured as inputs while PORz (power-on-reset) is low and immediately after PORz goes High. But both input buffer and output buffer are disabled after reset. The value found in the MUX MODE AFTER RESET column of Pin Attributes Table defines the default pin multiplexed signal function selected when PORz is deasserted.

Can you please share how your test failed? The GPIO_Init() only configure the direction of the selected GPIO pins.

Hello QJ, 

The System_init() is also derived code, and I don't see an easy way to comment out the GPIO_init(). Could you please give an example how to comment out GPIO_init()?

We have some of the GPIO directions that are supposed to be output, which are configured in the syscfg file. These include the SPI WP# and HOLD# signal. I noticed that these two signals are set to be output low after running GPIO_init() function. I didn't find a way that a default high or low can be given for these output GPIOs in syscfg file. The GPIO_init() only configures the direction of the selected GPIO pins, which sets the SPI WP# and HOLD# low in our case. These caused failures in our code to access SPI flash. Is there a way to set a default value for the output GPIOs in syscfg? We would like to set these two GPIOs default values to be high instead of default low. 

Thanks,

Hong 

Hi Hong,

The McSPI doesn't have HOLD and WP# signals, so you se two GPIO signals to control flash WP# and Hold.

You can enable the internal pull for the GPIO pin:

The pull is enabled or disabled in pinmux file:

Hello QJ, 

Thanks for the reply. 

From my understanding, the internal pullup is usually a weak pullup. When the GPIO is set as output, is there a way to configure the default value to drive high or low? Here I am referring to the default value for the hGpio->BANK_REGISTERS[regIndex].SET_DATA, where the equivalent GPIO function from SDK is listed below. 

static inline void GPIO_pinWriteHigh(uint32_t baseAddr, uint32_t pinNum)
{
uint32_t regIndex, regVal;
volatile CSL_GpioRegs* hGpio = (volatile CSL_GpioRegs*)((uintptr_t) baseAddr);

regIndex = GPIO_GET_REG_INDEX(pinNum);
regVal = GPIO_GET_BIT_MASK(pinNum);
CSL_REG32_WR(&hGpio->BANK_REGISTERS[regIndex].SET_DATA, regVal);

return;
}

Thanks,

Hong 

Hong Zhang said:

When the GPIO is set as output, is there a way to configure the default value to drive high or low?

The default output is LOW. 

If the pin is configured as INPUT, and the internal pull-up is enabled in pinmux configuration, the pin should be pulled-up after pinmux init and GIO init. Whenever you want to drive flash signals (WP, HOLD), you need to configure the GPIO DIR (output) first, then program the value to GPIO data register.

Another way is to add an external pull-up resistor to GPIO pins.

Hello QJ, 

In our application, we have several output GPIOs that require the default state to be high. This includes some of the reset signals in our application. With the default value being low set by syscfg for the output GPIO, this can cause unwanted glitches for these output GPIOs. 

Is there a way to disable the GPIO_init() to set those output GPIOs to be default low?  

I understand your suggestion, where we can configure those output GPIOs that need to be default high as input, then re-configure them as output in our application FW. However, this is very misleading and confusing. When an engineer looks at these GPIOs from syscfg, they are input GPIOs, then later on re-configure to be output GPIOs. 

I believe this is a bug introduced in this new syscfg release, which should be fixed by TI. 

We need to have a way to:
1) Declare the GPIOs in syscfg like in the previous version v1.14, without actually setting the GPIO directions. 
2) Set output GPIO default state in syscfg 

Thanks,

Hong 

Hi Hong,

The pins which can be used as a GPIO implement LVCMOS IOs, which have push-pull output buffers. The output buffer will drive low when enabled and will be be high impedance when disabled.

Hong Zhang said:

We need to have a way to:
1) Declare the GPIOs in syscfg like in the previous version v1.14, without actually setting the GPIO directions. 
2) Set output GPIO default state in syscfg 

I just checked generated code generated by stsconfig1.14, the GPIO_Init() is the same as the init function generated by the latest sysconfig.

My suggestion is to add an external pull-up to this GPIO pin.

Hello QJ, 

Using SDK 08.05 and syscfg 1.14, GPIO_init is not called in System_init(), refer as below. 



However using SDK 09.00 and syscfg 1.17, GPIO_init is called in System_init() by default in automatically generated code.


We already have an external pull-up on the board, but it won't help when the pin is driven low when setting as output. 

Thanks,

Hong 

Hong Zhang said:

We already have an external pull-up on the board, but it won't help when the pin is driven low when setting as output. 

It's my fault. The external pull-up doesn't help. 

Let me do some test today if adding the initialization value to the GUI works

Hi Hong,

I have filed a request ticket.

Hello QJ,

Thanks a lot for making the request. 

Is there a timeline for when this can be done?

Thanks,

Hong 

Hi Hong,

The request will be assessed by SW development team. I will keep you informed.