[SOLVED] Ozone hardlocks on debug start ...

v01d · May 17, 2021 at 12:47 PM

Ozone starts, load my project & uploads my binary, breaks in, but after I left it go / Run, it hard locks and becomes un-responsive ....
Window becomes blurry / fonts go , unresponsive.

Some snooping around, it seems stuck on some condition with no timeout:

Code

(gdb) c
Continuing.
^C
Thread 2 "CDevice" received signal SIGINT, Interrupt.
0x00007ffff55a39e8 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
(gdb) bt
#0  0x00007ffff55a39e8 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x0000000000990475 in ?? ()
#2  0x0000000000567773 in ?? ()
#3  0x00007ffff5640552 in ?? () from /opt/SEGGER/ozone/3.22.5/Lib/libQtCore.so.4
#4  0x00007ffff559d3f9 in start_thread () from /lib64/libpthread.so.0
#5  0x00007ffff5367b53 in clone () from /lib64/libc.so.6
(gdb) info threads 
  Id   Target Id                                   Frame 
  1    Thread 0x7ffff4b1e7c0 (LWP 20295) "Ozone"   0x000000000097b261 in ?? ()
* 2    Thread 0x7fffe6815640 (LWP 20299) "CDevice" 0x00007ffff55a39e8 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  3    Thread 0x7fffd97bd640 (LWP 20306) "CDevice" 0x00007ffff55a39e8 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  4    Thread 0x7fffd8fbc640 (LWP 20307) "CDevice" 0x00007ffff535f1eb in select () from /lib64/libc.so.6
  5    Thread 0x7fffd87bb640 (LWP 20308) "CDevice" 0x00007ffff535f1eb in select () from /lib64/libc.so.6

Display More

And then i have to kill it.

Whats interesting same binary/target same J-Link but connecting with CCS does not do it, and runs Ok.

I'm very sad about my Ozone ..

SEGGER - Nino · May 19, 2021 at 3:18 PM

Hello,

Thank you for your inquiry.
Such an issue is not known to us.
Could you share more details about the setup you are using?
What host OS are you running on?
Which Ozone version are you using?
Is the issue reproducible, if yes, how?
Could you share the Ozone and J-Link log of the failing session?

Best regards,
Nino

v01d · June 1, 2021 at 4:04 AM

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

v01d · June 1, 2021 at 7:45 AM

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.

SEGGER - Nino · June 4, 2021 at 11:33 AM

Hi,

Quote from v01d

V3.22e. Host === Linux

Which distribution and version? Default install, or custom changes?

Quote from v01d

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

Could you provide a sample application that could run on an eval board that shows this behaviour with reproduction steps?

Quote from v01d

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

Unfortunately that will not help. We need a way to reproduce the reported behaviour on our dev PC setups.

Best regards,
Nino

v01d · June 6, 2021 at 3:57 AM

Quote from SEGGER - Nino

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.

Quote from SEGGER - Nino

Which distribution and version? Default install, or custom changes?

Fedora x86_64, Fedora 33.

erwinrol · June 11, 2021 at 6:56 PM

I can confirm this problem.

My workflow is that I open an elf file (for a SAM4S in this case) with Ozone and after editing my code with VS code and compiling it with cmake/ninja Ozone will notice the elf file changed and asks me to re-upload it to the target. Every 4 or 5 times Ozone will hang, sometimes several times in a row. Like the original poster it is a hard GUI hang, nothing works anymore, not even the close button of the window manager, only killing can stop it.

This is on Centos 8.3 on a 24 core Xeon with nVidia GPU.

My Trace Pro is connected via USB3 and al software is up to date.

I can't recall I had this problem with the previous version of Ozone.

Best regards,

Erwin

SEGGER - Nino · June 22, 2021 at 12:54 PM

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.
Could you give the latest Ozone version a try and see if the issue persists?

Quote from v01d

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.

What does "their/TI default code" mean here? Where would I source this from?
Could you take the attached project and change so that the reported behaviour is reproducible and reupload it?

You can rebuild the application with Embedded Studio.

@erwinrol, not really sure that these inquiries are related to each other. You are using a different host OS, different target device and architecture and the issue seems to appear random whereas the issue OP is describing seems to appear every time.
So could you open a new thread for your specific issue and provide a reliable reproducer for the issue you are seeing?

Best regards,
Nino

v01d · June 29, 2021 at 1:34 PM

@nino

Quote from SEGGER - Nino

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.

Quote from SEGGER - Nino

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.

Quote from SEGGER - Nino

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

Quote from SEGGER - Nino

s to appear every time.

Indeed, latest 2 times today - pretty much repeatable.

Quote from SEGGER - Nino

Could you give the latest Ozone version a try and see if the issue persists?

Yes indeed I shall do

v01d · June 29, 2021 at 1:43 PM

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

v01d · July 7, 2021 at 3:43 AM

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.

Participate now!