DEV_TARGET_CMD_ERR

stevek80

May 25, 2012 11:57

I'm getting this all the time, when trying to connect to a STM32VLDISCOVERY board via it's on-board ST-LINK,

or, when the thing was in good mood and working for a few debug runs, then all of a sudden, if doing anything or just returning from the kitchen, that evil red line in the status strip would ruin my day once more.

I'm using CrossWorks for ARM 2.1 and 2.2 (parallel install, to see if 2.2 is doing anything better), the problem persists with both versions.
My host OS is either Windows XP 32bit SP2 or Windows 7 home premium 64bit, while I have a feel that it's a bit worse on Win7, that may be subjective.

The board as such (or any of the bunch of those I have) works fine, and I can debug with a tiny free Chinese toolchain which doesn't support C++, which Is why I bought CrossWorks, but I'm short of giving up on it...

Out of desparation, I soldered together a JTAG adapter for my olimex OCD --> discovery board, kinda ridicilous since it has a debugger on-board, but it works on the mentioned free toolchain, not so in CrossWorks. (not giving details here, since this is not the question, and frankly, I expect the ST-LINK to work)

The actual program to debug is a bit different in CrossWorks from the other tollchain's, since there I added some C++ stuff (not using new/delete), alongside all the system specific C code, and I made the stack a lot bigger.
Since it *sometimes* works and usually just stops in the middle of debugging (preferably short before I'm getting close to a bug), I don't think it's the program, though...

(have read about the startup from reset issues... I put in a delay loop of a few seconds before main gets called, and I now put C++ objects that would otherwise be created before main(), into function scope, for testing)

Any clues what the problem could be ?

Comments

12 comments

Michael Johnson

May 25, 2012 12:16
Can you attach the project and I'll see if I can reproduce the problem.
0

Comment actions Permalink
stevek80

May 25, 2012 14:11
Hey, thanks for the awesome offer!
It took a while, I cleaned everything up, removed distracting junk & put dependencies with in there & made sure it compiled on another computer...
Now that a lot of stuff is removed, the error seems to come up way less often. But everything I removed was inactive before (calls commented out).

While I managed to get the error within 30 mins of debugging this now, 30 mins after that I didn't, so since you're probably not so inclined to play with it for hours, I'll try to find out what made it occur more often.
0

Comment actions Permalink
Michael Johnson

May 25, 2012 14:29
My guess is that the debugger is asking the st-link to show memory that it reckons shouldn't be accessed. There's a target property "Restrict Memory Accesses" which will cause any debugger accesses to memory locations that aren't in the memory map file to be ignored - try setting this to "Yes".
0

Comment actions Permalink
stevek80

May 25, 2012 14:46
I'll try that, thanks!
0

Comment actions Permalink
stevek80

May 28, 2012 10:25
So, after I set this to "yes", I haven't had this error again with CrossWorks version 2.2, while debugging quite a bit yesterday.
This "Restrict Memory Accesses" things seems to have done the trick for ver. 2.2, but in ver 2.1 this caused the app to freeze quite often, "whitening" the app window & content, so I had to forcefully terminate it. I guess that's something that was fixed then between the versions ^^
0

Comment actions Permalink
Gavin Tait

May 29, 2012 14:52
Hi,

I have just seen this error too. So far, I have not had any luck cleaning up the project/solution such that the error disappears.

Any pointers would be greatly appreciated

Cheers
0

Comment actions Permalink
Gavin Tait

May 30, 2012 09:42
Hi again,

I have just rebuilt my project from scratch and this problem still exists. I cannot connect to the STM32-Discovery via the ST-Link/V2 without the error 'DEV_TARGET_CMD_ERR'. I was able to previously and had been programming the device without issue.

I am using CW 2.2 on the Mac.

Please advise how this error can be removed. I am currently evaluating this tool and this issue has not provided me with the best start to this environment.

Thanks in advance

Gavin
0

Comment actions Permalink
Michael Johnson

May 30, 2012 09:58
Did you set the target interface type to be SWD rather than JTAG - you'll need to unplug before trying to reconnect.
0

Comment actions Permalink
Gavin Tait

May 30, 2012 10:07
Hi Michael,

Thanks for your quick reply. Yeh, I did that, which I had to do in my previous working projects.

Interestingly, I have just replaced the STM32-Discovery with another STM32-Discovery. The Link now works fine. When I drop the original device in, the link fails again.

I guess that kind of suggests that the issue is on the board? Or, is there anything embedded in CW which holds info about previous connections ... something that could have been corrupted?

Any thoughts?

Thanks again
0

Comment actions Permalink
Michael Johnson

May 30, 2012 10:43
Hi Gavin,

Could be that a bad program is in the original board. STM32 has a story that the debug connection can be done with SRST asserted - but it's not supported in CrossWorks. Try using the ST-Link software to connect it may have support for this.

Regards

Michael
0

Comment actions Permalink
Gavin Tait

May 30, 2012 13:19
HI Michael,

Thanks for the info. I have just done a hard reset on the device in question and I can now talk to it again. Back in business.

I guess it could have been a bad program, which I downloaded but dont understand how a change in my 'main.c' c-code for example could have upset the ST-Link/V2.

Regards
0

Comment actions Permalink
Michael Johnson

May 30, 2012 13:38
Going into a low power mode may turn off the debug port. This was always a problem area on ARM7/ARM9 but I haven't tried it on CM3. I'll put it on the todo list.
0

Comment actions Permalink

Please sign in to leave a comment.

Comments

Didn't find what you were looking for?