I have an Elprotronic FlashPro-ARM JTAG/SWD programmer for programming Kinetis MCUs (as used in Teensy 3.x boards) in a manufacturing product tester.  I would like to use the same programmer during development with Visual Micro.

Is this possible?

I have a command line utility (in C#) that can be executed to do the upload and a JTAG connector on the target board.  There is also a API/DLL available for the programmer.

There is a GDB option for visual micro but it's beta and I am not sure how easy it will be to make it work.

I've installed Visual Micro GDB and am proceeding to set up to do my development including debugging of the Kinetis MK20DX processors this way. 

My boards have a JTAG/SWD interface on them that I use to upload hex files with using a standlaone programmer.  I want to get a programmer/debugger unit to connect between my Windows PC  and the target board that is compatible with Visual Micro/GDB (with OpenOCD?).

Can anyone give me some suggestions on what pgm'er/debugger to get that would work in my situation?.  I am happy to support only the MK2x series but a general ARM solution would be even better.

Thanks!

I just found the GDB debugging forum... sorry for posting in the wrong place.  Please move this thread to that forum if you feel it is appropriate.

I have ordered an Arduino Zero (the "genuine" one from Arduino.cc) and plan to use that to learn GDB debugging in VM.  I can do that without the need to use a "debug probe".

One question I have is whether VM GDB debugging will work with Visual Studio 2015 or do I need to upgrade to VS2017? I have not upgraded to VS2017 due to the (incompatible) change in project format.

Also, will this probe from P&E Micro work with VM for the ARM processors?

http://www.pemicro.com/products/product_viewDetails.cfm?product_id=15320168&productTab=1


BTW, I think VM is terrific and have been using the Pro version for all of my development for some time now.  Nice work!

I should have included this information on the P&E GDB server: 

http://www.pemicro.com/products/product_viewDetails.cfm?product_id=15320151&productTab=1

Sorry for replying to my own post so many times!!  I am continuing to try to figure out this stuff and keep finding more things.

We have several Altera (or clone) USB-Blasters.  These should work assuming I correctly set up the config for it, right?

On setting up the configuration, I have been pouring over the VM User's manual, various forum posts, and Google in general but I haven't been able to find detailed instruction on how to do it.  Is there a link for detailed instructions on how to do it, e.g. boards.txt/platforms.txt file changes, *.cfg files, drivers, etc.?

Thanks!

You can probably try various settings using a local board.txt in the project. This avoids having to change boards.txt and platform.txt then reload toolchains.

There is a doc here.There are a lot of openOCD cfg files installed with the OpenOCD that is installed with visual micro. You can also hard code your own paths.

http://www.visualmicro.com/post/2016/01/17/3rd-Party-Hardware-GDB-Configuration-Guide.aspx

The vmicro>compiler menu allows you to switch on showing all build properties. That gives you access to all known build {variable} names.

Switching to arduino zero board and attempting compile will show a build properties for a valid gdb debug.

.
I had trouble following the 3rd Party Config doc because there is an error in the path for the OpenOCD folder.  When I look in my install path (3vu3tp0o.aov) I see this:
http://testani.net/VM/install.jpg

The 3rd Party Config Guide shows the OpenOCD path as: "visual micro install path\default\tools\openOCD".  Notice there is no default folder in the install folder.  After clicking around I determined that there is an OpenOCD folder at ...\Micro Platforms\default\tools\openocd-0.9.0.  So this is the error that needs fixing. 

BTW, I had *many* install folders as it seems every time a reinstall is done the old folder is left behind.  I cleaned everything up and did a clean install.

OK... so I see there are cfg files in the scripts folder for boards, chips, cpus. I can't find any *.tcl files for the NXP Kinetis line and no *.cfg file for the KDx family (at least KD20 and KD22)?  Are these available somewhere?

In the interfaces section for j-link there is only a link to the Segger site for j-link and comments. Is all I need to do is specify the serial number (with leading zeros) in the cfg file?  I am also going to use USB-Blaster and I see all that is needed is the VID/PID which I assume is going to be different for Altera's and the clones, correct?

I tried a build of the Zero as you suggested and can see all that is going on.  That is a good suggestion.  It won't compile, however, as  core_cm0plus.h is missing.  I will have to hunt that down.

Thanks for bearing with me on all of this but hopefully my questions are also those others may have and they will be help as well.  This stuff is a bit confusing! Thanks

Tim@Visual Micro wrote on Jan 15^th, 2018 at 7:04pm:

You can probably try various settings using a local board.txt in the project. This avoids having to change boards.txt and platform.txt then reload toolchains.

I am using a local board.txt file in a project to override settings for the board in the master boards.txt file.  I need override some settings in platform.txt as well as have some not included at all.  I am looking for a way to do the latter which leads to these questions:

Is platform.local.txt supported or a way to specify the path to my specialized platform.txt?  There are a few items in the master platform.txt file that I do not want but don't know how to override/eliminate them completely without editing the master platform.txt file.  I need platform.txt the way it is for other, existing projects.

If not, is there a way to have an item in the platform.txt file excluded with a flag or define and a conditional statement?

Thanks

i think platform.local is also supported but all the properties of boards.txt and platform.txt etc are combined for compile so you can put platform.txt commands in board.txt

My understanding is that the project board.txt parameters supersede (override) the same parameters in the "master" boards.txt and platform.txt files.  My primary question is how to  prevent a certain parameter in either of the master files from being applied at all.  I have set a few of the same parameters in my local file as "<parameter> =" which I *think* is working but there are many and this will be tedious and error-prone.

What I would rather do since there are many things in the master files I don't want is to have board.local.txt and platform.local.txt replace the master files for a specific project. 

My reading on this subject is that boards.local.txt and platform.local.txt were supported in Arduino previously but are not supported now.  I have verified this by creating both *.local.txt files and they are ignored. The board selected in the dropdown is what is used along with the one master platform.txt.

I can create a new board as a section in the master Boards.txt file if necessary.   The only way I see to do the platform.txt file is to have multiple versions that get renamed for different projects..... unless it is possible to use if/then conditionals or something in the master platform.txt.  Does anyone know if it is possible and how to do it?

The very best solution to this is if Visual Micro supported the *.local.txt files.  Is this possible???

Not sure I understand some of that but you can set multiple properties on a single line if required.

Where did you put your platform.local.txt and where did you see a note about it being discontinued?

I put both *.local.txt files in the same folder as the INO file.  That folder is a sub-folder of the main project folder in the Sketchbook folder.  I just tried it in the top-level project folder and got the same results... they were ignored.

If you search for platform.local.txt or board.local.txt a couple of github hits (seemingly of files) come up but they are no longer valid links.  Here are a couple of links where I get the impression they are no longer supported:

https://github.com/arduino/Arduino/issues/3371

http://forum.arduino.cc/index.php?topic=313206.0

The rest of what I was saying is that board.txt does not replace the master boards.txt and platform.txt, only overrides the parameters included. 

The bottom line is a feature request and that is for Visual Micro to support platform.local.txt and board.local.txt.  Is that possible?

I see thanks,

1)
Visual Micro does not use arduino for build and it still supports the .local version but they need to be in the same location where the platform.txt is located and that is nowhere near your own code folder(s).

