MPC5748G flashing failure

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

MPC5748G flashing failure

1,504 Views
kfirbenshimon
Contributor III

Following up on case 805968, I still am not able to flash the MCU, it seems that the RESET toggles quite a lot

but doesn't fall to 0 at the end as would be assumed in RESET_LOOP scenario.

 

Comparing two MCU's one which is flashable and the other that isn't:

Still have the problem, When looking at the reset pin, I do see a very short reset loop

CH0 =RST, CH1=TMS, CH2=TDO

154353_154353.pngpastedImage_0.png

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

154354_154354.pngpastedImage_1.png

Labels (1)
5 Replies

1,133 Views
kfirbenshimon
Contributor III

You have misunderstood me.

This is the scope view when connected to the JTAG connector on the board.

The values that I see with the GOO and BAD are values read from the JTAG connector when I power on the board.

I do not suspect the probe itself.

0 Kudos
Reply

1,133 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

1. If you use command sys.up in Lauterbach debugger, you should see waveforms as shown above.

2. If JTAG probe is connected and you do power-on, debugger does not send any commands to JTAG interface until you use commands like sys.up or sys.attach... . All lines will be in default state and the JTAG module on MCU should be kept in reset (ensured by JCOMP signal (if available on a chip) or by state of TCK and TMS pins).

3. If JTAG probe is disconnected, it's the same like in case (2) above. JTAG module is kept in reset and you shouldn't see any waveforms on JTAG signals.

I do not suspect the probe too, of course. I just don't understand where did you get the signals. If the JTAG probe is not connected when making the screenshots then why the TMS is toggling? It's input only. Do you use this pin as GPIO in your application? What about TCK?

JCOMP signal is not available on this device. If it is available, it is used to keep the JTAG module in reset. If it is not available, TMS and TCK pins must be pulled to '1' to ensure that the JTAG state machine is kept in reset state. Noise or unintentional toggling can bring JTAG state machine/device to undefined state.

Lukas

1,133 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi,

how does your reset circuit look like? Could you share piece of schematic? I have checked the reset signal generated by Pemicro (together with S32 Design Studio) and by Lauterbach debugger. The length of reset signal generated by Pemicro is about 120ms. In case of Lauterbach, it's about 100ms. The reset signal which I can see on the screenshots seems to be very short, so I'm wondering where it came from.

Regards,

Lukas

1,133 Views
kfirbenshimon
Contributor III

Hi Lukas,

Thanks for the quick reply.

This is the reset schematic that we use:

pastedImage_0.png

RESETn - is an input directly from JTAG.

0 Kudos
Reply

1,133 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

The screenshots are not clear to me. Did you capture them when using Lauterbach debugger?

For comparison:

pastedImage_0.png

These are signals after "sys.up" command.

1 - Reset

2 - TDI

3 - TDO

4 - TMS

As I wrote in previous post, the length of reset pulse is about 100ms.

This is just zoom when reset is released:

pastedImage_1.png

Here we can see that the debugger enters debug mode before releasing reset...

So, it's totally different than your waveforms. The reset signal does not look like reset signal generated by debugger - in both cases, working and not working.

Could you take a screenshot of reset signal after power on? Keep the debugger disconnected.

Lukas

0 Kudos
Reply