Using J-Link / GDB, I'd like to change the reset behavior from the default (doesn't toggle reset) such that it toggles reset.

I'm using Pic32/2-wire but this shouldn't matter. The default behavior that has been shipping for the past year doesn't toggle reset. This causes untold issues with the Pic32.

Anyone?

First lesson: never trust microchip's docs. I can tell you with absolute certainty that the method you are describing does not fully reset the Pic. It may reset the licensed mips core but not microchip's external blocks (at least not reliably). Without a toggle of MCLR things can get in an indeterminate state on reset. This includes the current shadow register set, oscillator, interrupt flags among other issues. Maybe it's a bug in your implementation but it happens on 2 of their dev kits plus my own boards.

Clearly it's possible to fix because microchip's realice does the toggle and is able to halt at main. Have you considered dropping a breakpoint in flash then hitting MCLR?

I don't know what the ultimate fix will entail but without toggling this line your product is very flaky when used with this processor.

In the meantime, I'd be very happy if you could give me an idea on how to make J-Link toggle reset. That would fix me since I have a break instruction at the top of main.

With all respect, let me explain why this isn't right...

"toggling MCLR can have bad side effects on the debug side because the debug logic may also be reset by this reset, [...]

Why this assertion is wrong:

1) A competing programmer RealICE (From Microchip) does this exact thing. So you are telling me it has bad side effects yet I have an example showing this method to work.

2) I can toggle MCLR using a script in J-Link commander, combined with a breakpoint instruction in main and it also works.

You say: "This is currently not possible."

It is possible because I have a script that does it running in your tools. It's just not done through the "reset strategy" which makes it a bit of a hack.

You also say: "This may work for 1 setup but will break others."

Okay, I'll give you this. But J-Link presents itself as a flexible, configurable programmer. But that is misleading because you won't let users configure reset behavior that is clearly possible. Leave the default the way you have it (which is broke), and let the user set it to toggle if they want.

But that aside, it WON'T break others because the official programmer from microchip does it this way.

As I've said in other posts, my experience with J-Link/Pic32 has been very tough over the past year due to this and other issues that don't seem to be getting addressed. I was forced to look for other options because I used RealICE / External memory and Microchip had issues with that (plus their tools were just generally terrible). So Segger/Jlink was the only option I could find.

I find it just pretty darn confusing that tools are in such a broken state for this platform. I can understand SEGGER's situation in that there is not much demand as you say, but it's sort of a self perpetuating problem. Microchip really has no excuse releasing not only such buggy tools , but such buggy silicon. So I suppose this is why you see such few customers on this platform. But if you want to claim Pic32 support, many customers or not, I think it's misleading to tell people it is supported when you don't handle reset like the official programmers, not to mention the other issues I've tried to report over the past year that don't seem to get much attention.

So when I tell you it's broke, that's all I can do. It's your company and product so you can clearly chose to trust or distrust this feedback and not implement it. But I wanted to at least give you some feedback.

I've now had to write my own GDB stub which does all the things I've mentioned and now I'm up and running. I just find it sad that I had to spend time doing this when there are so many companies saying they support Pic32 yet all the choices seem broke in some way or another.

I thought for sure this would have stirred some debate with the folks at Segger. No?

I love how I have to debug on my target. I had to make a custom "run configuration" in eclipse that:
1) Launch my reset-hack script
2) Launch the J-Link GDB server
3) Launch a debug configuration that only programs my board and exits....
4) Kill the gdb server because it is now angry I violated the segger rule of no resetting
3) Launch a debug configuration that connects to my serial port GDB stub.

After all this I get a "one click to run"... It amazes me that with my Pic32MZ I had to do all this rube goldberg nonsense to finally get some develompent done.

And to anyone thinking this is crazy, try using Microchip's tools. They fall apart if you try to use the EBI bus to debug external memory. That's where most of my stuff is located. Stack, program, you name it. Been waiting over a year for them to fix that. Meanwhile, J-Link has been more or less a savior. Save the crashing constantly due to TLB exceptions which I guess is better than not working at all. Finally the bugs became too frequent, especially due to the random processor state based ghost bugs due to the reset not getting toggled... and now I am forced to only use J-Link to upload code, and now use my own GDB as I said.

What year is this? 1953? I blame open source for creating such a mess of software and QA.

The above post shows some crazy stuff I had to script up to get to the point of debugging on the Pic32 with J-Link. I managed to figure out how to do this with far fewer hacks...

Now my list is...

1) Build with gcc/eclipse toolchain
2) Post build step to convert .elf to .hex ( using xc32-bin2hex.exe )
3) Upload/Program with MPBAB IPE
4) Debug with my GDB serial stub

This works GREAT. Unfortunately for segger, I now no longer need/use their product.

Step 3 has me using RealICE (competitor's product) with the "IPE" GUI. This programmer does the proper thing that SEGGER refuses to fix : Reset the CPU after programming using the /MCLR line.

My goal for the past year was to get past all these TLB exceptions, random behavior, and lack of support for advertised-yet-unsupported external memory. Now I have achieved this.

SEGGER: Don't claim support for a processor when you don't fix bugs. This is worse than making no product at all and functions as a "developer landmine". I've lost a few fingers and a foot from your 95% complete product.