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,
Solved! Go to Solution.
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.
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.
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.
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.
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?
Which command of the FLASH script causes the bus error? It should appear
in the debugger's command line.
Am 05.02.2019 um 14:38 schrieb firstname.lastname@example.org:
NXP Community <https://community.nxp.com/?et=watches.email.thread>
Re: MPC5748G, Lauterbach multiple-reset causes error
Antwort von Muhammad Usman
in /MPC5xxx/ - Komplette Diskussion anzeigen
the error message "No such flash device" is displayed if the flash hasn't been declared yet.
Run the flash setup script before flashing.
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
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.
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
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
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.
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
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.
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:
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...