Hi,
I'm new to MCUXpresso and feel like I must be doing something wrong. I can program an LPCXpresso 812 board with the blinky LPCOpen project, but when I try to do something similar for a custom board I'm using I'm getting nowhere.
My board has the LPC812M101JDH16 and has a 10-pin SWD header and some GPIO. It will run from the IRC oscillator. I'm going through the LPCOpen project flow creating a new 'MCUXpresso IDE' project, picking the 812 and using the LPCOpen libraries I've imported into the workspace.
The default main() that is built with the project just enters an infinite loop. If I try to launch the debugger, the MCU is programmed and starts executing but if I pause it I see that its suspended at 0x1fff_00c4. If I add breakpoints inside Chip_SystemInit() or main() they don't fire. Not sure where to start from here?
Thanks.
So I've now populated a second PCB with no connections on the ISP pin, PIO0_12. I've checked this pin and it's sat at 3V3. There's nothing on this board but the debug header, a 3V3 regulator and the TSSOP16 LPC812. And I still can't even download a blinky example. What have I forgotten or missed in the datasheet?
This is the output from the debugger...
MCUXpresso IDE RedlinkMulti Driver v10.2 (Jul 25 2018 11:29:34 - crt_emu_cm_redlink build 555)
Reconnected to existing link server
Connecting to probe 1 core 0:0 (using server started externally) gave 'OK'
Probe Firmware: LPC-Link Probe v1.3 (NXP - LPC-Link)
Serial Number: WIN64HS12
VID:PID: 1FC9:0009
USB Path:
Using memory from core 0:0 after searching for a good core
Expecting vector catch on SYSRESETREQ signal
debug interface type = Cortex-M0+ (DAP DP ID 0BC11477) over SWD TAP 0
processor type = Cortex-M0+ (CPU ID 00000C60) on DAP AP 0
number of h/w breakpoints = 4
number of flash patches = 0
number of h/w watchpoints = 2
Probe(0): Connected&Reset. DpID: 0BC11477. CpuID: 00000C60. Info: <None>
Debug protocol: SWD. RTCK: Disabled. Vector catch: Enabled.
Content of CoreSight Debug ROM(s):
RBASE E00FF000: CID B105100D PID 04000BB4C0 ROM dev (type 0x1)
ROM 1 E000E000: CID B105E00D PID 04000BB008 ChipIP dev SCS (type 0x0)
ROM 1 E0001000: CID B105E00D PID 04000BB00A ChipIP dev DWT (type 0x0)
ROM 1 E0002000: CID B105E00D PID 04000BB00B ChipIP dev FPB (type 0x0)
Inspected v.2 On-chip Flash Memory LPC800_16.cfx
Image 'LPC800 (16K) Jul 25 2018 11:19:17'
NXP: LPC812
Connected: was_reset=true. was_stopped=false
Awaiting telnet connection to port 3330 ...
GDB nonstop mode enabled
Opening flash driver LPC800_16.cfx
Sending SYSRESETREQ to run flash driver
Writing 2944 bytes to address 0x00000000 in Flash
After error Nn(05). Wire ACK Fault in DAP access -
Failed to read address register in DAP - Nn(05). Wire ACK Fault in DAP access
failed read EraseSector message readyness - rc Em(17). Debug port inaccessible after access at location 0x10000C00
Closing flash driver LPC800_16.cfx
failed read Terminate message readyness - rc Em(12). Target rejected debug access at location 0x10000C08
Target error from Commit Flash write: Em(17). Debug port inaccessible after access at location 0x10000C00
Closing flash driver LPC800_16.cfx
GDB stub (crt_emu_cm_redlink) terminating - GDB protocol problem: Pipe has been closed by GDB.
Have you designed your circuit so it will follows the https://community.nxp.com/thread/388998 ?
The board I'm using now has nothing but the MCU and the debug connector attached. The MCU has internal pull-ups on all the SWD pins during reset and I'm connecting an LPC-Link which also pulls up all the relevant pins. What are you suggesting might be wrong?
Meh, after making sure all the voltages were what I expected I found my obvious mistake, I missed that the ground fill on the MCU GND pin isn't actually connected to ground. I made some quick adjustments to the layout and forgot to run DRC.
Edit: just to be clear, I've been debugging two boards here. The first one that seems to hit an unhandled ISR I think must be due to trying to reuse the SWD pins which I still need to sort out. But I'd made a new layout with a footprint fix and was trying to debug on that board with nothing but the MCU hooked up. No board is so simple that you can get away without running DRC.
Actually, I do have one related further question. In the LPC81x datasheet it talks about 3 revision identifiers that have the ISP entry pin in different locations, 1A, 2B and 4C. There's also a comment that the TSSOP16 package doesn't have this identifier. So how do I know which pin the ISP entry is on? The package I have has the markings, 'LPC812 M101J 04 02 XD37'.
As a side note, when I started to search for the errors in the log above, I found notes related to LPCLink vs LPCLink2. I was trying to download using an LPCXpresso LPC1769 from 2010. I then tried a V3 board with LPCLink2, the LPCXpresso43xx/18xx, and I can't get this to enumerate. I've now read the help files and downloaded lpcscrypt, but nothing seems to find it.
Are there limitations with the first version of LPCLink or am I just digging myself another hole?
In addition to the information from ConVerse, I would also suggest checking how you have the MCU's ISP pin connected.
Regards,
MCUXpresso IDE Support
Thanks. I tried setting the CRP to NO_ISP yesterday and it didn't help.
Try setting a breakpoint on ResetISR. This is the first peice of User code executed after the boot rom. If it doesn’t reach there, then you probably have a problem with your reset vector (or initial stack pointer) or, perhaps, you have not set the vector checksum correctly
Thanks. I think I tried setting a breakpoint on the ResetISR and it didn't fire. I'll double check later. However, aren't the things you suggested trying not under my control? The IDE should calculate the checksum and insert it right? Are there any user set configs that I should check?
Check the build log to see if the checksum is being added (typically by running the checksum utility). However, strongly suggest you try LPCXpresso support's suggestion and check that the ISP pin is not stuck 'high'. This would certainly cause you to get stuck in the boot ROM (as would an invalid checksum).
So after some more reading, that address of 0x1fff_00c4 is in the boot ROM sector. Why would there be an infinite loop in the boot code? Isn't the job of the boot code just to copy what's in flash to RAM? Have I hit an unhandled exception before the boot code has finished?