I am trying write a script to halt CPU right after powerup (for example we install a faulty code to flash of S32K144 device and make the chip stuck in reset. Other than the basic functions like SYSTEM.UP, BREAK, SYSTEM.MODE.ATTACH , is there any other way to stop the CPU before it executes the main function. I have come across a Lauterbach reference about GLOBALON event, such as POWERUP and POWERDOWN. If there is possible way, please provide kind guidance and example on the creating the script for halt command repeatedly before it go main function. based on the info from the pdf.
I have tried the execution using demo script given by Lauterbach on LCP1768 on board MCB1700.
This is my script:
SYStem.RESet
SYStem.CPU LPC1768
SYStem.CONFIG SWDP ON
SYStem.Option EnReset OFF
IF UTRACE()||COMBIPROBE()
(
SYStem.CONFIG.CONNECTOR MIPI20T
)
SYStem.up
; Load the demo code into the SRAM
Data.LOAD.Elf ~~~~/demo.axf
symbol.sourcepath.set C:\T32\demo\arm\compiler\gnu\src
Register.Set PC 0x10000748
Register.Set R13 0x10005000
IF hardware.COMBIPROBE()||hardware.UTRACE()
(
; Enable Trace
Data.Set 0x4002C028 %Long 0x00000008
ETM.ON
ITM.ON
ETM.PortMode Continuous
ETM.PortSize 4.
Trace.METHOD CAnalyzer ; Using CombiProbe
Trace.OFF ; Enable the trace and turn it off
)
ENDDO`
If it will have success depends a little bit on the used hardware. There isn't yet native support for your use case inside the debugger, but the PRACTICE script language should be fine to solve it.
The idea is to keep the board in reset after power up and let the debugger automatically execute a SYStem.Up. This will let the debugger connect to the core and halt it without having any code being exectuted on it:
There exists hardware, that is not able to keep the reset being asserted during the power-up. This is for example the CombiProbe HS whisker. But if your board has a reset button, then you can keep it pressed while powered down and realease it after power up as soon as "Connecting..." is shown inside the status line of the debugger.
The sequence should work on other controllers, too. I could not test the LPC1768 itself, because I currently do not have access to a board like this.
Best Regards, Steffen.