Debug Problem: Stepping not available

lpcware · ‎06-15-2016

Content originally posted in LPCWare by mrhobbles on Thu Nov 10 22:32:31 MST 2011
Hello I'm having a frustrating problem with debugging. I have two LPC1769 that work fine (aside from 1 pin I burned) and am able to run the debugger on them. However a few days ago my laptop, Asus eeepc 1000h with Windows 7, started having trouble connecting to any of my board.

I eventually got things working again except now when I enter debugging mode my only options are 'Terminate' and 'Suspend.' The 'Step' options are greyed out and not available. Also the debug no longer takes me to the first breakpoint in main, I'm not sure if anything is actually running. This happens with every board that I use with my eeepc laptop. When I start debugging the same boards on my Desktop PC(XP), or a friend's laptop(W7), everything works fine.

So far these are the steps that I tried.
1. Change USB cable
2. Try different USB ports
3. Reset into ISP mode
http://support.code-red-tech.com/CodeRedWiki/DebugAccessChip
4. Run diagnostic on LPC-Link. Everything checked out.
http://support.code-red-tech.com/CodeRedWiki/LPCLinkDiagnostics
5. Tried running sample projects in different workspace. Same problem.
6. Reinstall OS. Changed to Debian. Went through the same steps and still have the same problem.

Does anyone have any ideas? Thanks in advance.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Sun Nov 20 11:39:05 MST 2011
MEMMAP is the correct register for LPC17xx. NXP calls this register by SYSMEMREMAP for other LPC parts. The MEMMAP user flash setting is '1'. The question that comes to mind is how/why this register is set correctly for user flash, but the bootloader did not vector there? If this same code boots correctly on other LPC1769 parts, your chip is still suspect.

The entry point for your code is the ResetISR label provided you use the Code Red startup.

Regards,

CodeRedSupport

lpcware · ‎06-15-2016

Content originally posted in LPCWare by mrhobbles on Sat Nov 19 23:47:35 MST 2011

Quote: CodeRedSupport
Not a paperweight, but not ready for prime time, either. After flashing your part, the bootloader is not going to vector to user flash. If you get creative, you can still debug your code. Open the Peripherals view, and change the SYSMEMREMAP register to user flash. Set this register value equal to 1. If you then change the PC to ResetISR, it should run to main from there, or whereever you set the first breakpoint.

Regards,

CodeRedSupport.

Okay. I thought I could fix it but I'm not able to find the SYSMEMREMAP register. Under the peripheral view I've found the "SYSCTL" peripheral which contains a MEMMAP. MEMMAP's value is 0x01.

The register description sounds similar.

Quote:

Memory Mapping Control register (MEMMAP - 0x400F C040)
The MEMMAP register allows switch the mapping of the bottom of memory, including
default reset and interrupt vectors, between the Boot ROM and the bottom of on-chip
Flash memory.

With it being set to 0x01 it says the address 0 is mapped to onchip flash instead of the boot ROM. So I just need to change the PC to the reset vector, right? How do I do that? :o Under the core registers tab do I put ResetISR in place of an address?

Thanks. Sorry for all the questions.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Wed Nov 16 02:15:43 MST 2011

Quote:

How can I avoid it?

ISP pins are dangerous, so don't touch them :eek: You're not the first who wasted hours to find a delayed or damaged ISP :)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Wed Nov 16 01:01:15 MST 2011

Quote: mrhobbles

Is my target board now a paperweight? :confused:

Not a paperweight, but not ready for prime time, either. After flashing your part, the bootloader is not going to vector to user flash. If you get creative, you can still debug your code. Open the Peripherals view, and change the SYSMEMREMAP register to user flash. Set this register value equal to 1. If you then change the PC to ResetISR, it should run to main from there, or whereever you set the first breakpoint.

Regards,

CodeRedSupport.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by mrhobbles on Tue Nov 15 22:20:40 MST 2011

Quote: Zero
#1 Is there a Reset signal occurring?

#2 Is ISP pin high already?

If (external) pullups are damaged or missing or there's something connected to ISP pin or RESET pin and ISP pin is still low at Reset your bootloader is started every time :eek:

Result: no breakpoint and program is running in flash (=bootloader) :rolleyes:

