2020-07-22 04:48 PM
Hi All
I can drag and drop a binary file to the NUCLEO-F746ZG via its mbed hard drive that appears when the board is connected to the PC and the program runs.
I can also try to debug from STM32CubeIDE and it successfully programs and verifies the code but it then always immediately loses connection with the following message:
...
Download verified successfully
(Read)Failed determine breakpoint type
Error! Failed to read target status
Debugger connection lost.
Shutting down...
The complete console output is below.
What could be causing this and how can it be solved????
Note that with IAR Kickstart the debugger works correctly so it must be an STM32CubeIDE setting problem(?)
Thanks
Regards
Mark
STMicroelectronics ST-LINK GDB server. Version 5.4.0
Copyright (c) 2019, STMicroelectronics. All rights reserved.
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
-------------------------------------------------------------------
STM32CubeProgrammer v2.3.0
-------------------------------------------------------------------
ST-LINK SN : 066DFF545152717267241613
ST-LINK FW : V2J35M26
Voltage : 3.24V
SWD freq : 4000 KHz
Connect mode: Under Reset
Reset mode : Hardware reset
Device ID : 0x449
Device name : STM32F74x/STM32F75x
Flash size : 1 MBytes
Device type : MCU
Device CPU : Cortex-M7
Memory Programming ...
Opening and parsing file: ST-LINK_GDB_server_a07064.srec
File : ST-LINK_GDB_server_a07064.srec
Size : 7746 Bytes
Address : 0x08000000
Erasing memory corresponding to segment 0:
Erasing internal memory sector 0
Erasing memory corresponding to segment 1:
Erasing internal memory sector 3
Download in Progress:
File download complete
Time elapsed during download operation: 00:00:01.402
Verifying ...
Download verified successfully
(Read)Failed determine breakpoint type
Error! Failed to read target status
Debugger connection lost.
Shutting down...
2020-07-23 01:09 AM
Did you initialize the debug pins?
If you didn't, then a download using SWD is possible, because after reset the pins are configured for SWD. But after that these pins are reinitialized as GPIO or whatever you set them to, so the connection gets lost.
Debugging requires these pins, so enable SYS > Debug > Serial Wire in CubeMX, if you want to debug.
Good luck!
/Peter
2020-07-23 04:25 AM
Hi Peter
The program only sets the LED output and the user button input and otherwise leaves all pins in their default state. With IAR I can attach to the running target and debug so I don't think that it is a problem with SWD pins.
Today I managed a slight improvement with STM32CubeIDE in that after I have loaded the program (and the debugger disconnects) I then change the debugger configuration in the debugger configuration -> Startup -> Load Image and Symbols to "not perform the download" but still load symbols. Now I can connect to the board (which already has been programmed with the code) and I can run/pause and step code. However I can only step in "disassemble" mode since it says that it can't locate the source code (suggesting that it doesn't in fact correctly load the symbols).
Unfortunately it is also very unreliable in that sometimes it works and sometimes it just shows that it is running but it isn't and so I need to disconnect to start again.
Another thing to note is that after I load the program (attempting to debug) and it disconnects I tend to need to unplug the USB connector to get the board to respond again.
Finally if the loaded program is using the WFI command (to sleep between SYSTICKs) also the non-loading method doesn't connect/debug. This is however also an issue with IAR so I am presently avoiding using the WFI command when debugging.
I am using the most up to date STM32CubeIDE (installed a few days ago).
Do you have any ideas of other potential ways to try using it?
Regards
Mark
2020-07-23 05:19 AM
If you are only debugging with the NUCLEO, it is strongly recommended to set the SWD pins.
There is also a debug setting "Connect under Reset" (usually default, check it with Run > Debug Configurations --> Tab: Debugger), which should also work, as after reset the pins PA13/PA14 (for STM32F746ZG) are set to SWD. See e.g. RM0385, section 6.3.1., currently at page 202.
Anyway, you can upload your IOC and maybe main.c + stm32f7xx_it.c, it shouldn't contain too much company secrets if you just control an LED and a button. We can then double-check what could be the reason. You could also upload the whole project as ZIP, but in that case please delete the folder Debug before, as it can be easily recreated.
/Peter
2020-07-23 07:24 AM
Hi Peter
I was already using the "Connect under Reset" and I have also added PA13/PA14 configuration code immediately at startup but it doesn't change behavior.
With IAR I still have no issues and I can also debug the code (in disassembly mode) that STM32CubeIDE has programmed without any difficulties.
If you are interested in getting to the bottom of this the project is open source at https://github.com/uTasker/uTasker-Kinetis (don't be confused by the name since it allows NXP Kinetis projects to be moved to STM32 chips without porting effort).
To build with STM32CubeIDE:
Thanks
Regards
Mark
2020-07-24 12:12 AM
Hi, Mark,
indeed a very interesting project.
Unfortunately I don't find the time to dig into the issue, maybe someone else is able to jump in.
Regards
/Peter
2020-07-24 03:57 AM
Hi Peter
It is a shame that you won't have time to check out the problem but we will wait to see whether someone with more experience than us can take a look.
In the meantime we have reverted back to Atollic TrueSTUDIO (which was previously offered by ST-Micro) which works without any issues [also when using sleep modes between interrupts with WFI instruction] (project also in the open source project) and will try again later when new versions of STM32CudeIDE have been released which may have fixed something.
I did spend some more time with STM32CubeIDE this morning to see whether I could find a workaround and can (when downloading is disabled) do limited debugging (also in source code after changing the debug level) but the debugger loses the connection very easily, leaving the board running and needing to reconnect again (and start again). Therefore the experiences seem to confirm that something is too unstable at the moment.
Regards
Mark
2020-07-27 05:26 PM
I have been working on some projects using STM32CubeIDE v1.3.0 version for a long time (OS: macOS Catalina). Unfortunately, I updated STM32CubeIDE to v1.4.0 this morning and IDE couldn't find ST-link Server. Even after I manually tried to update ST-LINK server software module 1.3.0, it didn't work... (It can be about Catalina's /Application folder permissions but I am not sure.)
Long story short, I have just switched back to v1.3.0 (no issues about debug or connecting to ST-link Server) after wasting about 5 hours.
2020-07-27 05:49 PM
Hi
Although I installed only a few days ago I see that I have 1.2.0 (for Windows). Maybe the MAC version(s) have different version numbers?
Regards
Mark
2020-07-27 11:29 PM
Please check the website for STM32CubeIDE, where you find the current version. Some previous ones are also available when selecting the required version using the dropdown button on the right.
Good luck
/Peter