LPC Microcontrollers中的主题 Re: Attempting to debug board causes chip to become bricked.

Attempting to debug board causes chip to become bricked.

lpcware — Wed, 15 Jun 2016 17:32:36 GMT

Content originally posted in LPCWare by nickogden on Tue Nov 04 18:53:04 MST 2014
Hi,

I have a board that I am trying to run the webserver demo on from the LPCOpen library. I have two workspaces, one with all the LPCOpen demo code and another where I copied just the webserver project into. I can debug the webserver demo from the first workspace and everything works. When I try to debug the webserver code from the other workspace the debug process freezes, LPCXpresso crashes, and the board becomes bricked. I then have to use the FlashMagic program to clear the chip before I can program it again.

The only thing that is different between the two workspaces is that I modified the board.c file in the workspace where the code crashes. Other than that I don't seem to have any leads on what is causing the problem.

The error that pops up is this:

15: Target error from Commit Flash write
System rejected access at location 0x400FC040 - verify Population of memory and peripherals

and

15: Target error from Read Memory
Cannot complete transaction, even after slowing speed.

Here is the console when the process fails:

LPCXpresso Debug Driver v7.4 (Sep 8 2014 17:48:23 - crt_emu_cm3_nxp build 21)
Emu(0): Conn&Reset. DpID: 2BA01477. Info: HID64HS12
SWD Frequency: 3000 KHz. RTCK: False. Vector catch: False.
Packet delay: 0 Poll delay: 0.
Loaded LPC175x_6x_512.cfx: LPC175x_6x (512K) Sep 15 2014 17:39:55 On-chip Flash Memory
NXP: LPC1769 Part ID: 0x00000000
Connected: was_reset=true. was_stopped=false
v LPCXpresso Free License - Download limit is 256K
Writing 44048 bytes to address 0x00000000 in Flash
Erased/Wrote page 0-7 with 32768 bytes in 4458msec
Erased/Wrote page 8-10 with 11280 bytes in 1562msec
Flash Write Done
Flash Program Summary: 44048 bytes in 6.02 seconds (7.14 KB/sec)
Target error from Commit Flash write: Em(12). System rejected access at location 0x400FC040 - verify Population of memory and peripherals
Target error from Read Memory: Em(11). Cannot complete transaction, even after slowing speed.

and

$1 = 0xff
The target endianness is set automatically (currently little endian)

The GDB trace is:

