The code I jump to from the bootstrap loader is tiny and merely sets a variable and branches to where the reset vector normally starts code execution from. There's nothing special, tricky, or extensive in it. If I start up with the BOOT pin high, everything works great. Otherwise, when I eventually enable the USART0 receive data ready interrupt the character timeout interrupt starts and remains active forever. There does not appear to be any way to clear it. Is there anyone out there who interacts with the bootstrap loader like this with an LPC11U68 that doesn't have this problem, or who figured out how to clear this interrupt? Thanks for any help with this.
Note that the bootstrap loader interaction is quite minimal, and is used merely to jump (GO command) to a specific address to set a value in memory and then branches to where the RESET vector goes to normally to execute the startup code. So, all the initialization is identical (other than writing one value to memory first) whether the BOOT pin is high or low on startup. So, I'm certain that there's no odd-user-code thing happening due to this tiny piece of code that gets branched to [when the user wants to start manufacturing test mode]. I didn't see any chip errata that mentions this bug, but it seems like there should be (and a workaround provided for it).
We have a similar problem with some LPC1769 devices. Not all of them. In a debug session, after restarting a device using the 'Restart' button on the toolbar of MCUXpresso, the device ends up in an loop of eternal interrupt handling for either a serial port device or the CAN bus controller. The interrupt sources it self are bogus, as for example nothing is transmitted to the serial port. (Rx, Tx lines verified with scope) Once the device is in such a state, then the only way to get it out is by hard resetting the device (power cycle or issuing the WIRETIMEDRESET reset command on the RedlinkServer console) - trying another restart with the 'Restart' button will not help... Note that most devices do not have this behavior, but the ones that do are very persistent in it. NXP: Is this a known problem? Additional note: On advise from other developers, I already tried setting following debug options: Reset Handling = SYSRESETREQ, Semihosting support = Off, Vector catch = True. But this does not seem to help...
I discovered this problem with continuous repeating CTI interrupts during embedded testing. I tried the fix suggested above, read LSR and RBR every time the UART IRQ fires. That did not solve the problem in all cases. Through trial and error I discovered that reading the Interrupt Identification register (IIR) every time the UART IRQ fires did prevent the continuous repeating CTI interrupts in all of our test cases. Other scenarios may exist where this method does not work.
I have the same problem with my LPC11U68 based board, although only in a certain scenario. If I power up my board with the BOOT pin high (normal start mode) I do not have have this problem. However, if I power up with the BOOT pin low and interact with the built-in bootstrap loader I do have the problem. Worse, none of the above fixes make the problem go away. Basically, as soon as I clear then enable the USART0 interrupt the USART ISR gets stuck in a loop where the interrupt ID is 6 (character timeout) and nothing I do actually clears this interrupt so that the ISR will stop triggering. I too have used an o-scope to verify that the RX line is stable in the mark state. For debug, I decided to read the IIR, LSR, MSR, and RBR every time the ISR is vectored to, but even that won't clear this interrupt. Can anyone provide some guidance to help me resolve this?
P.S. I'm using the bootstrap loader interaction to allow my app to know which way it started (normal reset, or bootstrap loader interaction) to make my app act in a special way when started via the bootstrap loader (i.e., to enable manufacturing test mode). We use this technique on a variety of ARM Cortex M based boards, but this is the only one that has this behavior. It's also the first LPC11U68 board we've tried this on.