MPC5748G, Lauterbach multiple-reset causes error

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MPC5748G, Lauterbach multiple-reset causes error

Jump to solution
13,508 Views
umarali
Contributor I

HI everyone,

 

I am using PPC5748G processor for a certain application and using Trace32 Lauterbach for debugging and flashing. My problem is that when my application (basically it is a RTOS test) resets the core multiple times, the processor goes in a state where it has to be power-cycled, and simply resting the target doesn't work.

 

meanwhile the debugger lists this error message :

"    system.up error: received invalid OSR (0x000)

                                - does the target assert JCOMP while RESET is asserted?

                                - is the device censored?

     error: received invalid OSR while core running (0x000) "

 

so is it a hardware limitation or is there any script that can help me solve this problem ?

 

 

Looking forward reply,
uali

Labels (1)
1 Solution
9,156 Views
petervlna
NXP TechSupport
NXP TechSupport

Hi uali,

This issue is quite simple. I will try to explain it to you.

When you execute 15 consecutive resets the device stay in permanent reset. This is your case. To recover from this state you need to execute power on reset.

I expect you do not disable SWT in startup (assembly code).

After Power on Reset(POR) the default timeout for SWT is 20ms. If this expire SWT module resets the device. If this happen 15 times -> device stay in permanent reset until POR is executed.

So to prevent this you need to dissable or service SWT during these 20ms after POR.

Now the Lauterbach issue:

If you are able to attach with lauterbach during these 20ms x 15 times = 300ms then Lauterbach will disable the SWT automatically.

As this is a short time and usually you are not so fast with attach of debugger the micro will assert a reset after 15 SWT resets and you cannot connect until new POR.

Solution:

1. Connect with debugger within 300ms

2. Hold external reset, Power the board, attach with debugger, do break, and release the external reset.

Hope it helps.

Peter

View solution in original post

26 Replies
1,897 Views
chfakhtchfakht
Contributor III

Thanks that the first method works : i have kept powering on/off with resetting every time and i catch the reset before the BOARD goes down ... i'll keep the cmm file in case i need it.However can you tell me were can i find those cmm files ,i have a lot of them missed

thanks for your help

0 Kudos
Reply
1,897 Views
petervlna
NXP TechSupport
NXP TechSupport

Hi Reinhard,

I have tested it and it works!

Really cool feature. I was not aware of it.

Thanks,

Peter

9,157 Views
petervlna
NXP TechSupport
NXP TechSupport

Hi uali,

This issue is quite simple. I will try to explain it to you.

When you execute 15 consecutive resets the device stay in permanent reset. This is your case. To recover from this state you need to execute power on reset.

I expect you do not disable SWT in startup (assembly code).

After Power on Reset(POR) the default timeout for SWT is 20ms. If this expire SWT module resets the device. If this happen 15 times -> device stay in permanent reset until POR is executed.

So to prevent this you need to dissable or service SWT during these 20ms after POR.

Now the Lauterbach issue:

If you are able to attach with lauterbach during these 20ms x 15 times = 300ms then Lauterbach will disable the SWT automatically.

As this is a short time and usually you are not so fast with attach of debugger the micro will assert a reset after 15 SWT resets and you cannot connect until new POR.

Solution:

1. Connect with debugger within 300ms

2. Hold external reset, Power the board, attach with debugger, do break, and release the external reset.

Hope it helps.

Peter

1,896 Views
maheshd
Contributor II

Hi Peter,

Working with S32R274 ECU, I have faced the same system up error (received invalid OSR while core running (0x000)) . so as per your help, considering the permanent reset situation , i have done the above steps of Halt core at power on reset , but the pop up was "unexpected error " ( cmm :

powerupok:

WAIT SYStem.UP() 1.s
IF !SYStem.UP()
GOTO error

 

 

error:
ON POWERUP
ON ERROR
DIALOG.END
PRINT "unexpected error"
ENDDO ABORT

 

)

Also direct " SYSTEM.MODE STANDBY " fails (Debug port fail)

Is this the confirmation that MCU has been censored (locked) ? any settings to be done related to SWT in Trace32 ? or is there any other means to check again?

Thanks in advance ! 

Update : Tried flashing with EVB .. same behavior of system up error (Received invalid OSR while core running (0x000))observed.. so , I have used the method of 2.Hold external reset, Power the board, attach with debugger, do break, and release the external reset, then the EVB was able to System.up.

0 Kudos
Reply
1,896 Views
petervlna
NXP TechSupport
NXP TechSupport

Hi Mahesh,

You board is not censored for sure.

You just forget to server watchdog in your SW. And by default you have reset escalation set to 0xF.

If you connect a Scope probe on reset pin you can see after power up the board 15 consecutive resets and then permanent reset until power on is executed again.

Serve your watchdog properly in SW or disable it and you will be fine.

Peter

0 Kudos
Reply
1,896 Views
chfakhtchfakht
Contributor III

Hi, i didn't understund the solution well

Firstly i have to connect the debugger to the ECU right ? hold external reset and power on ... attcach again with debugger how ? and then do break WHERE ? please explain more i'm stuck in this issue

thanks

0 Kudos
Reply