First - I have used many cpus in the LPC21xx and LPC23xx family for at least 10 years now. I **always** use the same boot interface -- pullup R with delay cap on \RESET, and pullup R on BOOTSEL, wired standard way (using 2n3904) to RTS and DTR lines for use with FlashMagic. I've migrated this across numerous members of the family with no problem.
I'm using the LPC2468 for the first time on a new product (first time any LPC24xx). I have same boot structure as above, but of two (edit - four) boards built, two of them function, the other two do not. The failure appears to be that it is not booting into user code. I can use the "GO" command in FlashMagic which then boots normally, but that command actually forces entry to microcode by holding BOOTSEL down during \RESET, then issuing an "execute user code" command from there. Powering up normally just stalls. I've scoped the BOOTSEL and \RESET lines, and they are behaving as they should. I've increased the RC time on the \RESET, so now there is 60 ms or more delay after BOOTSEL goes high before \RESET goes high. All power rails are rock solid. I've checked the obvious stupid stuff (bad soldering, bypass caps, etc). I've scoped the critical lines right at the chip.
Again -- four identical boards, two work, two don't. No differences found. Chips have same date codes.
The board is designed with RTCK open. Reading arcane details led me to think this might be the problem, so I tacked a jumper onto that pin to pull it high...no help. Are there other poorly documented arcane tricks that I must use to ensure that it boots into user code? This is VERY URGENT.
Update: Additional things I've tried with no results: grounding TCK pin, allocating a pin to hold all the CPLDs in the circuit to hi-Z until well into the boot cycle. I've checked and RTCK, DBGEN, \TRST inputs all have internal pullups.
I need help here folks, gotta ship this product. I hate to start swapping out CPUs.
----------------
edit - problem solved. I will leave this here, humbly, as hope it might help others similarly ripping out hair. solution was found by brute force debugging...start with stripped code (ONLY enable output 1 pin then loop to toggle pin), then add functionality (hardware setup, interrupt enables, pin setups, sram mapping) one chunk at a time till problem found. was a simple register - used for flags - where the init was inadvertently moved to after the interrupt enables. got fooled by early tests that convinced me that first tests - super stripped code - was not operating when it actually was. humbly, j.c.
NXP folks - close any ticket that this may have opened. Thks.
