NXP LPC11U68, very strange behaviour from ISP pin (becomes a short to gnd) - Page 1
Forum section: electronics / general

author: JPortici
author_rank: Super Contributor
timestamp: September 12, 2016, 04:08:08 pm
content: hi gents, i would love to get on testing a board i designed that uses the NXP LPC11U68 microcontroller but i can't seem to program it.I have assembled three of them right now. Oscillator oscillates, power rails are clean and stable..however no programming.Actually, i can program the MCU in the first couple of seconds i connect it. After a lot of investigation i found this strange thing on the ISP pin.The pin was pulled up by a 10k resistor as suggested on the datasheed and various documents on the NXP community FAQs but the voltage is not at the expected voltage, it's at about 0.6VI measured during power on and actually the pin starts at 2.5V (logic vdd) then quite rapidly descends to 0,6V.switch power off, measure resistance between pin and GND, it's a shortbut it then rapidly gets to a respectable 6MOhm and something.I looked around the MCU and this seems to be the only pin that exibits this behaviour... did i kill the chip? i didn't do anything strange, soldered as i always do..And this is happening on all three boards. what is going on here?

author: technix
author_rank: Super Contributor
timestamp: September 12, 2016, 04:29:02 pm
content: Do you have a capacitor from that pin to GND? Maybe that can be your culprit as ISP signals are usually fairly high frequency (I run my Atmel ICE JTAG at at least 2MHz at almost all times) so you can get issues if there is a cap which shorts those high frequency signals out.

author: nctnico
author_rank: Super Contributor
timestamp: September 12, 2016, 04:46:03 pm
content: How is the USB bootloader enable pin configured?Also the watchdog may be enabled on these by default. After a watchdog reset ISP programming is disabled until the next power cycle.

author: JPortici
author_rank: Super Contributor
timestamp: September 12, 2016, 05:08:11 pm
content: no, no capacitoruh that's the pin used to enter the bootloader mode. by the way i don't actually use the bootloader, i use SWDnone of this explains the behaviour of the pin, why it becomes a short to ground :/

author: tatus1969
author_rank: Super Contributor
timestamp: September 12, 2016, 06:18:31 pm
content: is your board's 3v3 connected to the debugger's VDD input?

author: JPortici
author_rank: Super Contributor
timestamp: September 12, 2016, 06:22:14 pm
content: as per requirementsthe pin behaviour happens in every occasion. powered from the debugger, powered from the power supply, no difference.

author: tatus1969
author_rank: Super Contributor
timestamp: September 12, 2016, 07:30:23 pm
content: you say that after disconnecting supply and debugger, you measure a short to GND? that definitely smells like an NXP support ticket.

author: JPortici
author_rank: Super Contributor
timestamp: September 12, 2016, 07:40:38 pm
content: and then rises back to the expected very high impedance. i'll contact them tomorrow morning

author: tatus1969
author_rank: Super Contributor
timestamp: September 12, 2016, 08:17:33 pm
content: please keep us updated, I am curious what this ends up in. would that chip have problems at 2.5v?...

