MPC5748G target reset failure -- Debug Port Fail

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

MPC5748G target reset failure -- Debug Port Fail

1,288 Views
krishna2262
Contributor I

I was trying to Flash the Software from the Trace32 debugging tool. We have trying to do the flashing through .elf file in the Trace32. But when we did it was working for the first time for the debugging but when we checked the signals from ECU for can signals the can signals were not present at the same time when we are trying to do the debugging . But when we tried to do the debugging for the second time, we are trying to target reset and we are getting an error as below :

krishna2262_0-1686826774387.png

This is the error we got in the area:

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)

 

We have tried all the solutions present in the other solutions but it was not working .

There is no hard reset on the hardware board for the ECU.

I guess the Microcontroller went into censorship. If not please help me to solve the microcontroller issue if it went into censorship, please help me resolving it.

The below are the memory places in the .cmm  file of my microcontroller.

krishna2262_1-1686827000915.png

 

0 Kudos
6 Replies

1,101 Views
petervlna
NXP TechSupport
NXP TechSupport

Hello,

So from my point of view the reset escalation is solved, by using Lauterbach script.

Now it looks like you have issue in your SW, which is not related to this. Please do proper debugging to see why your CAN functions are not called. Is your code even reaching CAN routines?

Once you find where the SW crash, you will be able to move on.

Best regards,

Peter

0 Kudos

1,260 Views
petervlna
NXP TechSupport
NXP TechSupport

Hello,

I agree with mr.Weiss. The MPC5748G has by default enabled watchdog (SWT) for 20ms. Reset escalation is set to 15.

So after 20x15 =300ms your device will enter into permanent reset state. I do not expect that you are connecting to running target to stop SWT by debugger in such sort time. You will need to use script mention above.

This has been discussed on community many times.

Best regards,

Peter

0 Kudos

1,274 Views
rweiss
Contributor V

Hi krishna2262,

Did you enable censorship in the processor? If not, it is highly unlikely that the processor is censored now. It is more likely that the reset escalation feature disabled the SoC until the next target power cycle. This usually happens when the application in Flash crashed.

Try in the menu: "MPC5XXX" - "Tools" - "Halt core on power-on reset" and follow the instructions.´This will halt the processor before code can be executed and before reset escalation is triggered.

0 Kudos

1,246 Views
krishna2262
Contributor I

Thank you so much @rweiss , @rweiss  We got the microcontroller with censorship enabled and @petervlna the watchdog timer is disabled as it was throwing errors earlier when the watchdog timer is enabled. The solution provided by @rweiss it is working ,but it is only working for one time and when we close the trace32 window it is always going into the debug failure again. These are the steps which i followed to do the same steps which you  have mentioned:

 

krishna2262_0-1686897355541.png

 

 

krishna2262_1-1686897359921.png

krishna2262_3-1686897380202.png

krishna2262_0-1686897648277.png

 

 

krishna2262_5-1686897388831.png

krishna2262_6-1686897412720.png

 

And if i see the signals present in the Canoe, i am not able to find any other signals which are coming from IECU as seen in the image below:

krishna2262_7-1686897483107.png

 

And even the ECU is not listing in our tool to flash the Software.

Please help me out with this issue 

 

 

 

 

0 Kudos

1,227 Views
rweiss
Contributor V

Hi krishna2262,

if the watchdog is disabled, then there must be another condition causing resets. Again, those resets will eventually trigger reset escalation. Try to set breakpoints to the interrupt vector addresses (all but external input and system call), see if any unexpected interrupts occur.

Regards,
Reinhard

0 Kudos

1,145 Views
krishna2262
Contributor I

Hello @rweiss ,

I do not understand where to find the interrupt vector addresses are, so that i can put the break points. Also now if i am checking the canoe the signals are not coming is it because the ECU went into censorship ? as the data sheet contains that censorship is enabled. And when the system is running it is working more that one time but unable to debug the code which i am loading it. 

0 Kudos