9 years, 9 months ago.

When plug a LPC4088QSB into my embedded design and upload firmware via USB, I get a BSOD

I am making use of a LPC4088 Quick Start Board from Embedded Artists with built-in mbed HDK. I plug it into a custom board that I designed. If I try to update the program running on the LPC4088 via the mbed HDK USB connection, the transfer starts briefly and then I get the Blue Screen of Death (BSOD). [I am running a 32-bit version of Windows 7]. This happens every time. If I unplug the LPC4088QSB from my board and power it from USB, the transfer happens without any problems. Any idea on what could be causing the BSOD?

The UART0 serial port, which is used by the HDK, is brought out to a header but no components are attached to the RX and TX signals (like pull-ups/downs).

The ISP-EN signal is being used as a GPIO with an external pull-up, but it appears that the ISP-EN signal is a LPC4088 thing and not part of the HDK.

The only other signals that I can tell being used by the HDK and by my board is the RESET-IN-N. I have an external 4.75k pull-up and I now wonder if that's preventing the HDK microcontroller from being able to reset the LPC4088.

Another possibility is that I need to run my LPC4088QSB at 5.25V instead of the typical 5V. The mbed USB connector is supplying a voltage slightly below 5V due to the voltage drop across the USB connector. However, the diodes on the LPC4088QSB should prevent any issues here.

Any ideas are greatly appreciated. I am leaning toward the pull-up on RESET-IN-N preventing the HDK micro from being able to reset the LPC4088 - still, why does this cause the driver to cause a BSOD?

After some work, I determined that it was indeed the external pull-up. The reset circuit on the LPC4088QSB barely gets the RESET_IN signal below its low voltage threshold and my 4.75k pull-up was not helping.

Still, a BSOD is a really bad way of reporting an error. It seems that the mbed HDK firmware could do a better job of detecting a lack of reset and ending gracefully. Is that firmware actively being developed or is it frozen except for minor updates?

posted by Stephen Goadhouse 23 Jul 2014

It sounds like a specific issue on your PC. If it cannot pull reset low, it won't directly notice it (at least I assume it doesn't read the reset status back), but it won't be able to succesfully communicate over SWD. Now search on "SWD ERROR", and you see that that has been a problem for enough other people, but never with a BSOD.

I wonder also what the QSB uses as pull-up, since I would expect such a line to get easily close to zero volt.

posted by Erik - 23 Jul 2014

I failed to mention that the "PC" is really a virtual machine running in Parallels 9 on my Mac. So it is quite likely that the BSOD is a result of the interaction between the virtual USB bits within the VM and the error condition caused by the "SWD ERROR". Thanks for pointing that out.

The problem with the reset assertion voltage is that NXP recommends a RC low pass filter on the reset input due to an issue with the RTC losing time due to too many reset edges (see the LPC4088 datasheet for more info). They use to recommend a 15k series resistor for the RC and now recommend 10k. The reset input has an internal pull-up with a 50-85 uA current sink. Across 15k, 50 uA results in a 750 mV drop. So already at a disadvantage with a relatively high voltage for a logic low signal. If it gets as high as 85 uA, with a 15k series resistor the reset input cannot go below 1.275V which will never be seen as a logic low and you will never reset the processor.

posted by Stephen Goadhouse 23 Jul 2014
Be the first to answer this question.