If platform.local.txt in the platform.txt folder does not work then try platform.win.txt instead but again in the folder where the hardware definitions (platform.txt) exist

2)
Yes board.txt does not replace but if you copied platform.txt into board.txt you would have your local version.

3)
Your project directory structure should have the project_name.ino in a folder called project_name and the visual studio project should also exist in the same folder and be called "project_name". (replace project_name with name of project)

Also to answer your first question again you can add programmers to the programmers list. Just follow the arduino 3rd part hardware guide(s). Visual Micro uses the same config as the arduino ide.

Thanks, Tim.

That's just about where I am at this point...getting the programmmer to work and starting a debug session.  I am almost there getting GDB debugging going on a custom board using a MK20DX128VLH7.  I am doing this with the Teensy core and have created a section in boards.txt for the new board plus I created a standalone platform.txt file.  (I'll get back to the local board.txt file at some point).  Thanks for the help on this thus far!

I am trying to set up a j-link module and the latest Visual Micro (registered) and Visual Studio 2015. Cross Platform Mobile Development (Android) and Microsoft MI-based debugger are installed   I am using jlink.exe (Commander) on a command line basis passing a jlink script to download to the MCU flash. The script resets the MCU and then jlink.exe exits.

Everything works up until the debugger is to start, i.e. the flash is programmed and the MCU starts to run (as a test I put I put a run command in the jlink command script but I usually just reset the MCU and exit). After more output in the Output window I then get the error message:
Unable to start debugging. Cannot access a disposed object. Object name: 'Debugger' (from Visual Studio)

