STM32H503RB - Eval Board PORT configuration issue

Ravichandran · ‎2024-08-09

Greetings,

We are currently using NUCLEO64 MB1814(STM32H503RB) in our application in which when configuring GPIOs in PORT A and integrating it with data pulses, the following error occurs stating the target device not responding. The data pulses are of 5V and the GPIO PORT A pins we have selected are 5V tolerant, but the EVM MCU operates in 3.3V. We have tried the same operation in PORT C, and it worked. Can you explain what the difference between PORT A and PORT B regarding this regard is. We are using STM32 Cube IDE

STMicroelectronics ST-LINK GDB server. Version 7.8.0

Starting server with the following options:

Persistent Mode : Disabled

Logging Level : 1

Listen Port Number : 61234

Status Refresh Delay : 15s

Verbose Mode : Disabled

SWD Debug : Enabled

InitWhile : Enabled

Waiting for debugger connection...

Debugger connected

Waiting for debugger connection...

Debugger connected

Waiting for debugger connection...

-------------------------------------------------------------------

STM32CubeProgrammer v2.17.0

-------------------------------------------------------------------

Log output file: C:\Users\VENGAM~1.SAS\AppData\Local\Temp\STM32CubeProgrammer_a27616.log

ST-LINK SN : 0044003D3132511138363431

ST-LINK FW : V3J15M7

Board : NUCLEO-H503RB

Voltage : 3.29V

SWD freq : 8000 KHz

Connect mode: Under Reset

Reset mode : Hardware reset

Device ID : 0x474

Revision ID : Rev Y

Device name : STM32H50x

Flash size : 128 KBytes

Device type : MCU

Device CPU : Cortex-M33

BL Version : 0xE2

SFSP Version: v1.4.0

Debug in Low Power mode enabled

Memory Programming ...

Opening and parsing file: ST-LINK_GDB_server_a27616.srec

File : ST-LINK_GDB_server_a27616.srec

Size : 24.36 KB

Address : 0x08000000

Erasing memory corresponding to segment 0:

Erasing internal memory sectors [0 3]

Download in Progress:

File download complete

Time elapsed during download operation: 00:00:00.133

Verifying ...

Download verified successfully

Target is not responding, retrying...

Shutting down...

Exit.

Regards,

Ravichandran C

STTwo-32 · ‎2024-08-09

Hello @Ravichandran and welcome to the ST Community .

Could you please take a look at this article. It should be helpful for you.

Best Regards.

STTwo-32

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Andrew Neil · ‎2024-08-09

@Ravichandran wrote:
when configuring GPIOs in PORT A and integrating it with data pulses, the following error occurs stating the target device not responding.

The SWD Debug pins are on Port A:

Therefore, if your "configuring GPIOs in PORT A" includes PA13 and/or PA14, then that is going to break the debugger connection.

Ravichandran · ‎2024-08-09

We've filtered out pins that we can't use and are left with only 5 pins namely PA0, PA1, PA2, PA6 and PA15. We have rejected PA3 since in our EVM Nucleo 64 MB1814B, it is configured as UART/USART as default. Remaining pins we've rejected since they are not 5V tolerant

Andrew Neil · ‎2024-08-09

And you're sure you're not messing with PA13 and/or PA14 ?

Or doing any operations which affect the whole of Port-A?

As a test, what happens if you disable all use of Port-A ?

Ravichandran · ‎2024-08-09

No, we are not using either PA13 or PA14.

We are not using any operations we have just configured the pins as GPIOs and haven't even connected the data pulses to the pins. And the IDE shows target not responding.

If we change the pins to PORT C (P0-P3), it works as intended.

Andrew Neil · ‎2024-08-09

@Ravichandran wrote:
If we change the pins to PORT C (P0-P3), it works as intended.

Which very much suggests that you are disturbing the debugger connection!

Do you connect under Reset?

Ravichandran · ‎2024-08-09

Can you kindly explain what you mean by connecting under Reset so that we can understand.

Andrew Neil · ‎2024-08-09

https://community.st.com/t5/stm32cubeide-mcus/debug-configuration/td-p/281735

Ravichandran · ‎2024-08-09

Yes Andrew, we have been using that debug configuration