MPC5748G, Lauterbach multiple-reset causes error

cancel
Showing results for 
Search instead for 
Did you mean: 

MPC5748G, Lauterbach multiple-reset causes error

Jump to solution
4,462 Views
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
110 Views
NXP Employee
NXP Employee

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
81 Views
NXP Employee
NXP Employee

Hi,

Lot of these scripts are usually included in latest version of Trace32 PowerView. (like halt core on power on reset)

Every user can customize its PowerView by writing a scripts.

And if you need help with writing scripts than contact Lauterbach. Their support works really well.

Peter

90 Views
Contributor III

Hi Uali, Peter,

TRACE32 can halt the processor directly at a power-on reset. This prevents the SWT or crashing application from triggering the reset escalation.

Select in the menu: MPC5XXX - Tools - Halt core at power-on reset. Then follow the instructions as displayed.

Regards,

Reinhard

81 Views
Contributor II

I had the problem with MPC5744P and your proposed solution solved it. However I am unable to flash the board. If I try to flash it with the sample given in lauterbatch for MPC5742P/MPC5744P; a bus error is generated. 

I have verified the jumper settings and they are correct according to the power from mother board and also it is set to debug configuration.

Can you explain me what can be the other possibility?

petervlna‌, davidtosenovjan‌, ivadorazinova

0 Kudos
81 Views
Contributor III

Which command of the FLASH script causes the bus error? It should appear

in the debugger's command line.

Best regards,

Reinhard

Am 05.02.2019 um 14:38 schrieb usmanimtiaz63@gmail.com:

>

NXP Community <https://community.nxp.com/?et=watches.email.thread>

>

Re: MPC5748G, Lauterbach multiple-reset causes error

Antwort von Muhammad Usman

<https://community.nxp.com/people/usmanimtiaz63@gmail.com?et=watches.email.thread>

in /MPC5xxx/ - Komplette Diskussion anzeigen

<https://community.nxp.com/message/1109147?commentID=1109147&et=watches.email.thread#comment-1109147>

>

0 Kudos
81 Views
Contributor I

Hi Weiss,

I am also facing the similar issue,

"    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) "

I have tried the above resolution,

1. Holded the reset button on my Hardware board.

2. Turned ON the power.

3. Connected the Debugger.

4. Flashed the Bootloader and Released the reset button.

Then I am facing the error "No such flash device".

How can I overcome this issue ?

0 Kudos
81 Views
Contributor III

Hi,

the error message "No such flash device" is displayed if the flash hasn't been declared yet.

Run the flash setup script before flashing.

Regards,

Reinhard

0 Kudos
90 Views
Contributor III

Hi, in my case no cmm file found for ==> - Tools - Halt core at power-on reset

what can i do ?

0 Kudos
90 Views
NXP Employee
NXP Employee

Hi,

The cmm script is attached to this reply. Easiest way is to use this scripts.

I have also described to workaround in case you do not have lauterbach in other tread in this forum.

Let me know if this helps.

Peter

90 Views
Contributor III

I have the issue again since i'm flashing the final application using the bootloader and some errors appears in the flashing process that's way i could not reset the target.

For now i have tried  the cmm file (it tell me to power on/off) but after that i get the following error: ERROR while releasing RESET: timeOut of course after the message provided in discussion (received invalid OSR etc). Is there anything to do in this case or any other scripts that i can try

thanks

0 Kudos
90 Views
NXP Employee
NXP Employee

Hi,

By explaining issue in details with "Some errors appears in the flashing process" you gave me really good picture of the issue.

Maybe would be good to explain what errors and what exactly caused them.

If you are playing with UTEST flash, you most probably locked micro via censorship.

If halt on power on reset script does not work I expect this to be the reason.

Peter

90 Views
Contributor III

petervlna The error is caused after trying to accomplish the following sequence:

1. Flash the application on the target : MPC5748G

2. Copy the bootloader to RAM

3. Use the bootloader to flash the final application (6Mb) , maybe i have not erased some adresses before the flash because in this step target reset will show

I'm just in an internship, i  don't know about the UTEST , i found that it's a area in the beginning of RAM and also i don't know about the details of every step.

I'm stuck in this issue , if you need more details just tell me were i can find them thanks

0 Kudos
90 Views
NXP Employee
NXP Employee

Hi,

If you load the application to flash via debugger and not via bootloader application is it working?

Peter

90 Views
Contributor III

Flashing with JTAG was working but after the issue i could not flash using JTAG and the message erros appeared in trace32 .. but also the script poweronreset worked for one time after dispalying "thanks you".I found a breakpoint but i don't know what to do i have make steps but they will not finish so i click on run (go) and got the same problem again

Note that the script worked only once but i don't know why it hasn't worked after that @Peter Vlna

0 Kudos
90 Views
NXP Employee
NXP Employee

Ok, you cannot connect with debugger after loading an application to micro.

Are you sure you are not playing with UTEST flash? (censorship area or DCF records)

Which Lauterbach script you have used to load the code into flash?

Do you have you XBAR clocks configured properly within the specification?

Did you try to lower BDM speed to 1MHz from default 4MHz in debugger?

Did micro stay in permanent reset?

What about stand alone? Is it running?

Did it generate any output signal? (output clock, pwm, fault state of FCCU...)

If you do not give me a full ;picture of what are you doing I cannot guide you.

Peter

90 Views
Contributor III

I really didn't understund anything of what you're saying but i finally solved the issue with the same script you gave to me thanks a lot ... It have been for about 3 month i'm developping for the MPC target and there is a lot of things to learn the dataSheet contains everything but i need more time .... btw do you know in any case the MPC is censored and nothing can be done to it since i don't want to have the same issue again... thanks for your time

0 Kudos
81 Views
NXP Employee
NXP Employee

To not censor micro, you need to stay away from UTEST flash memory.

By default debuggers denies the programing to this area and require modification of programing script to do so.

Therefore it is hard to lock micro by accident.

And as you are new to MPC I do not expect you will play with OTP areas on microcontroller.

Peter

81 Views
Contributor III

I understund now since the UTEST is an OTP memory

0 Kudos
90 Views
Contributor V

chfakhtchfakht​ is it possible that you accidentally censored your MCU (or part of its blocks)?

90 Views
Contributor III

alexvinchev​  Please what censorchip means ? how it can be censored .... However i have not touch the board for about 24 hours and i tested again the script and it worked with the first test i clicked attach and i was able to connect with the MCU but i don't why it didn"t work in the previous tests ! thanks for your help :smileyhappy:

0 Kudos
90 Views
Contributor V

chfakhtchfakht Or maybe in your code you're referring RAM area which is not initialized or Flash address space, which does not exist (Like 0x00F88000 block for example)... In this case you'll get machine check exception, which could lead to reset...

0 Kudos