I was able to put the scope on them today, Reset signal is high, ISP pin is low. :( On the LPC 1769 the ISP pin is p2.10. When I plug the board into the USB port pin p2.10 remains low. I tried using a pull up to 3.3V to see if that would get the board out of the bootloader but in the bootloader it remained.

Is my target board now a paperweight? :confused:

What can be wrong with p2.10? How can I avoid it?

I've been having pins "die" by connecting them as GPIO to the input of 74LSXX series ICs. I learned that was a bad idea so I switched to the 74HCTXX and the dead pins went away. Now I have 1 dead pin and it happens to be p2.10, the ISP pin. Argh.

On the board that I'm able to debug I have one dead pin and watching the peripheral registers I can see the SET registers changing during debugging. However, the PIN status register never changes.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Tue Nov 15 01:59:20 MST 2011

Quote:

Power, yes. What do I look for on the Reset and SWD signals?

#1 Is there a Reset signal occurring?

#2 Is ISP pin high already?

If (external) pullups are damaged or missing or there's something connected to ISP pin or RESET pin and ISP pin is still low at Reset your bootloader is started every time :eek:

Result: no breakpoint and program is running in flash (=bootloader) :rolleyes:

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Tue Nov 15 01:41:01 MST 2011

Quote: mrhobbles
It is the LPCXpresso 1769 Rev. B.

I don't know ARM assembly off the top of my head but here is a few of the instructions that are seem to be repeating indefinitely. A quick lookup says a load register command, a left shift, and a branch to the first command.

1fff0ba2:    ldr r0, [r4, #20]
1fff0ba4:    lsls r0, r0, #28
1fff0ba6:    bmi.n 0xfff0ba2

I let this run for several minutes and the debugger still stops at these instructions after I 'Suspend' the program.

The PC confirms the bootloader is executing instead of your code. For whatever reason, the bootloader did not vector to your application. This could be due to a problem flashing your code, a reset issue, or a bad checksum word. The latter is unlikely since LPCXpresso inserts it for you.

Regards,

CodeRedSupport

lpcware · ‎06-15-2016

Content originally posted in LPCWare by mrhobbles on Mon Nov 14 21:55:25 MST 2011

Quote: Zero
Working with my ASUS EeePC and XP since years without problems. Not very fast with LPCXpresso V4.1.0, but always very reliable

Are we talking about original LPCXpresso1769 boards?

It is the LPCXpresso 1769 Rev. B.

Quote:

Are you sure that your USB is still working?

Yes. I'm able to mount a flash drive for R/W operations. Going through the LPC Link diagnostic I am able to confirm the presence of an emulator, and read the info for the LPC1769 target. The 'lsusb' command list a device with the name 'NXP Semiconductors.' I get the same output on a PC that has debugging working.

Quote:

Did you try to use a Hub with external power supply

Not sure. Do you mean an external USB hub? If so, then no I did not use one. Just my laptop ports.

Quote:

Did you switch vector catch on?

Yes. I tried starting debug. Same results, no stepping available. Then switched back too non-vector catch. I've tried this a few times.

Quote:

Did you scope Power, Reset and SWD signals?

Power, yes. What do I look for on the Reset and SWD signals?

Quote: CodeRedSupport
This is because the debugger has set the breakpoint on main, and started your code, but it hasn't reached that breakpoint. So a likely cause of this is that your application is crashing before it reaches main.

You can try hitting 'Suspend' and look to see where it is running (I would guess it is in one of the exception/fault handlers)

See
http://support.code-red-tech.com/CodeRedWiki/InitialBP
and set the breakpoint on your ResetISR function, and then debug from that point to see where it is going wrong.

You might also take a look at:
http://support.code-red-tech.com/CodeRedWiki/DebugHardFault

I've had hard faults before from not powering peripherals. I figured the program simply isn't making it to the first breakpoint but using the suspend option doesn't take me to any source code or exception handler. When I use suspend I get a new window popup, 'No source available for ""' When I try and view the disassembly I keep looping over the same few instructions, I think. I still can't step due too "Can't find the bounds of the current function." I have to 'Resume', then 'Suspend' to see any changes.

I don't know ARM assembly off the top of my head but here is a few of the instructions that are seem to be repeating indefinitely. A quick lookup says a load register command, a left shift, and a branch to the first command.

1fff0ba2:    ldr r0, [r4, #20]
1fff0ba4:    lsls r0, r0, #28
1fff0ba6:    bmi.n 0xfff0ba2

I let this run for several minutes and the debugger still stops at these instructions after I 'Suspend' the program.

Okay. A new development as come up. Now it seems to be one particular LPC1769 that is not allowing any debugging. I haven't been able to contact my partner over the weekend to try it on his laptop, but switching between the boards on my desktop has one board working and one not. On the working board I can set a breakpoint in the ResetISR and debug normally and get back to the default breakpoint in main. On the 'suspect' board I can't get into even the ResetISR.

Also it seems on the LPC-Link side on the 'suspect' board, LED1 is constantly on after initializing the LPC-Link.

So the problem has progressed from two LPCXpresso 1769 boards not working on my eee pc, but working on any other computer I tried. Now I have 1 board that works with my eee pc and Desktop and the other doesn't work now.. I'm going to attempt another ISP reset among other things. I have other LPCXpresso boards I might try a new Link board.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Fri Nov 11 01:04:37 MST 2011
This is because the debugger has set the breakpoint on main, and started your code, but it hasn't reached that breakpoint. So a likely cause of this is that your application is crashing before it reaches main.

You can try hitting 'Suspend' and look to see where it is running (I would guess it is in one of the exception/fault handlers)

See
http://support.code-red-tech.com/CodeRedWiki/InitialBP
and set the breakpoint on your ResetISR function, and then debug from that point to see where it is going wrong.

You might also take a look at:
http://support.code-red-tech.com/CodeRedWiki/DebugHardFault

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Thu Nov 10 23:19:02 MST 2011
Working with my ASUS EeePC and XP since years without problems. Not very fast with LPCXpresso V4.1.0, but always very reliable :)

Are we talking about original LPCXpresso1769 boards?
Are you sure that your USB is still working?
Did you try to use a Hub with external power supply?
Did you switch vector catch on?
Did you scope Power, Reset and SWD signals?