I saw a post in this forum long ago but it was about Linux and not applicable.

Suspecting it is something with jlink.exe, I am trying to use OpenOCD to flash the MCU but I having little success thus far. I created a "programmer" (jlink-SWD) in programmer.txt and copied the programmers.txt file to the Teensy hardware/avr folder (where boards.txt, etc. are) since there isn't anything there for programmer as it is built into the Teensy boards.  I set vMicro >> Uploader to my new programmer which does appear in the list. 

This is where I am stuck because I don't know how to set the program to run to do the programming from OpenOCD.  All other programmers use AVRdude.  Here is what I have as a programmer thus far:

[code]jlink-SWD.name=JLINK-(SWD mode)
jlink-SWD.communication=usb
jlink-SWD.protocol=SWD
jlink-SWD.program.protocol=swd
jlink-SWD.program.tool= <what to put here???>
jlink-SWD.program.extra_params= < and here???>[/code]

Any ideas on how I can proceed?

Al

You have done well. I am assuming you can click F5, your custom programmer runs then gdb tries to run.

After it fails you might need to terminate the micro.gdb.exe process or openocd.exe before another attempt can be made.

Hopefully you have vmicro>compiler>show build roperties enabled so you can see the build props such as {runtime.tools....} etc.

This is the platform/board.txt gdb for the texas instruments tiva boards

There is a 3rd party gdb guide here that might help


Code (c++):

# Platform external debugging # -------------------- debug.tool=gdb tools.gdb.pre_init.tool=openocd tools.gdb.cmd=arm-none-eabi-gdb.exe tools.gdb.path={runtime.tools.arm-none-eabi-gcc.path}/bin tools.gdb.pattern="{path}/{cmd}" -interpreter=mi -d "{build.project_path}" tools.gdb.openocd.cmd=bin/openocd.exe tools.gdb.openocd.path={runtime.vm.ide.platforms.path}/default/tools/openocd-0.9.0 tools.gdb.openocd.params.verbose=-d2 tools.gdb.openocd.params.quiet=-d0 tools.gdb.openocd.pattern="{path}/{cmd}" -s "{path}/scripts/" -f "{path}/scripts/{build.openocdscript}"

Yes, clicking F5 is what I am doing to start the build, flash, and (try to) launch the debugger. I have been using the 3rd party guide for Visual Micro and 3rd party guides for Arduino and have the code you listed included.  I have also been researching this and have many links saved.  The problem is nothing I have found shows *how* to do the flashing and that is where I am stuck.

I bought an Arduino Zero (from Arduino.cc) and can flash and debug perfectly.  Since it uses the built in debugger chip, it isn't much help in getting a bare board with dongle going.  I have been looking for a *complete* example but can't find one so have been hacking around for days trying to get this going.  I can't put a downloader/debugging chip on the boards I am designing since I can't afford the cost.

