AURIX™ Forum Discussions

[User21699]

I'm working with a TC397 ADAS 2.0 (TC397XA-256)
My goal is testing watchdog MCU reset mechanism but this way occurred hard reset several time in very short period.
I use Infineon wdg and gpt driver with Tresos generated code.
Without debugger (Lauterbach) the board go to reset immediately.
If I use debugger the situation is same with this error:
debug port failed after reset
aborted reconnect after hard reset: failed to establish communication within 3002 ms
reset source: debug port time-out
debug port failed after reset

The board was always in Reset but with a trick pushing and releasing reset button and send System.up with a good timing I reach System.UP state in trace32.
In this case I can read and change all registers (e.g. RCU)

If I try to set System.Up I get this error from Lauterbach:
debug port fail
aborted SYStem.Up: failed to establish communication within 502 ms

If this way I try to step one assembly instruction the Hw go to reset.
My main problem is I can not re-flash with Lauterbach, But meanwhile I have a fixed code which will not generate several reset only one.

[MoD]

What you are doing before this occurs? Made some programming also for different UCBs?
Can you check the ESR0 signal? If ESR0 stays always on low or it goes to high for some ms and then back to low?

[User21699]

Before this state of board I run a wrong test code which call Mcu_PerformReset via WdgM (developed and configured to ImmediateReset reset) a lot of times. This was my mistake since this would be enough at one time.
My goal is testing Autosar WdgM Immediate Reset feature provided by the MCU driver.
As I know UCB is not touched by me.

Currently I'm try to connect board with Trace32 (Lauterbach) with a trick since normal way System.Up mode is not working due to the reseted state.
The trick is what I mentioned previously.

If I set debugger this way to system.up and try to step one CPU instruction I see ESR0 go down immediately. Not was any change.

Without debugger: At connecting power it is high then low. So in the time between power on (ESR0 high) and ESR0 low is 600ms, but not any level change.

[MoD]

When you make a system up, then the state of ESR0 is changed also only for a short time (same should be occur if you select RESET OUT in Lauterbach). How you connect the Lauterbach to the board (DAP or JTAG) and what is selected?

[User21699]

I Used JTAG X401, but with DAP2 settings of DEBUGPORTTYPE settings of T32

If I simple use command SYSTEM.UP the ESR0 do not change.
The error is
debug port fail
aborted SYStem.Up: failed to establish communication within 502 ms

If change to JTAG and try to use System.Up
there error message is not the same:
IDCODE is 0x0
IDCODE is 0x0
aborted SYStem.Up: failed to establish communication within 502 ms

[MoD]

Please check also the PORST signal. When this signal stucks on low there is no communication possible. Normally the PORST is always high and will be driven low for a short time from the debugger to reset the device.

[User21699]

PORST is working as you describe. "always high and will be driven low for a short time from the debugger to reset the device."
And if I try to System.Up I see same but low level is shorter.

[MoD]

Ok, in this case all supplies are ok and the device should work. Because the ESR0 always stays at low they are only two possible problems: ESR0 has a short cut to ground or there was a problem during the last programming where anything goes wrong with UCB progarmming (e.g. UBCx_ORIG and UCBx_COPY are erased without programming of valid confirmation code). If this is the case then device can't be recovered and must must be exchange. Same occurs when the HSM is switched on via UCB programming and no valid HSM program was in the PFlash.

[User21699]

Is there any way to rule out whether this is a not recoverable state or not by any register value ? All register is readable... I assume this is possible.

[User21699]

Is it possible to see from register value side if the board is unrecoverable state ?

[MoD]

When you can read any register value then the device is not brick and you can recover the device by reprogramming.
Measure the behavior of ESR0...