Reassigning an LTDC pin to DAC after MspInit — is this safe?

[CAdat.1]

Hello ST Community,

I am working on a custom PCB using the STM32H743ZIT.

My project uses the LTDC to generate a VGA signal.

I also need at least 1 DAC output and USB_FS.

 

The issue is, in this specific MCU, the only 2 DAC’s are on:

PA4 (conflicts with LTDC_VSYNC)

PA5 (possibly conflicts with LTDC_R4)

 

Now, I can move LTDC_R4 to PA11 but now it conflicts with USB_FS pins.

Importantly, LTDC_R4 is not physically connected on our PCB. We only use 8 simple colors so I can use any LTDC pin to connect it to VGA signal. I’m completely fine losing LTDC_R4 altogether because we don’t use it at all.

 

Question: 

If I do the following, will it cause any conflict issues due to the way the MCU works internally?

1- Assign LTDC_R4 to PA5 in CubeMX to satisfy the configurator

2- Immediately after HAL_LTDC_MspInit() completes, override PA5 to analog mode using HAL_GPIO_Init() for DAC use

3- Configure DAC1 channel 2 manually in code and importantly, I call it AFTER HAL_LTDC_MspInit()

 

Note: We are not reinitializing LTDC at runtime, so MspInit will only be called once at startup.

Thanks in advance :)

[mƎALLEm]

Hello,

Yes that’s feasible by configuring DAC and PA5 GPIO in the user code in HAL_LTDC_MspInit() in the user code in between:

    /* USER CODE BEGIN LTDC_MspInit 1 */

    /* USER CODE END LTDC_MspInit 1 */

The only suspicion I have is about the transition between LTDC R4 IO config and the DAC IO config and its impact on the device you need to connect to the DAC output: disturbing the device input in transients. Most probably no impact but you need anyway to perform tests.

There is no impact on the internal LTDC function with this.

[CAdat.1]

OK - so we tested it today with a custom board, generating a DAC output and VGA output at the same time, independant of each other. It does seem to work.

 

1- Disabled the PA5 pin in LTDC_MspInit:

/* USER CODE BEGIN LTDC_MspInit 1 */
/* 
 * IMPORTANT: PA5 is assigned to LTDC_R4 in CubeMX to satisfy the configurator.
 * LTDC_R4 is NOT physically connected on the PCB.
 * PA5 is reconfigured here as analog for DAC1_OUT2.
 * This override must remain here and execute after LTDC MSP init.
 */
GPIO_InitTypeDef GPIO_Override = {0};
GPIO_Override.Pin = GPIO_PIN_5;
GPIO_Override.Mode = GPIO_MODE_ANALOG;
GPIO_Override.Pull = GPIO_NOPULL;
HAL_GPIO_Init(GPIOA, &GPIO_Override);
/* USER CODE END LTDC_MspInit 1 */

2- Configured DAC1 OUT2 manually (easier said than done, Cube IDE fights you at every step by removing the driver files and stuff each time you generate code, but it is doable with some effort).

 

3- Both DAC and VGA monitor signal works as intended on test board so far... 

 

I just don’t know what you meant when you said:

The only suspicion I have is about the transition between LTDC R4 IO config and the DAC IO config and its impact on the device you need to connect to the DAC output: disturbing the device input in transients. Most probably no impact but you need anyway to perform tests.

 

If you meant “During the config transition, the device might not work as intended” by “disturbing the device input in transients” that’s totally fine by us, because we anyways have some seconds of warm-up period for our device when we first power it and the configuration is done during that warm-up period.

If you meant “disturbing the device input in transients” as in “this can bite you later on”, well I hope it won’t, on test board it worked as intended so far?

[mƎALLEm]

If you meant “During the config transition, the device might not work as intended” by “disturbing the device input in transients” that’s totally fine by us, because we anyways have some seconds of warm-up period for our device when we first power it and the configuration is done during that warm-up period.

If you meant “disturbing the device input in transients” as in “this can bite you later on”, well I hope it won’t, on test board it worked as intended so far?

Yes this is what I meant as I don’t have idea about what you have connected to the DAC. You need to check with the an oscilloscope what happens on PA5 in between configuring the LCD and the DAC configuration. Is there any glitch appearing during this transient? If there is no glitch (that could disturb your devices) that’s fine.

PS: in next time please kindly use the Code button to paste your code:

I’m editing your post then..

[CAdat.1]

We haven’t checked what happens on PA5 during the config transition period (and I suspect it is just a few microseconds?) because we thought it’s not that important what happens the first few miliseconds you plug the device in.

We don’t expect the device to work flawlessly the moment you plug it in, there is an explicit warm-up period (actually 2 seconds) for various stuff (capacitors, etc elsewere in device) to settle.

After that period, DAC worked as expected alongside with VGA signal.

 

And with that, I think the issue is settled as → “It works” if I am not terribly mistaken?

 

[mƎALLEm]

We haven’t checked what happens on PA5 during the config transition period (and I suspect it is just a few microseconds?) because we thought it’s not that important what happens the first few miliseconds you plug the device in.

We don’t expect the device to work flawlessly the moment you plug it in, there is an explicit warm-up period (actually 2 seconds) for various stuff (capacitors, etc elsewere in device) to settle.

After that period, DAC worked as expected alongside with VGA signal.

 

And with that, I think the issue is settled as → “It works” if I am not terribly mistaken?

 

Based on that feedback it’s OK. you can go ahead with that config: no risk.