Ozone hardlocks on debug start ...

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Ozone hardlocks on debug start ...

      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:

      Source Code

      1. (gdb) c
      2. Continuing.
      3. ^C
      4. Thread 2 "CDevice" received signal SIGINT, Interrupt.
      5. 0x00007ffff55a39e8 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
      6. (gdb) bt
      7. #0 0x00007ffff55a39e8 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
      8. #1 0x0000000000990475 in ?? ()
      9. #2 0x0000000000567773 in ?? ()
      10. #3 0x00007ffff5640552 in ?? () from /opt/SEGGER/ozone/3.22.5/Lib/libQtCore.so.4
      11. #4 0x00007ffff559d3f9 in start_thread () from /lib64/libpthread.so.0
      12. #5 0x00007ffff5367b53 in clone () from /lib64/libc.so.6
      13. (gdb) info threads
      14. Id Target Id Frame
      15. 1 Thread 0x7ffff4b1e7c0 (LWP 20295) "Ozone" 0x000000000097b261 in ?? ()
      16. * 2 Thread 0x7fffe6815640 (LWP 20299) "CDevice" 0x00007ffff55a39e8 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
      17. 3 Thread 0x7fffd97bd640 (LWP 20306) "CDevice" 0x00007ffff55a39e8 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
      18. 4 Thread 0x7fffd8fbc640 (LWP 20307) "CDevice" 0x00007ffff535f1eb in select () from /lib64/libc.so.6
      19. 5 Thread 0x7fffd87bb640 (LWP 20308) "CDevice" 0x00007ffff535f1eb in select () from /lib64/libc.so.6
      Display All
      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 ..
    • 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
      Please read the forum rules before posting: Forum Rules

      Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/

      Or you can contact us via e-mail.
    • 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).
    • 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.
    • Hi,

      v01d wrote:

      V3.22e. Host === Linux
      Which distribution and version? Default install, or custom changes?

      v01d wrote:

      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?


      v01d wrote:

      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
      Please read the forum rules before posting: Forum Rules

      Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/

      Or you can contact us via e-mail.
    • SEGGER - Nino wrote:

      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.


      SEGGER - Nino wrote:

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

      Fedora x86_64, Fedora 33.
    • New

      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