[SOLVED] Implementing custom ResetTarget() in jlinkscript , return status, warning trace

v01d · Apr 28th 2020, 12:05pm

I need to have a special ResetTarget() in my JLink script file.

From the manual, it says, If this function is present, it will be called instead of the DLL internal reset. It also notes that, limitation is, DLL expects target CPU to be halted / in debug mode when leaving the function.

Does this mean DLL still will check if the target CPU is halted after my custom ResetTarget is executed? How does it check it exactly?

I have my ResetTarget doing what I need, and returning always 0 (return 0;), which hopefully returns success to DLL. However, I still get these traces after executing my implemented resets:

**************************
WARNING: CPU could not be halted
**************************
****** Error: Failed to halt CPU.

Is this trace from the DLL or inside JLinkExe somewhere? How does it check if the core is halted? Anyway to prevent it doing this, as I have my own reset strategy / method?

SEGGER - Fabian · Apr 28th 2020, 5:10pm

Hi,
Thank you for your inquiry.

v01d wrote:

Does this mean DLL still will check if the target CPU is halted after my custom ResetTarget is executed?

Not necessarily. Depends on the previous / current state and upcoming actions.

v01d wrote:

How does it check it exactly

Depends on the device (core) you are using. Usually by reading the debug registers.

In you case, it seems like the DLL tries to check if the CPU is halted which fails for some reason.
Than the DLL tries to halt the CPU, which also fails.

=> It seems like your custom reset confuses the device / core (e.g. debug logic got reset but not re-initialized afterwards).
We recommend to check your custom reset (e.g. make sure that the core is halted and the debug logic is still accessible).

Best regards,
Fabian

v01d · Apr 28th 2020, 6:48pm

SEGGER - Fabian wrote:

Not necessarily. Depends on the previous / current state and upcoming actions.

v01d wrote:

How does it check it exactly

Depends on the device (core) you are using. Usually by reading the debug registers.

Is there way to plainly prevent whatever calls the script's ResetTarget() from checking the CPU's debug registers after ResetTarget returns? And stop trying to halt it?

If on a platform / SoC, the system may implement it's own proper core or sub-platform reset sequence, and then hold the relevant core in reset. If JLink DLL only checking standard architecture debug registers - as it probably does? checking the debug halt status - then this may not work well, as you have to release the core, and then halt it through a debug port.
But if you cannot halt it immediately before it tries to execute even first instruction (which may be not valid entirely), then is too late and you may have created a nuclear disaster.

So how do you properly do this with JLink? Essentially you have a proper clean reset sequence you do you the spec, but then you need to do a standard debug halt, to make it work with debugger.

(Ignore which SoC or module. I think the principle should be common?)

SEGGER - Erik · Apr 29th 2020, 10:10am

v01d wrote:

Is there way to plainly prevent whatever calls the script's ResetTarget() from checking the CPU's debug registers after ResetTarget returns? And stop trying to halt it?

No, there is no option to prevent this and there are no plans to add such a option as it does not make any sense from our point of view.
So far, this procedure works for all supported devices (over 7000) out there and we do not see any use case where this procedure does not work.
We know that implementing a proper reset on modern devices is anything but simple compared to resets on legacy devices but it should work using this concept.

If the core is hold in reset after triggering the reset, the ResetTarget() has to release the core and halt it.
It does not make any sense to return from ResetTarget() if the core is not accessible through the debug interface.

Even if the DLL does not check the debug registers after resettarget, what should the DLL do?
It still cannot access the core so a debug session or whatever will simply crash.

If you provide us detailed information regarding the issue you are experiencing, we may can provide you information how a proper reset should be implemented for this device.

BR
Erik

v01d · Apr 30th 2020, 3:54am

Hey Erik

SEGGER - Erik wrote:

.......
If the core is hold in reset after triggering the reset, the ResetTarget() has to release the core and halt it.
It does not make any sense to return from ResetTarget() if the core is not accessible through the debug interface.
.............
Even if the DLL does not check the debug registers after resettarget, what should the DLL do?
It still cannot access the core so a debug session or whatever will simply crash.

Thanks for quick response on technical question.

SEGGER - Erik wrote:

If you provide us detailed information regarding the issue you are experiencing, we may can provide you information how a proper reset should be implemented for this device.

The issue is how to cleanly halt the core immediately -before it executes any instruction - in my ResetTarget() (inside jlink script) after releasing it, and before it executes anything - it must be way too slow invoke halt through JLINK API inside the script.

However, let me first ponder on this further (because at least I do have some dirty way to achieve this, and may be I can do better).

SEGGER - Erik · Apr 30th 2020, 10:36am

v01d wrote:

The issue is how to cleanly halt the core immediately -before it executes any instruction - in my ResetTarget() (inside jlink script) after releasing it, and before it executes anything - it must be way too slow invoke halt through JLINK API inside the script.

Welcome to our daily business

Implementing a clean reset is everything but straight forward on modern MCUs as bootloaders are involved and booting from different boot sources. Basically the CPU must be halted after bootloader execution but before executing the target application.

Basically there are two possibilities:
a) A reset does reset the debug logic as well
b) The debug logic is not affected by the reset

In latter case, a data breakpoint (watchpoint) can be used to achieve a clean reset.

The easiest thing is if your application can execute an instruction that loads a byte from Addr. 0, such as:
MOV R0, #0
LDRB R1, [R0]

You can then add a data breakpoint which halts the CPU when a byte from 0 is read.

In case a) it's much more complicated but also possible.

BR
Erik

v01d · Apr 30th 2020, 11:12am

Hey Erik

SEGGER - Erik wrote:

Basically there are two possibilities:

This is great stuff, thank you.

Yes I was thinking along the route of setting hardware address watchpoint at address X. One obvious non-nicety is too much knowledge at the connect/reset script stage (sits below all code & debugging).

I understand your easiest solution, and I see how it can work. (Just that you would need to modify all your early startup code).

I may, however, ask you to check something else I'm using, however I would message you through the board.

Thanks for help.

SEGGER - Erik · Apr 30th 2020, 12:03pm

You are welcome

BTW: Yes you would have to modify the setup code but it's a solution which may work on any setup.
Without this approach, it's kind of impossible to perform a proper reset on certain devices.

We consider this thread as closed for now.

BR
Erik

Share