Skip to main content
L
LRABO.1
Visitor II
July 10, 2020
Solved

STM32F767GTx custom board - Target is not responding, retrying...

  • July 10, 2020
  • 2 replies
  • 1134 views

Hi,

I'm a french embedded developer.

At my office, i use a Nucleo-STM32F767ITX and my software works fine.

Now, we have a new STM32F767GTx custom board, and my software must works on it.

I use a STLINK V3 with SWD interfaces (SWDIO on PA13 and SWDCLCK on PA14), i never use it before.

And i discover some issues.

During debug, i can program the new board, run it and blinks a LED. It's just the beginning of my software.

A few minutes after, I start seeing "Target is not responding, retrying..." message and finally an error message about not being able to read the target. When I try to reprogram the device either through the debugger, it fails saying "No device found on target."

USART1 doesn't work too, i change putchar so printf can send some text to serial port. With the Nucleo board, it works with USART3.

Can i have some helps ?

Thanks a lot.

    This topic has been closed for replies.
    Best answer by KnarfB

    > A few minutes after

    Is it just the debug link that breaks down? If so, you could lower the SWD clock and check if that helps. No idea for the UART except for using that pins as GPIO to check proper board connectivity.

    2 replies

    K
    KnarfBAnswer
    Super User
    July 10, 2020

    > A few minutes after

    Is it just the debug link that breaks down? If so, you could lower the SWD clock and check if that helps. No idea for the UART except for using that pins as GPIO to check proper board connectivity.

    L
    LRABO.1Author
    Visitor II
    July 10, 2020

    I lowered the frequency of the SWD clock, and things have improved a bit. I even managed to communicate on USART1.

    I think the problem is the cable between the card and the STLINK V3. We use a specific connector for the SWD interface, maybe a soldering or length problem.

    Thanks a lot !

    T
    Tesla DeLorean
    Graduate II
    July 10, 2020

    Perhaps connect NRST and SWO also, so you can gain control of the device, and have a debug output channel.

    If the device goes into a low-power mode it will turn off portions of the chip that control the debug interface.

    Make sure you don't have any code/options to disable the debug interface, or interfere with the pins.

    Check the hardware design, especially power interfaces, and VCAP pins/capacitors.

    USART1, going to depend on the pins, clocks and peripheral being set up correctly on the software side, and the design being solid on the hardware side. Nothing to work with here. Create simple code to initialize UART and pins, then loop sending 'U' characters, scope and probe.

    Terms & ConditionsAccessibility statement