Tag Archives: netbeans

Netbeans 8.x “Could not get children iterator” or “NULL VALUE RETURNED FOR CHILDREN”

Posted by KarlP on 24 November, 2016 None comments

If you’re getting messages like this when debugging and trying to look at variables, chances are you might be debugging some glib2 code. If you are, welcome to https://bugzilla.gnome.org/show_bug.cgi?id=749092

It’s easy enough to manually patch the file, and presto, working debug again. It’s been fixed in GDB, I was seeing this in Fedora 22, which is not _entirely_ up to date these days, but you tend to expect that plain old host debugging should be pretty stable. blog post because the netbeans error string doesn’t help you find that gdb bug. You need to run gdb on the command line to find the real error: Python Exception iter() returned non-iterator of type '_iterator':

Using NetBeans for STM32 development with OpenOCD

Posted by KarlP on 6 January, 2016 None comments

This post supersedes http://false.ekta.is/2012/05/using-netbeans-for-stm32-development-with-stlink-texane/ it has been updated for 2016 and current best software tools.  Again, this is only focussed on a linux desktop environment.

Required pieces haven’t changed much, you still need:

  1. A tool chain.
  2. GDB Server middleware (OR just a tool flashing if you want to live in the dark ages)
  3. A “sexy” IDE (If you disagree on wanting an IDE, you’re reading the wrong post)

Getting a toolchain

New good advice

Advice here hasn’t changed.  The best toolchain is still gcc-arm-embedded  They steadily roll out updates, it’s the blessed upstream of all ARM Cortex GCC work, and it has proper functional multilib support and proper functional documentation and bug reporting.  It even has proper multi platform binaries for windows and macs.  Some distros are packaging “arm-none-eabi-XXXXX” packages, but they’re often old, repackages of old, poorly packaged or otherwise broken.  As of November 2015 for instance, ArchLinux was packaging a gcc 5.2 binary explicitly for arm-cortex, that did not support the -mmcu=cortex-m7 option added in gcc 5.x series.  Just say no.

I like untarring the binaries to ~/tools and then symlinking to ~/.local/bin, it avoids having to relogin or start new terminals like editing .bashrc and .profile does.
~/.local/bin$ ln -s ~/tools/gcc-arm-none-eabi-5_2-2015q4/bin/arm-none-eabi-* .

Old bad advice

The internet is (now) full of old articles recommending things like “summon-arm-toolchain” (Deprecated by the author even) “code sourcery (lite)” (CodeSourcery was bought by Mentor, and this has been slowly killed off.  Years ago, this was a good choice, but all the work they did has long since been usptreamed)  You can even find advice saying you need to compile your own.  Pay no attention to any of this.  It’s well out of date.

GDB Server middleware

New good advice

Get OpenOCD. Make sure it’s version 0.9 or better. 0.8 and 0.7 will work, but 0.9 is a _good_ release for Cortex-M and STM32 parts. If your distro provides this packaged, just use it. Fedora 22 has OpenOCD 0.8, Fedora 23 has OpenOCD 0.9. Otherwise, build it from source

Old bad advice

Don’t use texane/stlink.  Just don’t.  It’s poorly maintained, regularly breaks things when new targets are introduced and not nearly as flexible as OpenOCD.  It did move a lot faster than OpenOCD in the early days, and if you want a simpler code base to go and hack to pieces for this, go knock yourself out, but don’t ask for help when it breaks.

Netbeans

No major changes here, just some updates and dropping out old warnings.  You should still setup your toolchain in netbeans first, it makes the autodetection for code completion much more reliable.  I’ve updated and created new screenshots for Netbeans 8.1 the latest current release.

First, go to Tools->Options->C/C++->Build Tools and Add a new Toolchain…

Adding a new toolchain to netbeans

Adding a new toolchain to netbeans

Put in the “Base directory” of where you extracted the toolchain.  In theory netbeans uses the base directory and the “family” to autodetect here, but it doesn’t seem to understand cross tools very well.

Base path for new toolchain and name

Base path for new toolchain and name

Which means you’ll have to fill in the names of the tools yourself, as shown below.  Click on “Versions” afterwards to make sure it all works.

Adding explicit paths to netbeans toolchains

Adding explicit paths to netbeans toolchains

“Versions” should show you the right thing already, as shown

Versions from our new toolchain (and an error from gdb we must fix)

Versions from our new toolchain (and an error from gdb we must fix)

If you’re getting the error about ncurses from gdb, this because newer gdb builds include the curses “tui” interface to gdb in the standard build.  (Yay! this is a good thing!)  However, as the g-a-e toolchains are all provided as 32bit, you may be missing the 32bit ncurses lib on your system.  On Fedora, this is provided in the ncurses-libs.i686 package.

Ok, now time to build something.  This is your problem, I’m going to use one of the libopencm3 test programs right now, specifically, https://github.com/libopencm3/libopencm3/tree/master/tests/gadget-zero (the stm32l1 version)