author: JPortici
author_rank: Super Contributor
timestamp: September 13, 2016, 08:01:31 am
content: the hell if i know what happened.Today one of the boards seems to be working (i only resoldered the bridge to the ISP pin pullup. i am sure i didn't screw up but the results say otherwise)I then moved on to another problem, why the chip wouldn't get out of the startup code. i saw that at any point when interveining on the PLL the debug would crash. okay, added the "USE_ROM_API" define, it skips the HAL for many things and directly access registers. now i get to the main. ye-ha.Seeing if i can solve things on the other two boards tooI was too optimistic.i hope nxp support is fast and effective, though it seems that they want to move anything non confidential to the community, where they only provide "automated" responces, but at least very fast.

author: tatus1969
author_rank: Super Contributor
timestamp: September 13, 2016, 10:34:53 am
content: good success. My last contact with NXP was two years ago, also for a LPC question. I quickly got to actually talking to an engineer (!).

author: nctnico
author_rank: Super Contributor
timestamp: September 13, 2016, 02:36:51 pm
content: I'd double check the design and every pin. Any change you can post the schematic (at least the part with the LPC11U68)? I have some designs around the LPC11U6x and LPC11E6x myself (which work ofcourse) so I could try and spot some obvious differences.

author: JPortici
author_rank: Super Contributor
timestamp: September 13, 2016, 03:23:56 pm
content: sure, why notthis is not a commercial product anyway, will only be used internallyi am actually taking notes for a new version. this one has a couple of oversights and idiocieslike not a single LEDits only purpose would be to blink once so i see that the MCU is alive but nontheless useful.there also isn't a pullup on the ISP selection pin (PIO_0.1) it shouldn't be needed but it's recommended, so i added it manually - and that's how i found out the issue.then a couple of components here and there, maybe another pair of analog inputs to keep track of something else than Vtarget and Itarget, though all the communication with the modules to log happen via the UARTfirst thing i did today was to re-check the pinout but it seems to match the datasheetAs a general info U3 is a TS1102, new low cost current sensing amp from silicon labs which i wanted to evaluate. Only tested one over the full range and it was almost never inside the claimed 0,5% error (more like 0,6 to 0,8 inside the guaranteed band) but i haven't investigated much on the correctness of my testing environment. (and of course one amp isn't a big sample. just needed to see how it perfrormed to create a correction curve..verypoorly outside the guardanteed 0,5% range but that's for very low currents anyway. understandable)

author: nctnico
author_rank: Super Contributor
timestamp: September 13, 2016, 03:56:43 pm
content: I took a quick look. Off the bat I'm missing a pull-up on PIO0.1 and a pull-down on PIO0.3. You can't tie PIO0.3 to a fixed 3V3 level because it indicates you want the bootloader to take over at startup and enumerate as a USB device (see the chapter about flash programming in the user manual). In my designs I solve this to connect PIO0.3 to another pins which signals the USB device should enumerate itself (through the 1.5k resistor on one of the USB data lines). A generic thing to remember which NXP's ARM controllers is that they always start with the bootloader. The bootloader checks the CRP (code read protection) flag and based on that the JTAG/SWD interface is enabled or not.Also: is there a battery connected to VBAT? If not, I'd check if it is allowed to run the microcontroller without VBAT present.

author: JPortici
author_rank: Super Contributor
timestamp: September 13, 2016, 04:08:59 pm
content: Quote from: nctnico on September 13, 2016, 03:56:43 pmi know about PIO0.1, i hacked one on the actual board(s).from what i remember from the datasheed the pulldonw on PIO0.3 is not required as its role to discriminate wether to launch the USB or the UART bootloader happens if PIO0.1 is low, am i correct?the battery is present but i should have added a diode from VDD to vbat, in case it wasn't.. and a diode from battery to vbat so i don't accidentaly "charge it"thank you for your helpmaybe the VBAT realm can be powered independently by the rest of the circuit but maybe the other way around is not possible?checking the datasheet..no need (in theory). page 37 of the datasheet shows the block diagram and the vbat realm is powered by vdd when it's higher than vbat+0.3V, the two supplies are connected to the same line with diodes in an or configuration.another bad thing i noticed, on all three boards the RTC clock is not clocking anymore. in one i have a faint oscillation, in the other two nothing. (and it did work, same waveforms as the demo board)this is a very bad sign, i fear

author: nctnico
author_rank: Super Contributor
timestamp: September 13, 2016, 04:12:48 pm
content: In a different design around an LPC1200 series I have a 100k Ohm resistor between RTX_OUT and the crystal. The datasheet doesn't say anything but the circuit turned up on a board from (IIRC) Keil.

author: JPortici
author_rank: Super Contributor
timestamp: September 16, 2016, 02:13:45 pm
content: Re-reviewing the datasheet- I may have killed all three chips- I may have made a biiiig misunderstatementthe application is actually running at 2.5V because i wanted to have my life easy with the conversion and i really have no space nor desire for a separate analog voltage reference, if i want to solder by hand or go dual sided smt (which i'd like to avoid.)and of course when i connected the USB cable to test stuff (which i did before i tried to program) 2.5V went to VBUS and 3.3V to each USB pin. who knows about the other damage?the next test will be made with a 3.3V regulator, same board

author: nctnico
author_rank: Super Contributor
timestamp: September 16, 2016, 02:22:40 pm
content: If you are saying you powered the chips from 5V (and usually it is a little bit more on a USB port) then it is safe to say you fried the microcontrollers.

author: JPortici
author_rank: Super Contributor
timestamp: September 16, 2016, 03:27:24 pm
content: no, no.the 5V from the usb power the LDO that give 2.5V to the systemhowever i found in the datasheet that fur USB, 3.0V < Vdd < 3.6Vfor the USB data pins:  Pad provides USB functions. It is designed in accordance with the USB specification, revision 2.0 (Full-speed and Low-speed modeonly). This pad is not 5 V tolerant.As NXP support kindly told me to refer to the community, my latest speculation: maybe the usb part fried and took something else with it, basically rendering the core uselesssomething i didn't think about, as i never use usb. damn

author: tatus1969
author_rank: Super Contributor
timestamp: September 16, 2016, 03:40:27 pm
content: Quote from: JPortici on September 16, 2016, 03:27:24 pmThe high side protection diodes at the USB inputs will supply the entire chip, pulling up the 2.5V supply to slightly more. Unless you break them thermally, I don't think that you have fried the chips. The problem is that this current can be flowing unexpected ways inside the chip, and when badly designed you could trigger something like test circuits and alike. When working for a semiconductor company ages ago, we tracked down how on earth it could be possible that EMI entering one of the pins to erase random cells of the integrated EEPROM. You can imagine how long this took us to find, and how upset our customers were.

author: JPortici
author_rank: Super Contributor
timestamp: September 16, 2016, 03:49:32 pm
content: i can imagine.well let's say that there actually are safety diodes in the usb input (but i don't think so as the mx voltage is Vdd and not Vdd+0,3 Volt.. and in the LPC11U68 demo board there are external ESD diodes)(3.3V - 2.8V) / 33 ohm series resistor = 15 mA(3.3V - 2.5V) / 33 ohm series resistor = 24 mA with no diodesi can't find info on maximum current for the protection diodes... but you know what i'm thinking.

author: tatus1969
author_rank: Super Contributor
timestamp: September 16, 2016, 04:12:49 pm
content: Quote from: JPortici on September 16, 2016, 03:49:32 pmThe limiting values say [-0.5 ~ VDD+0.5], which hints that the diode is there. And the datasheet says that the I/Os have +-100mA latchup current - which is quite a lot, they seem to have done their homework. If that applies to the USB pins as well?We also don't know if the 33 ohms are before or behind the ESD diodes.But how much current do you estimate that been drawn from the +3V3 rail? From your schematic I see only the micro itself and some SPI chip. Shouldn't have been too much?You could actually check if the diodes at USB_DP/M are still intact.But you are right, a lot of guesses...

author: JPortici
author_rank: Super Contributor
timestamp: September 16, 2016, 04:59:38 pm
content: mine are all assumptions based on what i can read from the datasheet and the drawings they care to sharere-reading a voice i didn't see before, USB data pins are rated up to Vdd + 0.5V :/ still exceeded that (measured 3.3V on the data line)

author: JPortici
author_rank: Super Contributor
timestamp: September 22, 2016, 09:34:39 am
content: New parts.Solder a minimum circuit (bypass caps, pullups, rtc, mcu) -regulator is not being powered.Works, can debug for 5 minutes. Then dead. Very funny waveforms from RTC, gabage between 2 and 3 volts

author: TiN
author_rank: Super Contributor
timestamp: September 22, 2016, 11:15:02 am
content: Sounds like some power / grounding issue perhaps?I had used LPC11U68 in multiple projects, never had issue with programming via ISP (both via UART mode and USB).