Anyone know of a complete example on how to do this under Visual Micro???

The reason I am using Arduino is the vast number of libraries available.  Having Visual Micro/Visual Studio is what makes that bearable.  I'm going to keep working on this but soon may have to give up and switch to something else for programming Kinetis devices.

I hope it is OK that I have attached the section of boards.txt I am using along with the standalone platform.txt.  Maybe someone can see what I am doing wrong! I can attach the OpenOCD cfg files if that would help

Thanks
Al

---

You need to add your own programmer. The zero is a bad example. So choose the avr isl mkII or something like that with an avr board.

I did add my own programmer, as I said in the previous post, but it isn't complete.

I've put that aside for now and am working directly with OpenOCD at the command line to see if I can get it to work with jlink.  As it turns out, it doesn't!  At this point, trying to get this to work for debugging in Visual Micro is not the best use of my time, which I am running out of having put in days on Visual Micro debugging.

So far, I cannot get OpenOCD to to connect to the jlink as it is throwing an error:

Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
Error: Cannot find jlink Interface! Please check connection and permissions.

I downloaded and installed OpenOCD 10.0.0 (binaries) and it has the same problem.

For OpenOCD to work with jlink, a different driver is required: libusb-win32. This whole libusb thing is as convoluted as OpenOCD.  It looks like if I install it, the Segger driver gets replaced and jlink tools will no longer work. Uninstall looks like a nightmare.

From old links, I saw that there is a build option for OpenOCD for enabling jlink.  By any chance did you (or could you) build OpenOCD with that enabled?  I am not in a position to build OpenOCD myself since I uninstalled Eclipse, etc. long ago. 

Al

Okay makes sense to get gdb working outside of any ide to start with. The upload issue is something for both visual micro and the arduino ide, one solution will work for both but not required right now.

I don't have facility to build openOCD and don't know it very well.

I assume you tried version 9 which is the one most things/articles appear to work with.

Instead of trying to fix it I would put the usb drivers back to default.

Then post the full error test you see when trying to connect to the jlink.

Also confirm which firmware version is installed on the jlink adapter and what command line you are using.

Yes, tried version 9 as installed by Visual Micro.  Jlink firmware is the latest.  I didn't change any USB drivers for the reasons I said in my last post.  I can connect and control the jlink module using Jlink Commander and, in fact, can flash within Visual Micro using the command line version of it.  This means the jlink hardware and jlink usb driver are fine. 

The full attempt to connect to jlink by OpenOCD is below.  I am using the jlink.cfg that comes with OpenOCD and created the MK20Board.cfg and k20.cfg (which uses kx.cfg that comes with OpenOCD).

MK20Board.cfg (don't know if flash banks are properly defined but will fix that later, if req'd):

Code (]#
# MK20 Board

source [find target/k20.cfg):

$_TARGETNAME configure -event reset-init {      puts "-event reset-init occured" } # Bank definition for the 'program flash' (instructions and/or data) flash bank pflash.0 kinetis 0x00000000 0x40000 0 4 $_TARGETNAME flash bank pflash.1 kinetis 0x00040000 0x40000 0 4 $_TARGETNAME

K20.cfg:

Code (]# Freescale Kinetis K20 devices

set CHIPNAME k20
source [find target/kx.cfg):

error results for command: openocd -f interface/jlink.cfg -f board/MK20Board.cfg
[code]C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\3vu3t
p0o.aov\Micro Platforms\default\tools\openocd-0.9.0\bin-x64>openocd -f interface
/jlink.cfg -f board/MK20Board.cfg
Open On-Chip Debugger 0.9.0 (2015-05-19-12:09)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "jtag". To override use
'transport select <transport>'.
Info : add flash_bank kinetis k20.flash
adapter speed: 1000 kHz
none separate
cortex_m reset_config sysresetreq
Info : add flash_bank kinetis pflash.0
Info : add flash_bank kinetis pflash.1
Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
Error: Cannot find jlink Interface! Please check connection and permissions.
[/code]

