MPC5748G flashing fail

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

MPC5748G flashing fail

4,751 Views
kfirbenshimon
Contributor III


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?

Labels (1)
15 Replies

3,040 Views
kfirbenshimon
Contributor III

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

pastedImage_0.png

The GOOD case in which I am able to flash on another board, it looks like this:

pastedImage_1.png

I do not understand why do the RESET suddenly acts like that....

0 Kudos
Reply

3,040 Views
coflynn
Contributor II

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.

0 Kudos
Reply

3,040 Views
kfirbenshimon
Contributor III

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.

0 Kudos
Reply

3,040 Views
alexvinchev
Contributor V

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.

3,040 Views
kfirbenshimon
Contributor III

Hi Aleksander,

Please see my comment below.

0 Kudos
Reply

3,040 Views
petervlna
NXP TechSupport
NXP TechSupport

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.

0 Kudos
Reply

3,040 Views
kfirbenshimon
Contributor III

Hi Peter,

Can you please refer to my last comment?

0 Kudos
Reply

3,040 Views
kfirbenshimon
Contributor III

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?

0 Kudos
Reply

3,040 Views
petervlna
NXP TechSupport
NXP TechSupport

Are you now referring to same problem?

Because above you have mentioned Lauterbach debugger and now you are talking about PE micro.

Peter

0 Kudos
Reply

3,040 Views
kfirbenshimon
Contributor III

Currently I'm using Lauterbach debugger, The problem started when using a PE Micro BDM.

0 Kudos
Reply

3,040 Views
petervlna
NXP TechSupport
NXP TechSupport

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.

0 Kudos
Reply

3,040 Views
alexvinchev
Contributor V

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.

3,040 Views
kfirbenshimon
Contributor III

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?

0 Kudos
Reply

3,040 Views
petervlna
NXP TechSupport
NXP TechSupport

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

0 Kudos
Reply

3,040 Views
alexvinchev
Contributor V

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...

0 Kudos
Reply