Suddenly - ST-Link Has Stopped Working !

Posted on June 26, 2016 at 17:53

Going into low power mode (WFI Loops) are a primary cause for the loss of connectivity. Check also if the supply is getting overloaded, and browning out.

Suggest you try a very simple SWV test app.

Posted on June 26, 2016 at 18:22

clive1:

When you say ''SWV app, you mean a ITM send char statement?

void SWV_puts(const char *s )

{

while (*s) ITM_SendChar(*s++);

}

If so, I can try that as nearly the first statement after basic setup, no peripherals, and it still does not work.

Also, I tried connecting and running on EWARM using my JLink driver, which is what I have used to program and debug it. See ATTACHED image.

It's giving me the message.The first dialog box is what I get as soon as I hit the EWARM run button. The second is what comes up after I select ''tes'' to the fist dialog box prompt.

In response, I connected the target boards back to the ST-Link utility and checked ''Option Bytes'' at Level 0 and 1 to ensure none were on, and applied. It seems to take and set this with no problem.

Also, I can download and run the target application and know it's running because I can see the status LED's function. The issue is, I must have debug output to make some changes. 3 boards, 2 different connect pods, and I'm all of a sudden getting this issue I have never seen before.

My supply voltage coming in is 9V, into a 3.3V regulator. There's no issue with power, again, I have programmed, debugged and flashed about 40 of these boards and never seen this. Frustrating!

________________

Attachments :

ErrorMssg.jpg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Htr1&d=%2Fa%2F0X0000000aXu%2F7ibyW3rO5zKPH.xdUHlJfFs4EaFVC1Cub.m3DUM5aP8&asPdf=false

Posted on June 26, 2016 at 19:11

I think I mean an SWV app that only does pretty much just SWV interaction, and perhaps some additional stream out of a USART to a terminal. I don't think I'd want to clutter it up with any other functionality, and I'd want to observe if the device was being reset, and what NRST was doing during this loss of connectivity.

9V to 3.3V in a single drop is quite significant, beyond an LDO, or linear regulator

Posted on June 26, 2016 at 22:06

Regulation and supply is really a non-issue on this board. I am using a fit for purpose regulator: MCP1703

that can have up to 16V input and will supply 250mA output. It is field tested in this design and has been no issue for the last 15 months. The design has the main clock at 84MHz and draws about 30mA.

As I have said, this just started. I have built and flashed about 40 of these boards, and have done all kinds of debugging using both  J-Link and the ST-Link pods. The last time I worked on these boards, about 2 months ago, no problem. I am using the exact same code in EWARM, and had the same ST-Link DLL files. And now this?

Do any of those pop-up dialog boxes I attached mean anything?

Also, when I am connected with ST-Link, I have no control over the core. I go to Target->MCU Core and select ''Core Reset'' I get 2 back-to-back dialog boxes. The first says ''Cannot halt the core''. I click OK, then another comes up and says ''Can not run core while booting from flash memory and Read out prtotection is activated''

Why on earth is it saying read out protection is activated? It is OFF, as the option bytes say it is. Strangely enough, I am getting a similar message when using J-Link in EWARM - see the pop-up dialog I attached a couple messages ago.

I have done a completed device erase and this made no difference. Why would it be saying this on 3 different boards?

Thanks....

 

Posted on June 26, 2016 at 23:54

Translation ''I'm not able to talk to the core, or make sense of the responses I am seeing''

Start with the cabling, and work the issue from there.. That things worked in the past only matters in as much as you reflect on what you have changed, or what you are doing differently now. Find a board that works now, and contrast that with the ones that aren't working.

Soldering, orientation, supplies, state of reset, connectivity, ...

VCAP =1.25V, NRST High

Connect via USART1/3 with System Loader and Flash Loader Demonstrator, or Terminal app sending 0x79 at 9600 8E1

Posted on June 27, 2016 at 05:35

clive1:

You are quite right. After looking thoroughly through the code, I found that I had changed something quite small, but resulted in this time-wasting problem.

I had inadvertently disabled Port A, and of course SWD/SWCLK is connected on Port A. It's the only thing I have in my design connected to Port A. Explains why I could flash it and it worked OK, but could not get anything from a debugger connected to it.

Sorry about this post...and thanks for your help. Hopefully it will help someone who might make the same dumb-out.