Watchpoint unstable in v11.2.1, debug with J-Link Segger Edu probe attached to KV31F

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Watchpoint unstable in v11.2.1, debug with J-Link Segger Edu probe attached to KV31F

Jump to solution
1,208 Views
luis-martinez
Contributor III

Hi there,

Any comments about watchpoints in v11.2.1?

I have a VM running W10 and MCUXpress0 v11.2.1 up to date (completely fresh install, only for this use). I'm testing modifications of blynky led program (systick timers) to check if I can use this technique  to measure execution times of other functions (not in test yet),... 

Two days ago watchpoints where working well stopping the program when (default) only memory writes or  when writes a expected data,... 
From this moment to now (unknown the reason) I have no way to trigger it in a consistent way, some times seem not trigger at all,  some times seem confusing memory' labels and trigger in a non consistent way,...

Please, any idea,... Thanks
Luis

0 Kudos
1 Solution
1,201 Views
ErichStyger
Senior Contributor V

I'm using watchpoints with v11.2.1 too, but on a different target (K22).

Don't think this matters. But here are are few things I would do (or not do):

- Eclipse does not have knowledge about the hardware triggers: best if you delete/remove all other breakpoints.

- I faced all kind of issues with a VM environment especially around the USB communication, especially if it is time sensitive: if you can, run in a native environment.

- check the gdb logs/traces (https://mcuoneclipse.com/2016/07/01/board-bring-up-tips-gdb-logs-and-traces-in-eclipse/ this should give an idea what is going on.

- dito: check the SEGGER Console view, probably it reports the problem there?

 

I hope this helps,

Erich

View solution in original post

3 Replies
1,202 Views
ErichStyger
Senior Contributor V

I'm using watchpoints with v11.2.1 too, but on a different target (K22).

Don't think this matters. But here are are few things I would do (or not do):

- Eclipse does not have knowledge about the hardware triggers: best if you delete/remove all other breakpoints.

- I faced all kind of issues with a VM environment especially around the USB communication, especially if it is time sensitive: if you can, run in a native environment.

- check the gdb logs/traces (https://mcuoneclipse.com/2016/07/01/board-bring-up-tips-gdb-logs-and-traces-in-eclipse/ this should give an idea what is going on.

- dito: check the SEGGER Console view, probably it reports the problem there?

 

I hope this helps,

Erich

1,169 Views
luis-martinez
Contributor III

Hi again Erich,

Finally I did't find more things about this unstability. Seem the watchpoint are working using the comparator '>=' instead '==' (but the MCU stop when the condition reach == value, always).
I notice also that the graphic tool to plot 'global memories' not start when you click the memory' box, I saw it working but lately it never plot again, strange,...

At the end may be the VM is the responsible but to final check it I need to mount a complete new real machine in other SDD and restart all the process,... too much work at the moment, but it's on mind.

Thaks
Luis

0 Kudos
1,188 Views
luis-martinez
Contributor III

Thanks your recommendations Erich,

About the word 'trigger' (it was only a name, not an analyser condition) I know it's a more complex process between Eclipse, probe - JTAG connection and the internal arm' mcu registers,... sure need time to do the work all chain.

The virtual machines I'm using are VMware' workstation 15.5.6 fully up to date,... in general no problem, and seem all USB from host machine (where my KV31F and debug probe are connected) are well detected (the fact is that all SDK demos work well). The Win10_64 VM is working with 6 cores (AMD FX-8370 4 GHz), 16GB RAM, 160 GB HD (a host SSD) and feel relative fast,... but no one can be 100% sure about this, as you said.

What I'm testing with (apparent) good result is changing the watchpoint conditions from basic 'glob_variable_counter' == 100  to  'glob_variable_counter' >= 100,... before this change I found all situations (from never stop to stop each write, independent of condition), well after change the condition seem always stop at the right value of 100 (interesting). Anyway I remain testing.

Thanks again Erich.
Luis

 

0 Kudos