Saturday, October 21st 2017, 6:58am UTC+2

You are not logged in.

  • Login
  • Register

Dear visitor, welcome to SEGGER Forum. If this is your first visit here, please read the Help. It explains how this page works. You must be registered before you can use all the page's features. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

v01d1

Beginner

Date of registration: May 29th 2017

Posts: 27

1

Monday, May 29th 2017, 10:22am

[ABANDONED] restarting debug session on Cortex M4 on Vybrid VF61x

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.

SEGGER - Niklas

Super Moderator

Date of registration: Oct 6th 2014

Posts: 1,684

2

Friday, June 2nd 2017, 8:52am

Hi,

Quoted

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


Well, that does not sound promising for what you are trying to achieve.
Could you please point me to the section of the documentation where this is mentioned?
What happens if the applications itself changes the flash contents(self-modifying code)?


Best regards,
Niklas
Would you like to be added to the J-Link software update notification list, so you get informed automatically when a new version becomes available?
Just write me a PM or in case you want to subscribe to it yourself, please use this link: Link
Notification for J-Link, J-Link Debugger, SystemView & J-Scope: Link
Notification for Embedded Studio: Link

v01d1

Beginner

Date of registration: May 29th 2017

Posts: 27

3

Wednesday, June 14th 2017, 8:48am

Hello,

Quoted

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).

Quoted

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

:wacko:

v01d1

Beginner

Date of registration: May 29th 2017

Posts: 27

4

Thursday, June 15th 2017, 7:44am

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?

SEGGER - Erik

Super Moderator

Date of registration: Dec 20th 2011

Posts: 387

5

Thursday, June 29th 2017, 2:45pm

Hi,

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.

Quoted

New code does not run, unless I do _full system restart/reboot__.
What do you mean with full system restart / reboot? Power-on-reset?

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

Source code

1
2
3
4
5
6
7
8
9
10
11
void main(void) {
  int Cnt;
  
  Cnt = 0;
  do {
    Cnt++;
    Cnt++;
    Cnt++;
    Cnt++;
  } while (1);
}


Best regards
Erik

v01d1

Beginner

Date of registration: May 29th 2017

Posts: 27

6

Friday, June 30th 2017, 4:04am

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

Quoted

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)

Quoted

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?

Quoted

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.

v01d1

Beginner

Date of registration: May 29th 2017

Posts: 27

7

Wednesday, July 5th 2017, 12:43pm

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.
v01d1 has attached the following file:
  • seggerlogs.7z (425.06 kB - 33 times downloaded - Last download: Oct 18th 2017, 10:30pm)

SEGGER - Erik

Super Moderator

Date of registration: Dec 20th 2011

Posts: 387

8

Friday, July 7th 2017, 4:06pm

When I compare the log file from the "bad session" against the log file from the "good again session" (I refer to it in below description with "good session"), I see that the GDB tells the J-Link GDB Server to set a different number of breakpoints. Can you explain this behavior? 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. However this should not make any differences. According to the log file, the following happens:

1. Reset (PC == 0x0000F4B8)
2. Application download --> Verified O.K.
3. Go()
4. BP @ 0x3F00C35C reached
5. Remove BP @ 0x3F00C35C
6. Go()
7. BP @ 0x3F0054AC reached
8. Remove BP @ 0x3F0054AC
9. Go()

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)

Good session:
03-00000000-00-00037991-002A: ...Breakpoint reached @ address 0x3F003710

Bad session:
03-00000000-00-00038649-0024: Debugger requested to halt target...
[...]
03-00000000-00-00038668-0022: ...Target halted (PC = 0x3F00D522)

--> The target behaves different although the same data have been downloaded and verified O.K. AND exactly the same steps have been executed. This indicates that the CPU is in a different state. I assume the following: CPU is not in a clean state after reset and the code is not able to handle this "unclean" state and therefore behaves different. Example: The startup code configures the PLL and assumes that the PLL is not enabled yet. If the PLL is not in reset state but already initialized, the code may assumes incorrect states and therefore writes data which causes the CPU to crash / hang.

Please note that from J-Link perspective everything is working / executed just fine as expected.

We would recommend to strip down the project (as already suggested in my previous post) and check if the behavior is still the same. I would assume it is not. From there on, i would extend your application until the issue pops up again. If you can tell us what causes the issue, we can check if we may can improve the J-Link software somehow.

Overview of the breakpoints:
Bad session:
0x3F0036A6 (not set in "good session")???
0x3F003710
0x3F0054AC
0x3F00C19C
0x3F00C35C
0x3F00EA80

Good session:
0x3F003710
0x3F0054AC
0x3F00C19C
0x3F00C35C
0x3F00EA80


Best regards
Erik

v01d1

Beginner

Date of registration: May 29th 2017

Posts: 27

9

Sunday, July 9th 2017, 2:10pm

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.

Quoted

.. 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. ..

Quoted

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.