I just learned that there is https://www.segger.com/products/debug…ace-pro-risc-v/
Can my JTrace Pro Cortex unit be 'upgraded' or flashed with new firmware / gatware to suppor that, or I need to buy entirely new unit?
(At the moment have no use for ARM Cortex anymore, would love if I could just pay for RISC-V license and may be get adapters..?)
Would like to use JLink 'native' with this soft RISC-V core:
https://github.com/SpinalHDL/VexRiscv
Project uses OpenOCD + gdb, which means I cannot (as far as I know) use Segger's Ozone, a tool I find slim, right & fit (and fast) so to say (and not a fat ide..).
Is it possible ... ?
Doesn't appear to make much difference if I do / not add this exec command to my init script. JLINK_ExecCommand("DisableFlashBPs");
I can still click & insert more breakpoints, where it should fail, but that doesn't appear to happen, and then my target crashes as presumably, it's now pushing sw breakpoints..
ok then, I didn't know Segger moved into non-embedded app development.
So I was curious, and installed it to see.
And by the first look, it's same as Segger other Embedded studio. So, why ? Why do we need this "Linux" re-brand?
Still seems Java script (and no more suitable Python .. ), interface still same, nothing special seems for debugger, .. Overall, what makes this special for Linux? Does it have all automated & ironed about JLink setups for debugging U-boot images and automatically hooking up to Kernel past boot, can it automate debugging kernel modules runtime ... ??
I see nothing . So big why we need it.
No still struggle somewhat. Each time I power cycle my JLink (or Jtrace), I have to again, start command line interface, and through web page, go and change settings to Never use Flash break points.
Also, I'm not sure this works when it runs out of hw ones - does it throw error when you try set more than hw breakpoints availble? Because, i never get it, and it seems it proceeds to insert software ones.
This whole feature / strenth of 'flash breakpoints' appears to insert sw breakpoints runtime, and this just does not play well at all on my TMS target, with MPU enabled.
Also, 'attaching' to running target entirely does not work, as , again, when I attach (i.e, No firmware upload) it only seems to use want to use sw breakpoints again, and this again crashes the system.
From the link you have provided : .. "The behavior of the J-Link can be customized via J-Link Command Strings passed to the JLinkARM.dll " . Can those command strings be passed from JLink init script when establishing connection to target?
Hi,
I'm using now the latest Ozone - v3.23 2021-07-02 - and need some time to see if it works Ok.
Please keep this thread open.
So far it is Not worse.
And, actually coming to think of it : where in Ozone, one can set option to ALWAYS DISABLE those smart Flash breakpoints ? (which are Sw breakpoints really ).
I'm suspecting that it could contribute to ozone hanging if target fails init due to it's doing RAM self check while there is RAM code which may try set/unset flash breakpoints .. ?
I sort of, found it: if you start JLinkExe, then connect to JLink through the webserver, you can find option "Flash breakpoints" : Auto, On, Off. Setting this to off, may appear to work on 'fresh' load - load program & symbols - but, it doesn't seem to work if you do just symbols only : always get the sw/flash break points then ...
Hello,
I just tested the default Hello World example on a TMC570LC Hercules board (example attached) on Fedora 33 and there everything is working as expected..
My targets are all TMS570S family; however that is probably not a factor.
Hello World is probably , too simple. Also, it would help (I think ..) to also use a FreRTOS based example, as your Ozone OS plugin might be a contributing factor.
What does "their/TI default code"
That mostly meant, their default HAL init code, which is normally auto-generated as-is from their HalCoGen tool. Specifically, the code in _c_int00 - the essential HAL & C runtime setup <--- This is where Ozone deadlocks.
You can rebuild the application with Embedded Studio.
I strongly prefer not to, as, this is not a comparable setup, not even compiler / linker : I advise you to only stick to TI ' ARM compiler - I'm using v 20.2.5
s to appear every time.
Indeed, latest 2 times today - pretty much repeatable.
Could you give the latest Ozone version a try and see if the issue persists?
Yes indeed I shall do
Could you provide a sample application that could run on an eval board that shows this behaviour with reproduction steps?
Providing a sample always requires one time to be spent on it.
I can tell you that if you start with just a sample default code startup for the TMS570xxx chip using their/TI default code you should be able to get it straight away.
Which distribution and version? Default install, or custom changes?
Fedora x86_64, Fedora 33.
ok thread resolved then.
Is there a J-Link script setting which _disallows_ all sw bkptrs and only does hw ones .?
Using J-Trace Cortex, TMS570LS12x chip, CCS IDE v10.3.
If debugger injects a Sw bkpkt, then it is no longer possible to resume/step the code, either C statement or ASM. This is in CCS.
Once this happens, the CCS
Looking at asm, for e.g:
E1200070 bkpt #0
00010f04: E3A00000 mov r0, #0
00010f08: E58D0000 str r0, [r13]So the CPU is stuck at line 1, and ASM step doens't work. Further, debugger/ide fails to read bunch of registers from that point, SP, CP, SPSR.
ortexR4: Trouble Reading Register PC: Failed to measure CPU clock frequency
CortexR4: Trouble Reading Register CPSR: Failed to measure CPU clock frequency: second loop count is less than first one! (0<=0)
CortexR4: Trouble Reading Register CPSR: Failed to measure CPU clock frequency
CortexR4: Trouble Reading Register SP: Failed to measure CPU clock frequency: second loop count is less than first one! (0<=0)
CortexR4: Trouble Reading Register SP: Failed to measure CPU clock frequencyMoving PC manually, i.e. setnextline , or move to line, by setting to line 2 in asm above, resumes the code.
So, is J-Link/J-Trace 's settings somehow clash with software break points here? I don't get seems this stuck behaviour on same code with an XDS debug probe.
I found manual reference to color and the setting under Preferences -> Appearance , Source Viewer . BUT, there is no setting to change editor background... Is there way to do it?
I think it may be good if you provide full debug version / symbols for the Linux Ozone, so I could quicker help you trace where it got stuck exactly, in which function ..?
I'm willing to sign any NDA in the name of my Co.
Hello,
V3.22e. Host === Linux
After looking more into this, it seem _ALWAYS_ the case that it freezes of any of the break points are set in the c init routine, e.g. checking reset cause, e.g por vs wdog reset.
It does not, seems, happen anything past main().
My target : ARM Cortex-R4 / TMS570xx SoS (multiple verisons).
Hi Alex,
Normally, people would do Vanilla Eclipse CDT + GNU MCU free plugin, with Segger J-Link helper GUI plugin to support - like, configuring JLinkGDB sever startup etc ...
I can't say I saw -rtos .. option giving anything different, i.e, in the debug view , under Debug there is always just one connection & one thread. I will double check again a brand new CDT, but something else is missing I think.
Actually, ignoring All Eclipse entirely, and just using a suitably targeted GDB client , for say gnu arm, I should be able in GDB console switch the threads, before I get into any Eclipse ...
TI CCS is not using JLink GDBServer but loads the J-Link lib and uses the J-Link API directly.
Thanks for replying Alex,
I'm jumping from one thing to another here above - sorry, I was asking above, for case I skip CCS and use Eclipse + GDB directly + JLink GDBServer -rtos xxxx.
(It should, I thought, then allow me to use the threads commands inside the gdb console, to switch over from one to other. )
There should be expand/ collapse bracket inside the editor (yes, right inside the editor window) next to each C statement, which allows you to open it and see the matching ASM statements.
(Pretty cool, if you ask me - interleaved assembly kinda, but you can hide it).
Once you open it / expand it, your next step becomes ASM step, until you close it again - and then you back to C stepping.
