2016-06-26 08:50 AM
I have a problem here that doesn't make one shred of sense. I have boards (STm32F405VG) I programmed a couple months back that were fine. Meaning, I could connect to the board, and print the output statements from the code when I used the ST-Link's ''Print from SWO Viewer'' function.
Suddenly it is not working. All settings are correct including port, frequency, etc. When I use the ''Print from SWO Viewer'' and then ''Start'', it disconnects from the target! I get the pop-up dialogue box stating ''Disconnected from SWV Trace Port''. This comes up in the main panel message box:09:42:17 : Connection to device is lost: check power supply and debug connection.
09:42:17 : If the target is in low power mode, please enable ''Debug in Low Power mode'' option from Target->settings menu. 09:42:17 : Disconnected from SWV Trace port! Tried different settings that did not help. Which I should not even bother because I have never needed to change settings with these boards, it's always worked. I've also tried on three different boards and they are all behaving the same. I went as far as trying the newest version of ST-Link utility and that didn't help at all. What in the world could be going on? It makes little sense. I know it cannot be the target boards - maybe one might give a problem , but not three....and all behaving exactly the same. Any help would be greatly appreciated.2016-06-26 08:53 AM
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.2016-06-26 09:22 AM
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=false2016-06-26 10:11 AM
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 regulator2016-06-26 10:15 AM
I'm not saying you can't use such regulation, just that there is additional heat, and reduce current sourcing as you get outside the sweet-spot for the devices..
2016-06-26 01:06 PM
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....2016-06-26 02:54 PM
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 8E12016-06-26 08:35 PM
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.