I'm struggling with reloading and restarting the debug session on my VF61x ' Cortex M4.
After fresh restart from power on, the firmware uploads and the system starts running properly.
If I hit restart button (in Eclipse it's the "restart debug target without terminating & re-launching"), then it seems mostly works, but this is restarting same code.

If I make changes and do a rebuild, then I need to terminate current debug session, and then start debug session a new (in Eclipse the green bug icon).
Now this does not work. The code seems to get uploaded, and I may get main() entry point, but after that things don't work: break points do not work, and the code appears to run wild, don't know what it does.
The only way to fix this is to power cycle the SoC. This is of course not nice at all, and time wasteful, considering that by doing this you kill whatever is running on the A5 side at the moment ( :cursing: )

I hope to get some help with this, and so got some questions.

1. Is it possible to cleanly restart the debug session on the M4 with J-Link without resetting the entire SoC? The Vybrid manual says that when the system is already running, you cannot reload the firmware and restart the M4 without resetting
the whole chip with A5 too. But I'm not clear on if this applies for case when you have JTAG connection to the M4. [I'm really hoping Segger guys will clear this up for me ! ] (Dunno, to me sounds crazy you would have to completely reset the thing)

2. What shall be the Initial Reset & Halt reset strategy be set to? Mine set to 0/default, and if I'm not mistaken, Segger's doc says this is the only supported strategy for the target. (I have tried other numbers, with no changes noticeable).

3. The Eclipse's restart button and kill debug session followed by start a new, appear to be doing the same thing, re-uploading the code on the target and trying to restart it. (Probably because I have option "supports debugging from RAM" in Elipse on. The linker puts the firmware image to SRAM). Also every upload/restart is followed by Pre-run/Restart reset, which again, I have set to reset type as 0.
Is this correct?
During this reset I have to find vector table and set the sp right. Anything else missing?

In both cases in Eclipse - restart without terminating & relaunching , and full stop, followed by debug start - it seems the steps executed are same: reset, upload code, reset again, set some registers right, go, break at main.
But yet full stop (with terminating) followed by start again does not work as I wrote, have to kill the target entirely.

Any help with this would be appreciated.

Hello,

Could you please point me to the section of the documentation where this is mentioned?

I do not believe it's explicitly stated like that, it should (I'm saying should because I cannot believe it's like that) become apparent from reading a few sections, according to Vybrid forum.

See Chapter 7.
7.5.11 Running Secondary Core. From there it may seem all good, you load entry point, argument, and enable auxiliary core clock to make it run. Ok, but how do you now restart just this core
And here to be honest I'm not clear, I had to try clear out things from reading chapter on resets, and looking at what others post on Vybrid forum.

Looking at 7.2 Reset, Reset sources, Reset Functions, the SRC (system reset controller), it's not clear if it's possible to reset just one core.For example any watchdog reset, like A5, or M4, ends up in SRC and resets the entire device. I cannot see anywhere mentioned resetting just one or the other core, only system reset.It seems anything that goes through SRC as a reset, and not configured as an interrupt, will eventually reset the device.

See table 7-7. and below. JTAG Reset is a Functional Reset. How do you get from this Functional Reset to just resetting M4 core, keeping rest running?
I really hoped that since you guys Segger are experts on JTAG, you could explain how this works.And if restarting debug session without resetting whole system can work ..

So far as I explained before, if I try to (re) start debugging modified code with Segger JTAG, it's seems like something gets uploaded, and the M4 seems to re-start running without affecting A5, but the code does not run probably, it bombs out somewhere and all weird things happen (no break points, etc).

What happens if the applications itself changes the flash contents(self-modifying code)?

No idea ...

Hello Niklas,

I did a little more testing while debugging with Segger. ( For now I don't care if you cannot re-start the M4 core without hardware debugger ).

So what I have is, after fresh system startup and first M4 image upload and code running fine:

- I can re-start debug target without terminating debug session fine, the M4 code restarts from beginning and works fine
- I can terminate the debug session closing debugger connection to M4, and then re-start the debug session, which starts with uploading same M4 code image and then runs the code,
this works fine too; but
- I _cannot_ re-start debug session (terminate, restart) after updating / modifying the M4 code: it gets uploaded, and I can start M4 after it's halted, however the code does not run normally,
the system can get stuck in various places, like repeated ISR handling, not allocated variables, un-cleaned variables, etc..
New code does not run, unless I do _full system restart/reboot__.

Any ideas please ?? What can be going on?

Hi Erik,
Thanks for getting back to me on this.

What do you mean with full system restart / reboot? Power-on-reset?

I execute reset on U-boot running on the other A5 core. That executes watchdog A5 reset, which should (per Vybrid manual as I read) execute full system reset.
(Power on reset would work too of course)

Can you please send us a J-Link log file of a) a session which is working as expected (after code has not been changed) and b) a session after changing the code where the described behavior pops up.

Ok, I need to set this up.
The J-Link log, you refer to the J-Link log from JLinkGDBServer?

Are you able to reproduce the behavior with a striped down project (see example below)?

I would have to try... I'm a bit un-sure on your test case, as this is too simple. Why? Because relatively, my project based on the RTOS which initializes few drivers and internal peripherals..
There could be chance that debug core reset does not reset properly those peripherals.. (i'm not sure on this). [I'm sorry i hoped you would help me clear out those details]

Anyway, I need to try your test case. I'm thinking of modifying this to the RTOS based setup with just one task doing the code you gave.

Hi Erik,

Here are some logs, see attached archive.

Inside are 3 files:
1. m4_seggerlog_good_session.txt : when you just started M4 debugging after 'fresh' restart, and things work as I described in thread..
2. m4_seggerlog_bad_session.txt : when you stopped previous session (logged in 1.), changed code, and restarted debugging. This is the broken session as per description in my thread
3. m4_seggerlog_good_again_session.txt : when I've reset the SoC, and upload / start debug session with same binary as in session (2.) log, but now things work. As per my description originally..

Please let me know if you able to spot anything.

Hi Erik,

Thanks a million for taking time to look at logs, and the observations & suggestion. I will take the course of action as you suggest: stripping down to minimal, and see if I can narrow down the init problem.

.. In the bad session, GDB tells the J-Link GDB Server to set 6 points while in the good session it tells to set just 5 breakpoints. ..

So far, both log files look similar apart from the one breakpoint which should not make any differences.
10. "good session": BP @ 0x3F003710 reached
10. "bad session": BP @ 0x3F003710 not reached but debugger request to halt the target instead (CPU halted at PC == 0x3F00D522)

For the different number of bk points: I probably set one extra bkpt in bad session, earlier in the code, in the hope that it _will_ hit it, unlike later points, which it does not.

So the second part you highlight, in bad session the break-point in question is not reached for whatever reason as the system is lost already, and I'm trying to locate where in the code it's lost, so just hit the halt/ Suspend /debug pause.
That I think is what you highlighting above.
(That is consistent with my original post, where I write in bad session, my usual break points 'do not work' .. Which most likely means the code is stuck before that somewhere / system is gone for a walk).

I will have to spend some time see if I can isolate where is that problematic system early init. Your suggestions make sense.. Somehow I hoped that it's some Jlink init parameter that I miss which will magically solve this..

Thanks again and I will report on the problem if/ when I find it.