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.

      Keep in mind, this is *not* a support forum.
      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.

      Keep in mind, this is *not* a support forum.
      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.
    • 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
    • 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?

      v01d wrote:

      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
      Files
      Please read the forum rules before posting.

      Keep in mind, this is *not* a support forum.
      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.
    • @nino

      SEGGER - Nino wrote:

      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.


      SEGGER - Nino wrote:

      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.


      SEGGER - Nino wrote:

      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

      SEGGER - Nino wrote:

      s to appear every time.
      Indeed, latest 2 times today - pretty much repeatable.


      SEGGER - Nino wrote:

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