I have read about the usb driver issues with jlink. It seems to have broken since they release new firmware with bug fixes. Uggh :)

It needs the winUSB driver. Some blogs recommend using this product to install the driver.

http://zadig.akeo.ie/

I had another thought...

JLink comes with it's own GBD server.  Can this be used instead and simplify all of this???  Segger JLink is a very popular programmer/debugger module and now with the EDU version it is very affordable at $29.95 (non-commercial use).

It seems Visual Micro should support it directly!

Tim@Visual Micro wrote on Jan 29^th, 2018 at 6:46pm:

I have read about the usb driver issues with jlink. It needs the winUSB driver. Some blogs recommend using this product to install the driver. http://zadig.akeo.ie/

If I did that I still have the problem of what to use in the programmer.txt file to create a definition, i.e. what program and commandline parameters to call when it is invoked.

Would I do the following as a programmer definition???

jlink-JATG.name=JLINK-(JTAG SWD)
jlink-JATG.communication=usb
jlink-JATG.protocol=swd
jlink-JATG.program.protocol=openocd
jlink-JATG.program.tool= <path to openocd bin folder>openocd.exe
jlink-JATG.program.extra_params=-f interface/jlink.cfg  -f board/MK20Board.cfg

If that has a potential to work I could try changing the driver.

Hi,

Adding an arduino 3rd party programmer

For the programmer I would open arduno ide and find the "Upload using programmer" has an issue with your definition. Then it is okay to ask for help on the http://forum.arduino.cc where they have people who can help.

When you have that working I can easily help you tune it or make it more flexible but they know their own spec for programmers much better than I do.


j-Links owns GDB

I have a j-link but never had time to use it. If you can find the direct calls then we can certainly look at using it instead. You will see that you can configure in the visual micro gdb settings which programs it needs to run to launch a gdb session..

It seems that the standard GDB is implemented plus multiple extensions.  The J-Link Manual (UM08001) is here and has a GDB section:

https://www.segger.com/downloads/jlink

So in theory just specify the gdb.path or just hard code the entire .pattern to start with. This assumes no openOCD

debug.tool=gdb

tools.gdb.pre_init.tool=openocd

tools.gdb.cmd=[hardware tool chain gdb.exe]

