Hi Gerrit,
Does the same problem was present when the MCUs were unprogrammed?
Could you please try flashing the boards presenting the issue with the periph_blinky example from the LPCOpen package and let me know if the problem is also present? This is to check if the software is in some way causing a short circuit.
For flash-based parts, the LPC18xx boots from internal flash by default (boot pin P2_7 is HIGH). If the boot pin is sampled LOW on reset, the boot source is determined by the setting of the OTP or the states of pins P2_9, P2_8, P1_2, and P1_1. How are you configuring the part to boot?
Hope it helps!
Best Regards,
Carlos Mendoza
Technical Support Engineer
Hello Paul
Were you able to resolve this problem?
We're experiencing the exact same thing on one of our custom PCBs.
Kind regards,
Gerrit
Hi,
This is probably a problem with the logic levels between the computer and your target MCU, I would recommend you to review the following document about the design considerations for debug, especially the “Logic Levels and Ground” section. Let me know if this helps.
https://community.nxp.com/message/630601
Hope it helps!
Best Regards,
Carlos Mendoza
Technical Support Engineer
Hi Carlos,
Thanks for your reply.
We're using the Keil ULINKpro debugger and we're not facing the issue when the probe is connected.
The problem (on our side) appears when the board is running in stand-alone mode (no programmers connected)
There are not latch-up scenario's that could induce this problem.
We even removed all our peripheral HW IC's to check this.
We also tried different rise times on the power supply with no effect.
What we see is:
- Reset line of MCU is kept low at all time and the MCU is consuming lots of current. (MCU consumes >0.5A at 1.14V)
- Quickly power cycling the MCU will allow you to have a normal boot scenario
- Waiting for about 30s will put you back into the high current consumption scenario
- It's not isolated to one PCB. We have three PCB's and two are having this issue.
Kind regards,
Gerrit