Hi,
I'm having problem flashing my code to MPC5748G (BGA 256).
When I try that with Lauterbach I get the following error in the AREA window:
file C:\projects\ips-wrappers\freescale_mpc5748g\mpc574xg.cmm saved.
debug port fail
JTAGID=0x0988101D
system.up error: received invalid OSR (0x000)
- does the target assert JCOMP while RESET is asserted?
- is the device censored?
I also tried slow reset, and "Halt core on power-on reset", both give the same result:
debug port fail
OR
target processor in reset
It seems that the cpu is stuck in reset
Any idea on how to free the cpu from reset?
Hi,
Still have the problem, When looking at the reset pin, I do see a very short reset loop
CH0 =RST, CH1=TMS, CH2=TDO
The GOOD case in which I am able to flash on another board, it looks like this:
I do not understand why do the RESET suddenly acts like that....
Did you ever fix this? I've had what I think is the same problem - using Multilink & I accidentally powered off device mid-flash. It now appears stuck in reset (reset LED is on) & will not talk to programmer... will switch the BGA but had hoped to avoid this hassle if there was some trick.
I do not understand exactly what you ask me to do.
I have a custom board and not an EVB, thus I cannot replace the MCU since it is soldered to the board.
using a flshing scrpit results in "debug port fail", using resetloop.cmm script
System.reset
SYStem.Option.SLOWRESET ON ;required due to external LVD on motherboard
SYStem.CPU MPC5748G
;SYStem.BdmClock 10MHZ
SYStem.BdmClock 1MHZ ;default value
SYStem.Option.WATCHDOG OFF
;JTAG.LOCK
JTAG.PIN ENable
; release System Reset and reset TAP Controller
JTAG.PIN NRESET LOW
WAIT 1000.MS ; wait until reset is active
;JTAG.UNLOCK
sys.up
Also results with same error.
With the right tools BGA chip could be replaced as well (even when soldered)... Since you could not distinguish if the MCU is in censorship mode, only way is to replace MCU and verify that problem is corrected, but it might not be needed. I just remembered that I had connection problem due to P&E Multilink before. Maybe you just have to fix one wire, I'll explain now what happened to me.
If P&E Multilink is not connected to PC (USB cable disconnected) it draws significant amount of current from the debug connector (don't know why, if this happened to you, you may ask P&E why do they have such design). In my case this almost completely vanished the thin PCB trace between the 3.3V power supply and the debug connector. Fortunately, on my PCB this trace was on the same layer as the debug connector itself (not in the middle layers for example) and problem could be easily seen if you look at the board. With patch-wire everything was set in place.
Look at your board, this might be also your case. For the next PCB revision width of this trace was increased 5 times to avoid same problem.
Hi Aleksander,
Please see my comment below.
Replace the micro with fresh one and check if it connects.
Do not load any code into it!
If it connects then check you script for flash initialization and check if you enabling UTEST area programing.
Hi Peter,
Can you please refer to my last comment?
If censorship is locked and can't be achieved easily, and the following doesn't work:
System.reset
SYStem.Option.SLOWRESET ON
SYStem.CPU MPC5748G
SYStem.BdmClock 1MHZ
SYStem.up
Still getting "debug port fail", what other things can be done?
Are you now referring to same problem?
Because above you have mentioned Lauterbach debugger and now you are talking about PE micro.
Peter
Currently I'm using Lauterbach debugger, The problem started when using a PE Micro BDM.
First lower the BDM frequency to 1MHz in lauterbach.
Sometimes happen that Lauterbach do not want to connect (some bug or so) and you need to restart the TRACE32 powerview instance.
If this does not solve your problem the micro can be censored and if you do not programmed censorship intentionally then micro is locked forever. But this is not so easy to achieve with Lauterbach as the censorship programed is locked by default.
Unfortunately, I have similar experience with Multilink, so we took another Lauterbach in order to avoid usage of Multilink... For a year of usage by now I didn't face any unsolvable problem with Lauterbach.
The problem happened while using PE Micro debugger, and the flashing stopped while flashing.
So it's not a problem with the placing since the chip has been flashed once, and the chip is soldered on our own board.
Assuming that I have been censored the MCU, how can I free it?
Hi,
There are few possibilities which can cause such behavior.
1. Micro is not correctly placed in socked or incorrectly soldered.
2. You have accidentally programmed censorship word and locked micro.
3. You are connecting to core which is in reset (make sure you are connecting to core 0)
system.config.core 1 1 -> in lauterbach
4. Try to lower BDM frequency in lauterbach to 1MHz
Peter
I think that you have device in censorship mode. By some reason device key is not matching to the key you are setting in your Lauterbach script file (if you set one). Check your "System.Option KEYCODE".
If you don't know the key, this device is for the trash can...
This is from the Lauterbach manual:
"If the device has been censored anyhow, it may happen that it must be dropped if the keycode is unknown. Almost all JTAG accesses are blocked, as it stated in the Reference Manual of the device. In this case the debugger can not work.
To recognize if the device is in censorship mode is almost impossible. An indication may be a similar message in the AREA window like below, after System.UP"
If you are using MPC57xx EVB and your device is stuck in reset, your red LED will be ON. If this is not the case... change the device and try again...