[StrongArm]

Hi Brazis,
thank you for all the suggestions.

After reviewing all the possibilities I dicided to use openOCD direct. This is the only way to get runtime information from the CPU without the help of a debugger and without the need to stop/restart the CPU for data transfer. I wrote a small test project for this with QT5. An implemented TCP Client connects to the OpenOCD TCP Server on port 6666. Using an elf parser gives the possibilty to get the addresses and sizes from the variable names. Using the ocd_mdw/ocd_mww commands I can read and write variables, using array2mem/mem2array I can transfer whole buffer regions. Works great!

Best regards

P.S. Just tested VisualGDB with my MSP432 Discovery board, works fine!

[StrongArm]

Hi Bazis,
first of all, thank you for the great support here, even for people only evaluating VisualGDB!!!
Have to change this – where is the buy button -:)

Your last post solved all the strange problems I had.
Becoming old and blind is not funny! As usual i used a comma between the flags, so i added “,- specs =rdmon.sys”.Try it, the GUI does not complain, but you get all the troubles i had!
Whatever, problem solved, semihosting working with Newlib-nano.

>Regarding live variables.As a quick fix….
No quick fix needed, the development project (medical technology) I got the order for, has a time frame of 24 month..
Just looking for all the tools I need.
I see three different possibilties to run tests without adding some test functions to the code.
(During the devolopment adding test functions is not the problem, the problem starts when your code gets “frozen” and all debug functions are removed)

1.) Using GDB and OpenOCD direct to access the final software on the devices.
2.) Using your VisualGDBExtensibility Interface – seems to be able to do the job.
The only example i could find was the tuturial “Debugging Embedded Threads with VisualGDB”, tried it, worked.
But,… there is nowhere a documentation of all the Interfaces.
3.) Using the new Visual Studio MI Debug Engine.

Best regards

 

 

[StrongArm]

Hi,

-specs=rdimon.specs is correct, you can’t enter –specs=rdimon.specs into theLDFLAGS field.
You cannot uncheck “provide default implementations for syscalls” because _write,_close,_fstat usw.
becomes undefined when using printf with Newlib-nano.

>Not 100% sure what you meant about fixed-length buffer API. Could you perhaps provide an example of a task you want to accomplish with it?

I was talking about an API for the Live Variables. You have already defined the types from 8-bit unsigned to 64-bit floating point. Here i am missing a tpye to access to a fixed length buffer.

char buff[20] = “Hello world”;                         //fixed length buffer var on the embedded system, length = 20, no string variable
int count = 12345;                                                //int var on the embedded system

To show the Live Variables in the “Live Variable window” i can enter into the expression field
“count” and the value shown is “12345” or
“buff[0]” – value “0x48”
“buff[1]” – value “0x65”
“buff[2]” – value “0x6c” ……
This is ok when i want to show the variables only in the graph window.

With an Live Variable API I would like to do following:
char livebuff[20];
int  liveint;

readLiveVariable(count,liveint);
readLiveVariable(buff,livebuff,20);     //tranfer 20 bytes from the embedded system variabel buff
writeLiveVariable(count,i);
writeLiveVariable(buff,livebuff,20);   //send 20 bytes to the embedded system system variable buff

As I already said, getting programatical access to the Live Variables via an API would be really great – for example – writing  test software for embedded systems. Different test cases can be programmed on the PC and the embedded software running under the debugger stays untouched.

Best regards

P.S. how can I use the code window in this forum?

• This reply was modified 9 years, 3 months ago by StrongArm.

[StrongArm]

Hi Bazis,
tried as you succested:

>If you are using newlib-nano, please add “–specs=rdimon.specs” to LDFLAGS to enable newlib-nano semihosting implementation.

Adding this option to the LDFLAGS disables the breakpoints in the program and you get a warning in the GDB console:
“Warning: could not set a breakpoint on main. ‘Step into new instance’ will not work.”
Verified this behavior with a NUCLEO-L053R8 and Discovery 32F429IDISCOVERY board.

>If you want to do the formatting on the computer instead of the device, you would need to make a custom semihosting call handler plugin for VisualGDB.
>If you believe it is worth the effort, please let us know so that we could extend our SDK with API for implementing such plugins.

I believe that this API would be only usefull for a part of people working with some smaller devices where all the UARTS are already used.
Would it not be less effort to simply redirect the stream to a virtual com port on the PC?

Sorry for going off topic now!

But what kind of API would really be extrem usfull for a lot of people (at least i think so -):
Make an API for the Live Variables!
Add the type of a fixed length buffer to the variables and you get a perfect tool to run most of the needed test cases without changing the source code on the device(s).
You can do all together in one VS solution and dont’t have to fiddle around with some external gdb in asynchron mode.

 

Best regards from Austria

[StrongArm]

Visual Studio 2015 Community Edition
arm-eabi GCC version 4.9.2 VisualGDB 5.0 Beta 5

Just evaluating VisualGDB i also had a problem with Semihosting not working.
After testing different configurations i got it working by changing the library from NewLib-nano to default.

Using Semihosting changes the startup time for the debugger drastically from ~4 seconds to 15-20 seconds.The code memory overhead using the regular printf function for Semihosting on a STM32L0 device is just to much.
Would it be possible to implement a simple string output function with Semihosting and leaving the formatting up to the user?

Regards from Austria

[Author]

Posts