I've been using this for a year and just as a warning to others, here are the issues I had:
1) Reset isn't toggled. Only recently figured this out. There's a "reset strategy" that is configurable for some processors but doesn't seem to be for Pic32. (stuck at 0). Without reset, you get resets via software however the external-to-the-core blocks will be in an indeterminate state. That means OSC sometimes won't come up. Random interrupts may be enabled, random shadow sets may be selected, etc. This has caused untold pain for me.
2) The act of watching (accidentally or otherwise) null pointers, bad pointers, or pointer members of a struct that haven't been initialized will vector into an exception. This was reported to Segger a year ago but no fix a year later.
3) Stale/bad data in watch windows/memory dump.
These issues make debugging nearly impossible.
I tried the GUI debugger also offered by SEGGER, but with a clean install it just is plain broke. The issues are too numerous to go into, but even having a valid register definition file seems to have leaked through QA.
Posting in the forums yields crickets. Not sure why that is, since posts before and after mine are happily answered. Maybe I'm blacklisted
I have gotten fed up with this stuff. And having migrated from Microchip's broken tools it leaves me wondering: How is anyone developing on Pic32? Sure, simple stuff works. But try to use the chip to any meaningful degree. What ever happened to quality control and/or support?
To get around this, I have written my own GDB stub (serial server). It's about a week long project if you are curious. All my issues are fixed. Why is it that I can take a week and write a working debugger tool while these companies can't? Makes you wonder. The nice thing about this is you can add things like threads and the ability to look into custom memory areas over on-chip peripherals. It's super flexible and I wish I did this earlier.
Just my $.02
1) Reset isn't toggled. Only recently figured this out. There's a "reset strategy" that is configurable for some processors but doesn't seem to be for Pic32. (stuck at 0). Without reset, you get resets via software however the external-to-the-core blocks will be in an indeterminate state. That means OSC sometimes won't come up. Random interrupts may be enabled, random shadow sets may be selected, etc. This has caused untold pain for me.
2) The act of watching (accidentally or otherwise) null pointers, bad pointers, or pointer members of a struct that haven't been initialized will vector into an exception. This was reported to Segger a year ago but no fix a year later.
3) Stale/bad data in watch windows/memory dump.
These issues make debugging nearly impossible.
I tried the GUI debugger also offered by SEGGER, but with a clean install it just is plain broke. The issues are too numerous to go into, but even having a valid register definition file seems to have leaked through QA.
Posting in the forums yields crickets. Not sure why that is, since posts before and after mine are happily answered. Maybe I'm blacklisted
I have gotten fed up with this stuff. And having migrated from Microchip's broken tools it leaves me wondering: How is anyone developing on Pic32? Sure, simple stuff works. But try to use the chip to any meaningful degree. What ever happened to quality control and/or support?
To get around this, I have written my own GDB stub (serial server). It's about a week long project if you are curious. All my issues are fixed. Why is it that I can take a week and write a working debugger tool while these companies can't? Makes you wonder. The nice thing about this is you can add things like threads and the ability to look into custom memory areas over on-chip peripherals. It's super flexible and I wish I did this earlier.
Just my $.02