[SOLVED] Ozone stuck on "resetting device"

Zeke · Jul 2nd 2020, 5:26pm

This is basically a re-post of forum.segger.com/index.php/Thr…ne-hangs-in-device-reset/
I was having this issue in 3.20a. It would trigger after only a few minutes of connection to the device.
I've updated to 3.20b ~~and the issue appears fixed (after about 30 minutes of use)~~, but I don't see anything that would fix this in the release notes.

The bug was triggered seemingly at random. After this, none of the interaction with the device would work. Resetting, halting, disconnection, editing/viewing memory, etc. were all unresponsive. The status bar shows "Resetting device..."
My only option was to kill the process.
Disconnecting the j-link did produce the standard error, but didn't release ozone out of this bugged state.

I'm debugging a cortex-M0 based core via SWD at 4MHz. I also tested at 1MHz and 500kHz which both continued to have the bug. The image loaded is a .elf. Before triggering the bug, I was always editing a field in the watched data called "command".
The j-link being used is an on-board one, not an external one.

~~Since this appears to be fixed, does support care about pursuing this?~~ If I encounter it again, I'll make sure to post back here.
Thanks

Zeke · Jul 3rd 2020, 2:44pm

Can confirm this is still a bug in 3.20b.
Just occurred on the same setup after re-compiling the binary and going back to ozone. Ozone asked me if I wanted to load the new binary and I pressed yes. The dialog closed and nothing happened (there is no flashing dialog). Status bar says "Resetting device...".

FYI I'm on Windows 10 Pro on a desktop.

Here's another thread on the same issue:
forum.segger.com/index.php/Thr…ost-connection-to-target/

SEGGER - Nino · Jul 7th 2020, 12:07pm

Hello,

Thank you for your inquiry.
We are aware of this issue, however so far no one could provide us with a working reproduction scenario.
Could you provide us with reproduction steps that work reliably?

What is your debug setup?
Which J-Link?
What is the target device name?
Custom or eval board hardware?
Does it appear only with a specific project or with any?

Best regards,
Nino

Zeke · Jul 7th 2020, 3:45pm

Hi.
I've answered a few of those already but I'll summarise here.

Could you provide us with reproduction steps that work reliably?
Unfortunately it's rather random. My colleague gets this bug every other day, but I was once triggering it every 10 minutes.
It MAY be related to editing variables in the watched data list. All of my recent experiences of the bug have been the same sessions where I was doing this.

What is your debug setup?
Cortex-M0 core with a custom ASIC being debugged by an on-board j-link. However, this issue has been seen with the official SEGGER J-links too.

Which J-Link?
See above

What is the target device name?
Han
but the same issue has been seen on our Qin project too.

Custom or eval board hardware?
Custom

Does it appear only with a specific project or with any?
It seems specific to this series of chips (Han, Qin) but I haven't had the chance to test other products we make.

If there was a debug mode for Ozone/jlink to print out useful data to identify this bug, I can do that and provide logs for you.

SEGGER - Nino · Jul 8th 2020, 3:22pm

Hi,

Thank you for providing the information.
Could you send us the J-Link log and Ozone log file for reference?
wiki.segger.com/Enable_J-Link_log_file

and for Ozone log start Ozone via commandline with parameter -logfile <filepath>

Best regards,
Nino

Zeke · Jul 8th 2020, 7:21pm

Yes, I can do that.

I can also confirm this bug is not related to editing variables in the watched data view. My encounter today went like this:
Open Ozone
New project (specify .elf, SWD @ 4MHz)
Save project file
Connect to jlink
Run
Do things in other programs...
Come back to ozone
Try to set breakpoint (nothing happened)
Try to pause CPU (nothing happened)

Zeke · Jul 8th 2020, 7:50pm

Here are some logs. These are from after I closed Ozone via task manager.

zamniah · Jul 9th 2020, 12:46am

I had issues with resetting device from Ozone, it uses different method than JLink commander's reset or "monitor reset" via gdb (perhaps it just jumps to reset vector instead of doing device reset?)

