2020-09-04 02:39 AM
I'm working on my end-of-degree project using an STM32F407 Discovery board. I have been working with it the last couple of months with no problems, doing the pin configuration with STM32CubeMX and developing the program in ARM Keil uVision 5.
Yesterday, while doing some debugging the board stopped being recognized by the program. When trying to load any program Keil says "No ST-LINK detected", 30 seconds before it worked perfectly.
After looking on the internet this is what I have been able to find.
Any help would be appreciated; I have reached to a blocking point and cannot go on with my project.
Thanks.
Solved! Go to Solution.
2020-09-10 04:22 AM
At this point I give up on fixing the board.
In retrospective I believe that the cause of the damage might have been a connection I did between one of the GPIOs and one of the power supplies of the project (an ETX power supply). I did that connection to have an interruption to stop the program if that power supply stops working, but I guess it might have broken the board.
2020-09-04 02:46 AM
Try connect under reset first! Did you enable WFI or even deeper sleeps in some recent step or uou now have longer periods of WFI/Sleep?
2020-09-04 03:22 AM
Deleted. Sorry, I'm new. I ment to replay, not answer.
2020-09-04 03:22 AM
I have tried, but I'm not sure if I'm missing something, looking at comments online I wasn't sure of how to do it (I am quite new working with this kind of boards). I selected the connect under reset option in ST-LINK Utiliy (which the program itself suggested) and try to reconnect, including while pressing the reset button and/or having BOOT0 pin connected to GND
No, the program does not have WFI or sleep.
Personally, I doubt that the program is the problem, the changes I was doing at the time was activating a pin PB_13 as GPIO_EXT. The program itself is quite simple: 3 timers, 13 inputs set as GPIO_EXT plus the ADC and 12 PWMs as outputs. The LCD and COM PORT are only as a way to show data and error messages to the user.
2020-09-04 03:54 AM
The BOOT0 High trick will let you connect and erase your code if that is broken.
Check you aren't breaking PA13 / PA14 pins, these are used by debugger.
Could you have shorted or damaged the board? Broken a cable or connector?
2020-09-04 04:01 AM
Clive, all of the problems you talk about should be overcome with connect under reset, as long as the board is not broken.
2020-09-04 04:15 AM
Perhaps, but as that isn't working, I'm willing to repeat alternate approaches, in hopes of gathering more symptoms and responses, so a more definitive conclusion can be drawn.
Check ST-LINK jumpers.
2020-09-04 04:27 AM
2020-09-04 04:47 AM
There is no change when connecting BOOT0 to high.
ST-LINK jumpers I have had them all time on. I have never touched them since I received the board.
The board doesn't have external scratches or marks that may suggest that it is damaged. I guess that it might have gotten shorted at some point, but if so I'm wasn't aware of it. Power seems to work properly, 3v pins and VDD pins supply 2.9v when checked with a polymeter and 5v pins supply 4.56v.
2020-09-04 10:30 AM
I just got a rev D (MB997D) Discovery board a couple of days ago. So far it's worked great.
This morning I used STLinkUpgrade to update the firmware, and immediately after I started having the same problem. In particular:
It's clear to me that the ST-LINK firmware upgrade has contributed to the problem. Unfortunately I didn't note the shipped version so can't attempt a downgrade.
I have a workaround: I had the Discovery board connected via a USB hub; moving it to be directly connected has made STM32CubeIDE happy again.