The Netduino forums have been replaced by new forums at community.wildernesslabs.co.
This site has been preserved for archival purposes only
and the ability to make new accounts or posts has been turned off.
I'm still working through confusing errors trying to get a Visual Studio project to run.
(Removed this, because I just found similar problems with the official download. So it's apparently some mis-configuration of MSVS10 when I went back to QF1. Will pursue -- sorry for crying wolf again. Problem is: if I investigate for hours to be sure, I may be missing something that would be obvious to someone else.)
(Keeping this, because inquiring minds want to know):
If nothing obvious surfaces, I'll probably try JTAG debug. ziggurat29 (I thought you signed one post "dave"), I notice you said you use GDB with OpenOCD (still waiting for membership approval at the latter forum; so I can download). Is this now command-line, or through Eclipse as you'd said before?
can't say for sure about your vs2010 problems going back-and-forth because I havne't tried yet. My only guess at a suggestion (if it's not immediately obvious) would be do remove the .netmfqfe2 sdk, and the netduino sdk, and install the versions of qfe1 (and for the netduino 4.2.1, which is qfe1 based). But maybe that's overkill.
I did not complete the eclipse setup of jtag because I was having initial problems with my openocd config so I needed to get closer to the wire to reduce the number of variables. Once I got there, I just plugged along with gdb. You're welcome to the config and a couple batches I used to setup, if interested. I might go back to trying to configure Eclipse at some point, because automating the gdb is certainly nice.
I don't remember needing to join a forum to download openocd, though. I might have gotten a build off of freddie chopin's site. It was named openocd-0.6.1.zip. The binaries worked fine for me, and I just made a board script (which really was just copied from the existing stm32f4discovery.cfg)
I was able to resolve the problem -- all Visual Studio and Secret Labs nonsense. Once I'd resolved the problems using the official download, then I reloaded the firmware I had built 2 days ago using your additions and procedure. It compiles and debugs a blinky just fine. I posted the details here, because it sounded like they were having related problems.
I'll let you know if I see any problem with low-level serial port access (the main reason I needed interop) or network. Otherwise I don't see any more roadblocks. Whew!
Yes, I plan to do JTAG debugging soon; so please send me anything convenient. I'll be glad to do some writeups, etc. on them if you don't have time; this was a big help to me.
sure; re: jtag. I didn't do anything terribly complicated, but here is all of it FWIW:
* I installed a prebuilt openocd-0.6.1 version. Maybe I got it from sourceforge? The file I downloaded was openocd-0.6.1.zip. I installed to:
* Happily, I didn't do anything fancy with the configuration. I just made some config scripts I found handy.
in 'C:openocd-0.6.1scriptsboard' I created 'netduinoplus2.cfg'. This was simply a copy from 'stm32f4discovery.cfg' and I didnt' edit anythng, but I made a separate file nonetheless in case I did need to edit something (but I never did).
# This is for the Netduino Plus 2, which I simply copied from stm32f4discovery.cfg# This is an STM32F4 discovery board with a single STM32F407VGT6 chip.# http://www.st.com/internet/evalboard/product/252419.jspsource [find interface/stlink-v2.cfg]source [find target/stm32f4x_stlink.cfg]# use hardware reset, connect under resetreset_config srst_only srst_nogate
Then, in the 'root' of my project directory (which happens to be 'C:Experimentsnetduinonetduino_plus_2', I created a batch to start up openocd, which I named 'startOpenOCD.bat':
title OpenOCD to netduinoplus2C:openocd-0.6.1bin-x64openocd-x64-0.6.1.exe -f board/netduinoplus2.cfg
Then, in that same 'root' directory, I create a batch to startup gdb, called 'startGDB.bat':
title gdb for arm tinyclrarm-none-eabi-gdb.exe -x gdbinit.txt C:Experimentsnetduinonetduino_plus_2BuildOutputTHUMB2GCC4.6leFLASHreleaseNetduinoPlus2bintinyclr.axf
the interesting thing that took me a while to understand is that the *.axf (ARM eXecutable Format) file is actually just an ELF file with DWARF info, so gdb can take it as-is.
That batch uses a startup command file, called 'gdbinit.txt':
set remote hardware-breakpoint-limit 6set remote hardware-watchpoint-limit 4target extended-remote localhost:3333monitor reset halt
which gives gdb some useful advice, and also tells it to reset the board like it just powered up.
So, to do debugging, I did this hardware action:
I plugged in my STLinkv2 to the computer
then I connected the STLink to the adapter board
then I connected the 10 pin micro idc to the Netduino Plus 2
then I connected the netduino plus 2 to the computer via usb. Or powered it from power supply, whichever.
Then this software action:
start 'startOpenOCD.bat'. If it immediately exits, that means it couldn't talk to the stlinkv2. Re-check all that; maybe repeating the hardware connect sequence. When it does work, you should see a 'dos box' window running the openocd monitor, and it should be 'quiescent', i.e. no incremental output, especially no continuous output indicating that it is trying to connect. If that happens, shut it all down and restart the process of connecting the hardware and starting the software. It will work! Just not always, alas.
Then start 'startGDB.bat' This will open an interactive gdb prompt, and is where the work will be done. Ostensibly, if you get Eclipse working, then you wouldn't do this because eclipse would be driving. But I did it manually. The command script I gave will be executed, and it will do a hard reset of the board and put it in a halt state, so you can start single stepping the boot process.
The first part is in TinyBooter. You don't have the proper source for that since we told gdb about tinyclr. Take it as read that TinyBooter works, and whiz through to the start of TinyClr, with this:
You'll whiz through and stop at the very start of your built firmware. Symbol names (for functions) will be meaningful now, so you can use them for your breakpoints instead of addresses.
It's a little slice of Hell to use gdb from the command line, but I found 'tbreak' 'disassem' 'info registers' and 'si' and 'ni' and 'finish' to be oft-used. Occaisionally 'bt' but you have to take the output with a grain of salt. If you're a noob as I am, then get the GDB Quick Reference pdf off the web. If you can get Eclipse configured to step through the firmware, then you win the Magic Cookie. I had to stop messing with Eclipse early on because I didn't know if I had my ocd straight, and by the time I did, I had mostly solved my problems, so I never got back to the Eclipse config. But if I had to debug again, I'd give my kingdom for an gui interactive source level debugger.
Also, I found the STLinkV2 to be quite twitchy, and prone to giving up the ghost easily. Or maybe you can blame OCD, but many times Id find my gdb non-functioning, and see in the openocd window that it had gone into some 'lost connection, reconnecting' cycle. When that happens, you have to shut down the software, unplug the USBs, and go through the hardware reconnect and software bringup again. Yay! I like wasting time! Separate note, this seems to happen for me anytime USB re-enumerates. I.e., if the board reboots and goes through the USB enumeration procedure, it tends to hose my STLink connection. E.g., if I am debugging via jtag while I am also connected via visual studio and deploying software (which will cause the board to restart). This rather puts a damper on debugging into that stuff effectively, alas....