How to debug a project that doesn't get to main()?

[shareefjalloq]

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.

[shareefjalloq]

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.

[converse]

Have you designed your circuit so it will follows the https://community.nxp.com/thread/388998 ?

[shareefjalloq]

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?

[shareefjalloq]

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.

[shareefjalloq]

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'.

[shareefjalloq]

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?

[lpcxpresso_supp]

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

[shareefjalloq]

Thanks.  I tried setting the CRP to NO_ISP yesterday and it didn't help.

[converse]

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 

[shareefjalloq]

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?

[converse]

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).

[shareefjalloq]

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?