Programming your device

Netbeans doesn’t really have any great way of doing this that I know of.  You can use build configurations to have “run” run something else, which works, but it’s a little fiddly.  I should spend more time on that though.  (See later for a way of doing it iteratively via the debugger console in netbeans)

In the meantime, if you just want to straight out program your device:

$ openocd -f board/stm32ldiscovery.cfg -c "program usb-gadget0-stm32l1-generic.elf verify reset exit"

No need for bin files or anything, there’s a time and a place for those, and if you don’t know and can explain why you need bin files, then elf files are just better in every way.

Debugging your part

GDB is always going to be a big part of this, but, assuming you’ve got it flashed, either by programming as above, then you can debug in netbeans directly.  First, make sure OpenOCD is running again, and just leave it running.


$ openocd -f board/stm32ldiscovery.cfg

First, install the gdbserver plugin, then choose Debug->Attach Debugger from the menu.

Attach to a gdbserver

Attach to a gdbserver

  • Make sure that you have “gdbserver” as the debugger type.  (Plugin must be installed)
  • Make sure that you have “ext :3333” for the target.  By default it will show “remote host:port” but we want (need) to use “extended-remote” to be able to restart the process. (See the GDB manual for more details)
  • Make sure that you have the right project selected.  There’s a bug in the gdbserver plugin that always forgets this.

At this point, “nothing” will happen.  If you look at the console where OpenOCD is running, you’ll see that a connection was received, but that’s it.
Press the “Pause” button, and you will stop execution wherever the device happened to be, and netbeans will jump to the line of code. In this example, it’s blocked trying to turn on HSE, as there’s no HSE fitted on this board:

Source debugging in netbeans via OpenOCD

Source debugging in netbeans via OpenOCD

If you now set a breakpoint on “main” or anywhere early and press the “Restart” icon in the top, OpenOCD will restart your process from the top and stop at the first breakpoint. Yay!  If restart fails, make sure you used “extended-remote” for the target!

Bonus

If you click the “Debugger console” window, you can actually flash your code here too.  Leave the debugger running!  (No need to stop the debugger to rebuild) Make a change to your code, rebuild it, and then, on the “Debugger console” just enter “load” and press enter.  You’ll see the OpenOCD output as it reflashes your device.  As soon as that’s done, just hit the “Restart” icon in netbeans and start debugging your new code!

Using netbeans for STM32 development with stlink (texane)

Posted by KarlP on 3 May, 2012 1 comments

So, You got a STM32 Discovery board hey? Good for you! They’re cheap, and highly functional, but this ain’t your grandmother’s Arduino.

Here’s a rough and ready howto for developing in netbeans, and getting source level debugging for that code.

Required pieces

GNU arm toolchain installed and working.

I use summon-arm-toolchain for this. To test that it’s working, you can try any of the following:

You want to make sure that you can successfully compile via make from the command line first. If you can’t compile with the raw tools, netbeans isn’t going to magically fix that for you.

texane/stlink

A confusing name, but so be it. stlink (the software tool) provides tools for flashing STM32 chips via ST/Link v1 and v2 hardware. It also provides a gdbserver for debugging those chips. Get it from github (Sorry, there’s no tagged releases or anything yet, though there really should be)

Netbeans

Duh, this post is covering that. You need the c/c++ plugin and the gdbserver plugin. Download it here. For reference, I’m using 7.1 at the moment.

Setting up the toolchain in netbeans

  1. Click Tools->Options->C/C++
  2. Click on “Add” and set up a new toolchain for arm development. See the screenshot below
    Netbeans add tools dialog for gnu-arm

    Netbeans add tools dialog for gnu-arm

  3. Import your project as a makefile based project from existing sources. You can get netbeans to actually do all the compiling and things for you, but I find it hard to share the project that way. Not everyone uses netbeans, but makefiles are pretty portable.
  4. Build your project
  5. Flash your binary to the target. You can actually do this anyway you want, but we’ll use stlink’s st-flash tool. 
    $ arm-none-eabi-objcopy -O binary your_project.elf your_project.bin
$ /path/to/stlink/flash/st-flash write your_project.bin 0x08000000

    Here’s a screenshot from my makefile. (You can set up run modes in netbeans to do this too, but that’s not the focus here)

    console log for make and upload via stlink

    make and upload via stlink

  6. Start stlink’s gdbserver. 
    karlp@tera:~/src/stlink$ ./gdbserver/st-util 
