Troubleshooting ST-LinkV2/STM32F469 connection

Jorge Sequeira · ‎2017-08-25

Posted on August 26, 2017 at 00:28

Hey guys!

I currently have a problem with the connection between the debugger ST-Link V2, ARM Atollic 8.0.0 and a custom board with STM32F469. The Atollic and the ST-Link utility believe the Target is halted (and can't load programs or debug), the ST-LINK_gdbserver and the ST-Link utility can't recognize the target device but the ST-Link Utility seems to be able to connect to the debugger with the Hot Plug mode, although a Read Out protection was somehow enabled, and can't erase flash.

When trying to start a debug section, the Atollic console shows the following:

Target not halted

Error in initializing ST-Link device.

Reason: Target not halted.

While a message box with the following warning appears:

'Error message from debugger back end:

localhost:2000: The system tried to join a drive to a directory on a joined drive'

The Atollic settings are the default ones. I also tried changing the gdb server port to 2000, but still the same result.

This error doesn't allow the debugging or loading of .elf files. I already tried to do the following:

Turned the ST-Link on and off.
Turned the computer on and off.
Updated the ST-Link firmware.
Updated the computer drivers for the debugger.
Tried the ST-Link_gdbserver server and client
Installed ST-Link utility
Tried erasing the FLASH memory (Utility popped error saying 'Read out memory enabled')
Tried reprogramming the board, but it showed me 'The elf loader file is not accessible.' (Since Atollic only outputs .elf files, I tried saving a .hex file from the STM32 ST-LINK Utility, and used that one)
Tried the ST-Link_CLI

After this, I also tried to run the ST-Link_gdbserver to see if I could get a different response, but all I got was the following:

'Target unknown MCU target

Error in initializing ST-Link device

Reason: Unknown MCU found on target'

On the other hand, when trying the ST-Link utility, when running from 'Normal' or 'Connect Under Reset' mode, the utility pops a message saying stating:

'14:53:37 : Can not connect to target!

Please select 'Connect Under Reset' mode from Target->Settings menu and try again.

If you're trying to connect to a low-frequency application, please select a lower SWD Frequency mode from Target->Settings menu.

14:53:41 : Can't halt the core'

But, when running on Hot Plug mode, a connection is made available. What's interesting is that the Device ID is not recognized, nor is the Device Family.

Although the FLASH memory cannot be erased due to a Read Out Protection, this read out protection cannot be disabled with 'Option Bytes', an error message pops up stating

'Could not set Option Bytes!,

Please reset the target and retry'

I believe the debugger can't recognize the MCU, and therefore a read out protection is interpreted somehow.

I don't currently have access to the hardware connection between the ST-Link and the board, so, besides from a bad connection, I'm not sure what could be wrong.

In short, I'm unable to read or write the MCU, I get 'Can't halt the core', 'Unknown MCU found on target' and 'The system tried to join a drive to a directory on a joined drive' errors from different software.

I'm running on Windows, Atollic 8.0.0, STM32 ST-LINK Utility v4.1.0.0, STLINKUSBDriver.dll v5.0.2.0, ST-LINK_CLI v3.1.0.0

#can't-halt-the-core #could-not-set-option-bytes! #unknown-mcu-found-on-target #stm32f469ni #atollic #st-link/v2

Vangelis Fortounas · ‎2017-08-28

Posted on August 28, 2017 at 16:29

Hello!

I am not sure what is the exact problem but i faced a similar problem by my mistake.

I programmed an mcu and 'accidentaly' after start went allways to standby node.

I had not acces from SW because i didn't set the DBG_STANDBY bit.. Had exact the same symptoms like yours!

In your case STLINK utility connects to your device under reset and after connection releases the reset. For some unknown reason after release reset . . the sw connection breaks and you can do nothing.

Your chance to connect to your device is to keep reset button down before you try to erase your memory(and load new firmware) by your IDE.

Release it , just before timeout of your IDE expires.

I use this method succesfuly with keil and stlinkV2 debbuger. and have 100% success in such not so rare cases.

Regards.

Jorge Sequeira · ‎2017-08-28

Posted on August 28, 2017 at 17:43

Hello Vangelis,

Thanks for the reply, it's much appreciated. I will try and install MDK and see how I fare while trying to program and debug with Keil.

The other difficulty I also have with the current setup is that I don't currently have access to the MCU pins, or a reset button.

Vangelis Fortounas wrote:

In your case STLINK utility connects to your device under reset and after connection releases the reset. For some unknown reason after release reset . . the sw connection breaks and you can do nothing.

Is that the case? I can only connect on 'Hot Plug' mode through the utility.

Regards,

Jorge

Vangelis Fortounas · ‎2017-08-28

Posted on August 28, 2017 at 18:14

Hello again.

HotPlug mode connects target with no reset and not halts the target. In your case Its not realy connects as you mention in your post(no ID no family, etc)

Connection under reset(not POR) halts the targer just after reset and target do not execute any code.

If we supose that your program changes the behaviour of SWclk and SWDio pins (or cuts the power) after reset it will not posible to have access by 'software reset mode' or by 'hot plug mode'.(By the way , please check the VCC of your target .)

In this case the only solution is the external reset.

In case the NRST pin is connected to your stlinkdebuger , it will performed automaticaly, else you need to press the button.

I forgot also to mention to lower the clock of sw port . and to try..(from target settings)

Regards

Jorge Sequeira · ‎2017-08-28

Posted on August 28, 2017 at 21:47

Vangelis Fortounas wrote:

HotPlug mode connects target with no reset and not halts the target. In your case Its not realy connects as you mention in your post(no ID no family, etc)

So it's not actually connected to target, but it is connected to the debugger?

Connection under reset(not POR) halts the targer just after reset and target do not execute any code.

If we supose that your program changes the behaviour of SWclk and SWDio pins (or cuts the power) after reset it will not posible to have access by 'software reset mode' or by 'hot plug mode'.(By the way , please check the VCC of your target .)

Yeah, funny thing is that the program that the core is currently running is but the following:

int global_var = 0;

int main(void)

{

int i = 100;

int a = 0;

if(a == 0 ) {

a = 1;

} else {

a = 2;

}

while(i < 10000)

{

i++; // = func(i);

a--;

}

return 0;

}

Nothing too complicated or crazy. No pin manipulation. Oh, and VCC is definitively not the problem xD.

In this case the only solution is the external reset.

In case the NRST pin is connected to your stlinkdebuger , it will performed automaticaly, else you need to press the button.

I forgot also to mention to lower the clock of sw port . and to try..(from target settings)

Yeah, my board is custom, and I don't have access to schematics, so I'm not 100% sure that the NRST pin is correctly connected. or if I'll touch something else that might damage the board.

Also, I tried all the clock of SW port options.

Kind regards,

Jorge Sequeira · ‎2017-08-29

Posted on August 29, 2017 at 23:14

BTW! I solved the problem by installing MDK 5 and loaded a program into the MCU.

Thanks so much Vangelis for helping

Bob Boys · ‎2017-08-29

Posted on August 30, 2017 at 01:23

Hello

There are several ways to RESET a Cortex-M processor.

uVision (and others) support these: See the picture below:

This is in the Debug tab. Select Help in this window and then select Debug at the end of this document.

Some people find one of these selections useful especially with custom boards.

Under Connect is a new feature to connect to a running target without stopping or resetting it.

Bob

dan linehan · ‎2017-10-06

Posted on October 06, 2017 at 17:52

I have a v similar problem Atollic 8, stf32F4Discovery board. Debug refuses to connect ST-LINK at the point that it usually does. ST-LINK application on its own connects fine and I can xfer hex files. There is nothing obvious wrong with the hardware.

When I start a debug session, I get an error in the debug console ' Target unknown MCU target ' followed by ' Unknown MCU found on target' . Everything was working fine but I probably have reset some setting in the Atollic. No hair left. The rotating ST-Link light next to the USB connector is fixed red at all times.

Interestingly, If I try and run debug session with ST-LINK app running and connected (coloured led rotating now) I get a

different

error 'Device connect error' from Atollic debug console.

any help much appreciated

Dan