Queries Regarding ESD Protection and STDC14 UART Connections for STM32MP157FAC1

[PS_115]

Hello,

We are designing a custom board using the STM32MP157FAC1 device. For programming and debugging, we are providing an STDC14 connector on our board and use the STLINK-V3SET debugger/programmer.

As per AN5031 (Section 8.3.3), the recommended ESD protection device is ESDALC6V1W5. Snapshot is attached for kind reference.

We have the following queries:

Query 1:
Can we use the HSP053-4M5 device instead of the ESDALC6V1W5 for ESD protection? We are already using the HSP053-4M5 to protect the data, clock, and command lines of the microSD card interface. Using the same device for the STDC14 interface would help us optimize the BOM.

Query 2:
Can we connect USART1_TX (PA9) and USART1_RX (PB15) of the STM32MP157FAC1 to Pin 14 (T_VCP_TX) and Pin 13 (T_VCP_RX), respectively, on the STDC14 connector for the STLINK-V3SET Virtual COM Port interface?

 

Regards,

PS

 

 

[PatrickF]

Hi ​@PS_115 

 

for ESD device, you could certainly put another one, JTAG is quite slow, so the one for SD-Card is OK even if overkilling.

For UART, you could use any UART pins assuming your SW device tree will be adapted to use this one as console output. there is come community posts showing that USART1 has been slightly more complex to setup in DT as secure by default (especially in TF-A early console), but there is no HW limitation to use it.

Notice also that USART1 is not part of possible BootROM boot pins (please refer to AN5031), but this is only a concern during early board bring-up in case USB DFU is not working (which is rarely the case except big HW mistakes). Boot UART allow to download basic tests (TF-A / uBoot), until board USB DFU being corrected.

 

UART4 PB2 and PG11 are still the recommended UART console (as it default to this one in our OpenSTLinux ecosystem deliveries)

 

Regards.

 

[PS_115]

Hello ​@PatrickF,

 

Thank you for your valuable response.

We are planning to use the SWD interface (instead of JTAG) for programming and debugging. In this case, would it be acceptable to use the HSP053-4M5 device for ESD protection as well?

Regarding the UART, yes the USART1 is not one of the BootROM boot interfaces as mentioned.

We are using STM32CubeMX software for the pin assignments of STM32MP157FAC1, and we observed that whenever UART4 is enabled in our project, CubeMX reports a warning (shown in the attached snapshots) at both UART4 and DEBUG interface. When UART4 is disabled, the warning disappears.

Could you please help us understand the reason for this warning and advise whether it has any impact on the design or we can just ignore it and connect UART4 with the VCP of the programmer ?

 

Regards,