MCU always in reset

[Bananajoe]

Hi,

I am using MPC5743R MCU together with a new development card we developed. I have measured core and vdd power ok (vdd = 5V, core = 1.236V). The reset pin is pulled up to 5V via 4.7k resistor. But for some reason the reset is always low, and I mean always. I have never seen it high. I cannot figure out the reason for this.

Do you have any idea how to proceed or what the problem might be?

Regards,
Mathias

[Bananajoe · Accepted solution]

The problem was that PORST and RESET was connected. This was due to that 2 zero ohm resistors was installed when only one should have been installed.

[davidtosenovjan]

Good to hear. Unfortunately, I haven't noticed.

Just to add (for potential other readers of this thread) how RESET and PORST signal are supposed to be connected.

RESET and PORST cannot be connected to one input as RESET is bi-directional signal and it would keep device in POR state.

[davidtosenovjan]

Hi, that’s pretty difficult question.

Are you using internal regulator as described in the AN4998 or different approaches? What about /PORST pin? Do you measure /RSTOUT signal and power-up sequence?

[Bananajoe]

Hi David,

I understand that it is hard question but I appreciate any hints so thanks for your feedback.

I think the HW is following the AN4998, but since I did not develop the HW I cannot say for sure. It is however using the internal regulator as suggested by AN4998.

PORST pin is same as reset, never going high (also as reset pin, pulled up with 4.7K). I measured the RSTOUT and it actually goes high for about 5ms and then it goes low again when powering up the HW. What does this indicate? The reference manual for this MCU is so hard to find I have only heard rumors about its existence.

Regards,
Mathias

[davidtosenovjan]

Reference manual you may find here (MPC5743R is its single core derivative):

https://www.nxp.com/products/processors-and-microcontrollers/power-architecture/mpc5xxx-microcontrol...

Regarding your customer board: Have it ever run? Is it blank or some software is burned in the MCU? Have you measure power-up sequence along with reset signal?

[Bananajoe]

Hi again,

So MPC5743R is the same as MPC5746R ?

The MCU and board has never started up before, this is first bringup. I.e. the MCU should be empty in flash.

Here is the startup sequence.

Yellow: VDD
Green: RSTOUT
Red: Reset
Blue: LV

PORST looks exactly like Reset.

Regards,
Mathias

[davidtosenovjan]

Are you capable to connect by debugger? JTAG_ID you should be able to read even in case device is reset.

In the MPC5746R Hardware Design Guide, I have found following sentence:
"In a POR event RSTOUT is internally pull-up then actively drives low during reset PHASE3 and drives high at the end of reset PHASE3."

So it could be possibly correct.

If you lengthen time base of the scope, don't you see some RESET pulses? That is because it should be offline BIST at the beginning, it takes tens or hundreds of miliseconds, and during this time RESET is asserted.

If you see 15 RESET pulses, then the issue could be reset escalation - I would give you some other instruction what to do. Currently I am out of other ideas.

[Bananajoe]

Hi David,

This is what I see in S32 when trying to debug etc.

Connection from "127.0.0.1" via 127.0.0.1. Connection from port "55715" to 7224
PE-ERROR: Warning. Can't read registers while part is running.
PE-ERROR: Warning. Can't read memory while part is running. @0 (4 bytes)
PE-ERROR: Warning. Can't read memory while part is running. @0 (4 bytes)
PE-ERROR: Warning. Can't read memory while part is running. @0 (4 bytes)
PE-ERROR: Warning. Can't read memory while part is running. @0 (4 bytes)
PE-ERROR: Warning. Can't read memory while part is running. @1003228 (4 bytes)
PE-ERROR: Warning. Can't read memory while part is running. @1003228 (4 bytes)
PE-ERROR: Warning. Can't read memory while part is running. @1003228 (4 bytes)
PE-ERROR: Warning. Can't read memory while part is running. @1003228 (4 bytes)
PE-ERROR: Warning. Can't read memory while part is running. @1003228 (4 bytes)
Interrupt command received. Halting execution.

Device IDCODE is $00000346
Device ID revision is $00000001

Device IDCODE is $00000346
Device ID revision is $00000001
Disconnected from "127.0.0.1" via 127.0.0.1. Disconnection by port "55715" from 7224
Target Disconnected.

I cannot see the reset escalation stuff that I have been reading a lot about of late. The reset is simply never rising after the small bump in the very beginning.

By the way, here is the sequence with another board we have (but with MPC5746R insetad of MPC5743R) that actually works:

Here the reset rises as expected after 10ms.

Regards,
Mathias

[davidtosenovjan]

Is mentioned working board of the same type? Actually do you have more faulty board or it is just one prototype? It could be just some hardware failure. You could possibly try to replace an MCU with another piece or to do A-B-A swap test.

In principle MPC5746R and MPC5743R are very similar devices, there are only differences mentioned in the following appnote:

https://www.nxp.com/docs/en/application-note/AN5234.pdf

No difference from external hardware point of view.

[Bananajoe]

Still no luck on this one, I have tested another board and it behaves exactly the same with reset permanently low.

I could supply the schematics if you want, but I do not think you will find it interesting. Its pretty normal, RESET and PORST pulled up to 4.7k@5V. VRC_CTL connected to NJVNJD2873T4G and supplies the LV. TESTPIN and VDDSTBY are not connected. VDD_HV_FLASH is just decoupled as per instructions and all the others VDD pins are connected to 5V (and LV ones are connected to the product of NJVNJD2873T4G and VRC_CTL).

TDI and TDO are pulled high by MCU while TCK is low (no external pull downs or pull ups on JTAG lines).

The exact MCU we are using is SPC5743RMLQ5.

[davidtosenovjan]

You can share schematic.

If you don't want share it here, please create new case according procedure below (and put link to this thread to the body):

https://community.nxp.com/t5/Using-Our-Community-Knowledge/How-to-submit-a-new-question-for-NXP-Supp...

[Bananajoe]

Hi,

Thanks for information. I have shared it now.

Regards,
Mathias

[Bananajoe]

Hi David,

The other one that I tested OK is a completely different board. I have a few more boards of the problematic type (that this issue is about) here so I can test if it is just one board that suffers from this problem or all of them.

I will do this next week and I will update this thread then with info.

Regards,
Mathias