070,704 2-environment-cd "C:/Users/nick/Desktop/work stuff/code/Alto/webserver"
070,720 2^done
070,720 (gdb)
070,720 3-gdb-set breakpoint pending on
070,736 3^done
070,736 (gdb)
070,736 4-enable-pretty-printing
070,751 4^done
070,751 (gdb)
070,751 5-gdb-set python print-stack none
070,767 5^done
070,767 (gdb)
070,767 6-gdb-set print object on
070,782 6^done
070,782 (gdb)
070,782 7-gdb-set print sevenbit-strings on
070,798 7^done
070,798 (gdb)
070,798 8-gdb-set charset ISO-8859-1
070,814 8^done
070,814 (gdb)
070,814 9-gdb-set auto-solib-add on
070,829 9^done
070,829 (gdb)
070,829 10-file-exec-and-symbols --thread-group i1 "C:/Users/nick/Desktop/work stuff/code/Alto/webse\
rver/Debug/webserver.axf"
070,845 10^done
070,845 (gdb)
070,845 11set remotetimeout 60000
070,860 &"set remotetimeout 60000\n"
070,860 =cmd-param-changed,param="remotetimeout",value="60000"
070,860 11^done
070,860 (gdb)
070,860 12-target-select extended-remote | crt_emu_cm3_nxp -msg-port=57914 -g -mi -2 -pLPC1769 -vend\
or=NXP -e0 -wire=hid -flash-driver=LPC175x_6x_512.cfx
071,328 =thread-group-started,id="i1",pid="42000"
071,328 =thread-created,id="1",group-id="i1"
071,328 13-list-thread-groups --available
071,375 *stopped,frame={addr="0x1fff0ba6",func="??",args=[]},thread-id="1",stopped-threads="all"
071,375 12^connected
071,375 (gdb)
071,375 13^error,msg="Can not fetch data now."
071,375 (gdb)
071,375 14set mem inaccessible-by-default off
071,391 &"set mem inaccessible-by-default off\n"
071,391 =cmd-param-changed,param="mem inaccessible-by-default",value="off"
071,391 14^done
071,391 (gdb)
071,391 15mon ondisconnect cont
071,406 &"mon ondisconnect cont\n"
071,422 15^done
071,422 (gdb)
071,422 16set arm force-mode thumb
071,438 &"set arm force-mode thumb\n"
071,438 =cmd-param-changed,param="arm force-mode",value="thumb"
071,438 16^done
071,438 (gdb)
071,438 17-target-download
071,484 17+download,{section=".text",section-size="44040",total-size="431005"}
071,484 17+download,{section=".data",section-size="8",total-size="431005"}
071,985 18-list-thread-groups
078,620 17^error,msg="Error finishing flash operation"
078,620 (gdb)
078,620 19-interpreter-exec console "mon capabilities"
078,636 18^done,groups=[{id="i1",type="process",pid="42000",executable="C:\\Users\\nick\\Desktop\\wo\
rk stuff\\code\\Alto\\webserver\\Debug\\webserver.axf"}]
078,636 (gdb)
078,636 20-list-thread-groups i1
078,651 19^done
078,651 (gdb)
078,651 21-interpreter-exec console "mon semihost enable"
078,667 20^done,threads=[{id="1",target-id="Thread <main>",frame={level="0",addr="0x1fff0ba6",func="\
??",args=[]},state="stopped"}]
078,667 (gdb)
078,682 21^done
078,682 (gdb)
078,698 22-interpreter-exec console "mon info,all"
078,714 23-stack-info-depth --thread 1 11
078,807 22^done
078,807 (gdb)
078,994 23^done,depth="3"
078,994 (gdb)
079,026 24-data-list-register-names
079,026 25-stack-list-frames --thread 1
079,041 24^done,register-names=["r0","r1","r2","r3","r4","r5","r6","r7","r8","r9","r10","r11","r12",\
"sp","lr","pc","","","","","","","","","","xpsr","","","","","","","","","","","","","","","","","",\
"","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","\
","","","","","","","","","","","","","","","cycles"]
079,041 (gdb)
079,041 25^done,stack=[frame={level="0",addr="0x1fff0ba6",func="??"},frame={level="1",addr="0x1fff0c\
be",func="??"},frame={level="2",addr="0x1fff0cbe",func="??"}]
079,041 (gdb)
079,041 26-gdb-show --thread-group i1 language
079,057 26^done,value="auto"
079,057 (gdb)
079,057 27-gdb-set --thread-group i1 language c
079,072 27^done
079,072 (gdb)
079,072 28-interpreter-exec --thread-group i1 console "p/x (char)-1"
079,088 ~"$1 = 0xff\n"
079,088 28^done
079,088 (gdb)
079,088 29-data-evaluate-expression --thread-group i1 "sizeof (void*)"
079,104 29^done,value="4"
079,104 (gdb)
079,104 30-gdb-set --thread-group i1 language auto
079,119 30^done
079,119 (gdb)
079,120 31-interpreter-exec --thread-group i1 console "show endian"
079,136 ~"The target endianness is set automatically (currently little endian)\n"
079,136 31^done
079,136 (gdb)
079,136 32-break-insert -t -f main
079,261 32^error,msg="Cannot access memory at address 0x62a6"
079,261 (gdb)
079,261 33-list-thread-groups
079,261 34-thread-info 1
079,276 33^done,groups=[{id="i1",type="process",pid="42000",executable="C:\\Users\\nick\\Desktop\\wo\
rk stuff\\code\\Alto\\webserver\\Debug\\webserver.axf"}]
079,276 (gdb)
079,276 34^done,threads=[{id="1",target-id="Thread <main>",frame={level="0",addr="0x1fff0ba6",func="\
??",args=[]},state="stopped"}]
079,276 (gdb)
079,276 35-gdb-exit
079,292 35^exit
079,292 =thread-exited,id="1",group-id="i1"
079,292 =thread-group-exited,id="i1"

If there is some more useful information to describe the problem I am having I will provide it.

Re: Attempting to debug board causes chip to become bricked.

lpcware — Wed, 15 Jun 2016 17:32:37 GMT

Content originally posted in LPCWare by lpcxpresso-support on Tue Nov 04 21:49:18 MST 2014
Please read this FAQ for regaining debug access, which also lists possible causes.
http://www.lpcware.com/content/faq/lpcxpresso/regaining-debug-access

Re: Attempting to debug board causes chip to become bricked.

lpcware — Wed, 15 Jun 2016 17:32:38 GMT

Content originally posted in LPCWare by LabRat on Wed Nov 05 00:44:38 MST 2014