2012-05-03T20:44:56 INFO src/stlink-common.c: Loading device parameters....
2012-05-03T20:44:56 INFO src/stlink-common.c: Device connected is: L1 Med-density device, id 0x10186416
2012-05-03T20:44:56 INFO src/stlink-common.c: SRAM size: 0x4000 bytes (16 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 256 bytes
Chip ID is 00000416, Core ID is  2ba01477.
init watchpoints
Listening at *:4242...
  7. Whew, ok, just about there. Now in netbeans, choose “Debug->Attach debugger”.
  8. Choose “gdbserver” and make sure you put in the right host and port, (normally localhost, and 4242) and make sure it’s set to debug your project.
    screenshot for netbeans gdbserver attach dialog

    gdbserver-attach

  9. MAKE SURE you have set at least one breakpoint first. Something in netbeans doesn’t like adding breakpoints while it’s running, and it doesn’t like pressing the pause button. (but see the footnotes)
  10. Profit…
    screenshot showing netbeans Source debugging STM32 via stlink gdbserver

    Source debugging STM32 via stlink gdbserver

    11. That’s it. If any of the steps are glossed over too much, mail me and I’ll try and update to clarify.

    Sidenote: If you didn’t set any breakpoints in netbeans first, or you pressed pause, or you double clicked in the gutter to add some breakpoints, and nothing happened, you’ve hit whatever weirdness is in the gdbserver plugin. This problem is reported with other stm32 gdbservers, so it doesn’t appear to be a problem with stlink, but with netbeans. You can wake up netbeans again with kill -INT $(pidof arm-none-eabi-gdb)
    Thanks to gsmcmullin on ##stm32 on irc.freenode.net for that gem.

    Update for netbeans 7.2: Apparently you now have to put “target localhost:4242” into the gdbserver box, not just “localhost:4242”.

netbeans debug gdbserver: “Invalid argument”

Posted by KarlP on 3 April, 2012 None comments

I was trying to do some remote debugging via gdbserver the other day, using netbeans. I knew I’d had this working before, but I kept getting a rather bizarre (to my mind) error dialog:

I could connect happily via gdb on the command line, and on a whim I tried a different project in netbeans, which worked as expected. A bit more thought, and some comparison in the project properties showed up what was missing, the name of the binary output built for this project. After filling it in again everything works just fine :)

(This is with Netbeans 7.0.1, we won’t get into why it didn’t detect from the Makefile what the binary output was, when it runs quite fine in the non-cross configuration)

Early impressions with PyDev 2.2 and Eclipse 3.7

Posted by KarlP on 17 August, 2011 1 comments

I’ve been happily using netbeans for C/C++ and python work, which works well enough to not really complain much. Mostly, I want IntelliJ for C code. I find eclipse big and clunky and awkward on the keyboard, and just generally a pain. No Eclipse, I do NOT want to have some sort of “workspace” I want you to just leave things where they are on the disk. Anyway, in Oracle’s infinite wisdom, they are continuing to destroy things that Sun built, and python support has been dropped in netbeans 7. A pity, as netbeans 7 added some nice debugging support for C/C++, and netbeans is much more tightly integrated than eclipse. Still a pale shadow of IntelliJ, but I digress.

So, I had to go and look for some alternative python editors. I’m currently trying out PyDev 2.2 with Eclipse 3.7. It mostly works ok too. It’s capable of running some unit tests, and has the basic highlighting and so on. However, it’s completion is not as good as I would like, nor think it should be. Take this for example.

def something(self):
    self.mylist = []
    # on this line, self.mylist. will give me the full builtin completion for lists
    self.otherlist = "blah blah".split()
    # split returns a list, but self.otherlist. has no completion here

It seems this can be worked around by “pre declaring” the type.

def something(self):
  self.somelist = []
  self.somelist = "blah blah".split()
  # self.somelist. produces full completion for list here....

This is…. odd?

Possibly related is that in python unit tests, I at least, normally use the self.assertEquals(left, right, msg) form, probably because I came from Java. However, self.assertEquals in PyDev doesn’t give me any completion guidance on the parameters at all. It turns out that in the implementation of python’s unittest, assertEquals is simply an alias for another function (assertEqual = assertEquals = failUnlessEqual) For whatever reason, this means that I get full completion and parameter help if I use the _real_ implementation, failUnlessEqual but no advice/help whatsoever if I use the assertEquals form.

Google says this is unhelpful.

  • “self.assertEquals python” returns 74300 results
  • “self.failUnlessEqual python” returns 35800 results

Update: this assertEquals vs failUnlessEqual is apparently only a problem for python < 2.7. Unfortunately debian stable (squeeze) at present still uses python 2.6 :( In more mundane items, I would _really_ like to know how to get IntelliJ's "ctrl-W" shortcut, for expanding a selection. (From the cursor in the middle of "karl" in the following line, 'self.wop = "this is karl in python".split()', pressing ctrl-w once would highlight 'karl', once more would select 'this is karl in python' (without the quotes), once more with the quotes, and then on to the entire rvalue, then the entire line. This stackoverflow post mentions a solution, but it doesn’t seem to work in PyDev windows, even after getting into the keymap and adding a “Select Enclosing Element” for the PyDev views (or the editor scope? the difference being?) it still doesn’t work.

Oh well, life goes on.