AFAIK there is no possibility to change resetting procedure in Ozone.

As workaround, I use either JLink commander's reset or reset from GDB

(My device's firmware has three stages, each with different set of interrupt vectors, and Ozone's reset doesn't work at all)

I guess the reset should be something like

Source Code

SCB_AIRCR = SCB_AIRCR_VECTKEY | SCB_AIRCR_SYSRESETREQ

hs2 · Jul 9th 2020, 2:13pm

I've encountered the same issue. Ozone stucks sporadically e.g. after being idle a while and the process needs to killed.
Ozone V3.20b on Win10x64

SEGGER - Nino · Jul 9th 2020, 2:43pm

Hello,

Zeke wrote:

Here are some logs. These are from after I closed Ozone via task manager.

Thank you for providing the logs. The J-Link log does not seem to be saved correctly. Is Ozone the only tool in this instance that is connected to your J-Link or are there also other tools?
You write that this issue appears on your own eval boards. I believe we should have them in our office as they are using J-Link OBs. Could you provide an example project for your boards with reproduction steps via a support ticket? How to open one you can find in my signature.

zamniah wrote:

I had issues with resetting device from Ozone, it uses different method than JLink commander's reset or "monitor reset" via gdb (perhaps it just jumps to reset vector instead of doing device reset?)

That is not correct and the issue you are describing here is due to an incorrect project setup.
For more information see here:
wiki.segger.com/Debug_on_a_Target_with_Bootloader

So the reset behaviour is always the same. The difference is only what happens after the reset.

hs2 wrote:

I've encountered the same issue. Ozone stucks sporadically e.g. after being idle a while and the process needs to killed.
Ozone V3.20b on Win10x64

Could you provide a reliable reproduction setup?
Could you also send us a J-Link script and Ozone script of the failing session as Zeke did above?

Do you get the same behaviour when using the latest J-Link software package?
segger.com/downloads/jlink/

Make sure that Ozone is closed during the installation of this software and that it is selected at the end of the installation progress in the DLL updater.

Best regards,
Nino

hs2 · Jul 9th 2020, 4:30pm

Yes, I'm using the latest non-beta JLink package and also ensure Ozone is not running when installing JLink.
No, as mentioned since it happens sporadically (and luckily not very often) I don't see how to provide a reproducible test case.
I only know that wasn't the case in the past (1,2, .. ? versions before), my jdebug scripts are the same since a pretty long time.

I can start a Ozone debug session and work with it, then I leave it running the target and go back to work on the sources.
Then after a while I go back to debug my changes and Ozone hangs/is not responsive anymore.

SEGGER - Nino · Jul 10th 2020, 4:49pm

Hello,

hs2 wrote:

Yes, I'm using the latest non-beta JLink package and also ensure Ozone is not running when installing JLink.

Ok thank you for verifying.

hs2 wrote:

No, as mentioned since it happens sporadically (and luckily not very often) I don't see how to provide a reproducible test case.

Yes that is why we would like to investigate this further, but without a reproduction scenario that works on our developer PCs it is near impossible to fix this.

To understand better what you were doing before the freeze.

- You have Ozone open and debug your application.
- You need to change a application part and switch to your IDE while leaving Ozone running with the debug session on and target running
- After a while you finish your coding and recompile the application
- Now Ozone asks you if you want to reload the new elf file
- You accept and Ozone freezes directly or shortly after the pop-up

Is this correct?
If not what was exactly what you were doing?
Does this issue also appear if you do only slight changes to your code and switch back to Ozone fast within a couple of seconds?

Best regards,
Nino

Zeke · Jul 10th 2020, 6:45pm

SEGGER - Nino wrote:

Hello,

Zeke wrote:

Here are some logs. These are from after I closed Ozone via task manager.

Thank you for providing the logs. The J-Link log does not seem to be saved correctly. Is Ozone the only tool in this instance that is connected to your J-Link or are there also other tools?You write that this issue appears on your own eval boards. I believe we should have them in our office as they are using J-Link OBs. Could you provide an example project for your boards with reproduction steps via a support ticket? How to open one you can find in my signature.

Yes, the j-link log does appear very short. I've got some better logs now. I'm on J-Link version 6.80b. Should I update to latest?
I have some complete logs of two failures but the combined size of the log files is 17MB. How do you want me to upload these?
I Ozone is the only j-link tool open.
I could open a ticket, but I'll have to discuss that with my company. The reproduction steps are basically "use ozone as normal".

New finding:
RTT works after hitting this bug. Even after smashing the "stop debug session" and "halt" etc., I see see RTT live output.

hs2 · Jul 13th 2020, 12:42pm

@nino I'm aware that it's hard to find and fix something w/o a reproducible testcase..
I've added my findings to underline that it's a somewhat systematic and not a user specific problem.
To be honest I can't remember if Ozone prompted for re-load before getting unresponsive on regaining focus after a longer period being idle in the background.
I'll pay (more) attention and report back.
Thanks !

Zeke · Jul 13th 2020, 8:54pm

Finally I got some logs small enough to upload with a complete jlink log. Hope this helps!

Zeke · Jul 14th 2020, 2:55pm

More logs. I think these should be clearer since I barely did anything to Ozone before hitting the bug.

SEGGER - Nino · Jul 14th 2020, 4:40pm

Hi,

Thank you for providing the logs.
We will see if we can narrow down the issue that way.
We will keep you posted.

Best regards,
Nino

Ewout206 · Jul 16th 2020, 12:47pm

I am the author of the original thread. I'm sorry I didn't follow up on it, I had a lot of other things to do.

I can give you a short summary of my experiences :

Ozone 3.20b on Mac OS X (10.14 on iMac)
STM32L452 on custom board with JLink Ultra+
OR
STM32L476 on STM32L476 Discovery with JLink implemented over ST-Link.

The freeze occurs randomly when:
- Ozone is left running connected to board without input from me for 1-2 minutes.
- I suspect putting the STM32L4 in LP Run or LP Stop does seem to aggravate the issue in that it happens more often.

Ozone seems unable to execute a device reset on the target. Because a reset does not execute properly, Ozone does not respond to other commands like stopping the debug session or even closing the program. Killing the program through the Activity View is the only way of ending Ozone.

I attched an Ozone snapshot just after it froze:
ozoneConfig_200716.jsnap.zip

zamniah · Jul 19th 2020, 1:44am

SEGGER - Nino wrote:

That is not correct and the issue you are describing here is due to an incorrect project setup.
For more information see here:
wiki.segger.com/Debug_on_a_Target_with_Bootloader

So the reset behaviour is always the same. The difference is only what happens after the reset.

You are missing the point. JLink Commander has 9 different reset types (section 7.10 from JLink/JTrace Guide).

The default reset strategy is via AIRCR.SYSRESETREQ:

Source Code

J-Link>r
Reset delay: 0 ms
Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via AIRCR.SYSRESETREQ.

It would be actually very cool if you could add this setting to Ozone.

EDIT: though chaning the AfterTargetReset to set VTOR table from boardloader and not current elf made the thing easier.

Beew · Jul 20th 2020, 5:43pm

Hello,

i have the exact same problem with Ozone. Is seems to crash randomly after some time without any error dialog.
* Cortex-M4 (TI MSP432P4011) custom board
* JLink EDU
* OSX 10.15.5
* Ozone (3.20b), JLink (V6.80e)

It don't react to any Debug.* commands after the crash. The rest of the UI is reacting tho (except the "Close this Session?" dialog).
Sometimes it even halts to a breakpoint in this state.
The only way is to force close Ozone. It's a pity that Ozone don't save its *.user file when force closed.
Every breakpoints and expressions from last session are lost because of this.

I can provide some logs if needed.

Greetings

Source Code

Source Code

Share