Quote: nickogden
If there is some more useful information to describe the problem I am having I will provide it.

..schematic and changes in board.c...

Re: Attempting to debug board causes chip to become bricked.

lpcware — Wed, 15 Jun 2016 17:32:38 GMT

Content originally posted in LPCWare by nickogden on Wed Nov 05 14:03:01 MST 2014
I read the FAQ. That is how I found out how to use FlashMagic to recover debug access. At this point I don't have any trouble regaining access to the board after it becomes bricked.

The problem I am having is that when I attempt debug the chip from my current workspace it will crash LPCXpresso and brick my board. If I switch workspaces then everything works fine. I would like to know what could cause this.

Re: Attempting to debug board causes chip to become bricked.

lpcware — Wed, 15 Jun 2016 17:32:39 GMT

Content originally posted in LPCWare by nickogden on Wed Nov 05 14:17:20 MST 2014
Also, I removed my modified board project and replaced it with the board project included in LPCOpen. I am still having the same problem so I assume the board files are not to blame.

So the only difference I see between the webserver project that works and the webserver project that does not work is which workspace I am in.

Re: Attempting to debug board causes chip to become bricked.

lpcware — Wed, 15 Jun 2016 17:32:39 GMT

Content originally posted in LPCWare by lpcxpresso-support on Wed Nov 05 14:55:41 MST 2014
Try deleting the Debug (launch) configuration (*.launch files in your project) and then start another debug session. This will have the effect of resetting your configuration to the defaults.

If that does not work, please post your non-working project(s)

Re: Attempting to debug board causes chip to become bricked.

lpcware — Wed, 15 Jun 2016 17:32:40 GMT

Content originally posted in LPCWare by nickogden on Wed Nov 05 16:32:21 MST 2014
I deleted the debug.launch file and started another debug session. Nothing has changed.

I have attatched my copy of the webserver project from LPCOpen. It should be exactly the same as the one on the website, except I turned off DHCP and set the address to 192.168.112.250. I doubt that is related to my problem though.

Re: Attempting to debug board causes chip to become bricked.

lpcware — Wed, 15 Jun 2016 17:32:41 GMT

Content originally posted in LPCWare by lpcxpresso-support on Wed Nov 05 18:29:42 MST 2014
I have just imported your project (together with the chip and board projects from LPCOpen) and it works perfectly, every time.

Exactly which board are you using?

Re: Attempting to debug board causes chip to become bricked.

lpcware — Wed, 15 Jun 2016 17:32:41 GMT

Content originally posted in LPCWare by nickogden on Wed Nov 05 18:41:44 MST 2014
My project uses a custom LPC1769 board. However, the same thing happens on other boards. For example, I just now opened a new OM13000, connected it to my computer, and attempted to debug it. The board is now bricked and it happened in exactly the same way as all the others.

Also I am using the most recent version of LPCXpresso, 7.4.0, build 229.

Re: Attempting to debug board causes chip to become bricked.

lpcware — Wed, 15 Jun 2016 17:32:42 GMT

Content originally posted in LPCWare by lpcxpresso-support on Wed Nov 05 21:58:15 MST 2014
Please try what I did:
- open a new workspace
- import your project
- import the chip and board projects from lpcopen

Re: Attempting to debug board causes chip to become bricked.

lpcware — Wed, 15 Jun 2016 17:32:42 GMT

Content originally posted in LPCWare by nickogden on Wed Dec 10 14:23:29 MST 2014
Problem solved.

For some reason the file iocon_17xx_40xx.h was not the same as the most recent version of LPCOpen. These definitions for the pull-up/pull-down control were:

#define IOCON_MODE_INACT        0x2/*!< No addition pin function */
#define IOCON_MODE_PULLDOWN     0x3/*!< Selects pull-down function */
#define IOCON_MODE_PULLUP       0x0/*!< Selects pull-up function */
#define IOCON_MODE_REPEATER     0x1/*!< Selects pin repeater function */

instead of

#define IOCON_MODE_INACT        (0x2 << 2)/*!< No addition pin function */
#define IOCON_MODE_PULLDOWN     (0x3 << 2)/*!< Selects pull-down function */
#define IOCON_MODE_PULLUP       (0x0 << 2)/*!< Selects pull-up function */
#define IOCON_MODE_REPEATER     (0x1 << 2)/*!< Selects pin repeater function */

which was somehow causing the board to become bricked. My guess is that the lack of the shift meant that one of the JTAG pins was being configured improperly. At any rate, everything seems to be working now. Thank you for your help.