tools.gdb.path={runtime.tools.[hardware tool chain path}/bin

tools.gdb.pattern="{path}/{cmd}" ­interpreter=mi ­d "{build.project_path}"

tools.gdb.openocd.cmd=bin/openocd.exe

tools.gdb.tcp=localhost:3333

That still uses openOCD which can't connect to the jLink.

I think I need to get openOCD to connect with Jlink.  Way back in this adventure I was able to get the upload to happen in Visual Micro using JLink Commander on a command line basis.  Then the debugging session would fail with the Unable to start debugging. Cannot access a disposed object. Object name: 'Debugger' error from Visual Studio.

Maybe the problem was same problem of not connecting with the jlink.

I'm making progress and can now use OpenOCD to flash and restart my board.  I changed the JLink USB driver to winUSB and it now connects and works.  I created an OpenOCD script  based on a GitHub script I found which includes a program() and attach() procedure using SWD.  I found it here:
https://github.com/geomatsi/stm32-tests/tree/master/boards/stm32f103-mini/scripts

It works to load my hex file and restart the MCU. It is hardcoded to the hex file path right now but this should be straightforward to pass in platform.txt (maybe... everything has been a battle thus far!).  I haven't tried the attach function at this point.

The script follows and is called to flash the device with this command:
    openocd -f setup_MK20.cfg -c "program ()"


Code (]# openocd setup for MK20

source [find interface/jlink.cfg):

transport select swd source [find target/k20.cfg] # write image and restart target proc program () {      init      reset init      halt      flash write_image erase "C:\\Users\\Al Testani\\Documents\\Arduino\\Blink2\\Debug\\Blink2.hex"      reset run      shutdown } # reset target and attach to debug proc attach () {      init      reset run }

useful to know thanks

Where are the "runtime.vm." path values defined?  I am looking for the one that is the openocd BIN path, i.e. I  want the one that points to here (on my machine):

C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\3vu3tp0o.aov\Micro Platforms\default\tools\openocd-0.9.0

In "Arduino 3rd Party Hardware GDB Configuration Guide", the sample platform.txt uses:

tools.gdb.openocd.path={runtime.vm.ide.platforms.path}/default/tools/openocd-­0.9.0

I can't find where {runtime.vm.ide.platforms.path} is pointing to.

I need to know where the "real" openocd folder is as I want to add some cfg files to the scripts folder.

Thanks

Have you switch on "show build properties" then run a build and searched the output?

Yes have done that countless times.  It doesn't expand the paths I am concerned with. 

I can hard code the paths and get it to work but it isn't clear how this will work on other computers I have.  That is why I am looking for the {} paths.

ah so you are testing outside the ide and have not added anything the users the property yet

add this to local board.txt or hardware>platform.txt

pathtest1={runtime.vm.ide.platforms.path}

Then save (rescan if using platform.txt) and build

I *am* testing in the IDE and editing platform.txt.  I am looking for what {runtime.vm.ide.platforms.path} actually points to as it is not where I can find it and it doesn't point to where VM is installing openocd. 

This works if I hardcode the path to:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\3vu3tp0o.aov\Micro Platforms\default\tools\openocd-0.9.0

but not with {runtime.vm.ide.platforms.path}

What I really want is what the equivalent {runtime.vm.xxx.xxx.path} is for the hardcoded path above.

My alternative is to install openocd at C:\openocd so I know for certain where it is and where my scripts are.

it's a runtime property similar to project_name. Platform.txt doesn't contain any full paths they are all runtime.

So add a property as in my example and build and the path will then be in the build output.

I guess I am not making myself clear.  I think I know what it is and how it is a "shortcut" to an actual path. If this is incorrect, please let me know.

On my main development machine the Visual Micro extensions seems to be in:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\3vu3tp0o.aov\...

In there, is the openocd folder where scripts (inc. mine) are stored and the executable lives

The 3vu3tp0o.aov folder is not present on my notebook so the equivalent folder is *somewhere* in the VS Extensions folder.  So, if I want all this to work on any machine where I do development, I want the path shortcut to be transportable and, obviously, hardcoding the path isn't. 

So the question is if I use pathtest1 = {runtime.vm.ide.platforms.path}, what is the REAL path that pathtest1 represents?

I am not making myself clear

pathtest1={runtime.vm.ide.platforms.path}

ADDING THE ABOVE TO PLATFORM.TXT AND THEN BUILDING WILL SHOW YOU, IN THE BUILD OUTPUT, PATHTEST1=????SOME PATH THAT YOU WANT TO SEE ??

If you do as I ask ten inspect the output you will see pathtest= states the path you are asking about.

This does not work.

I even did a project "Clean" and Rebuild to see everything and only the one line in platform.txt where I put the pathtest1={} line shows up. I am attaching the build output so you can see for yourself.

I do see a couple of openocd paths but neither is the one in the VM extension folder.  I also see this line:

vm.platform.root.path=C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\i5drq5bg.rqa\Micro Platforms\arduino16x

Backing up one level, there is a \default\tools\openocd path so possibly this is where the scripts are being search for.

The fact is that I still have no clue which openocd folder is being used and likely the reason I am having trouble and frustration.  I am going to put my own openocd folder at C:\openocd so I know definitively where it is.

---

You are right sorry. You actually need to use a property in a pattern for it to resolve.

The runtime.vm.ide.platforms.path is the "\Miro Platforms" folder below the visual micro program folder you have found.