Hi Lubomir,

I tried your cfg file (slightly adjusted for LPC1766 and 12Mhz xtal) and
your .gdbinit commands, and I still have the issue.

It gets to the reset vector allright, but if I continue or single step I
get lost at 0xfffffff8 ..... :-(

The dump from openocd is:

----------------------------
$ ./openocd.exe
Open On-Chip Debugger 0.5.0-dev (2010-09-29-12:40)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter_nsrst_delay: 300
jtag_ntrst_delay: 300
srst_only separate srst_gates_jtag srst_open_drain
50 kHz
Info : device: 4 "2232C"
Info : deviceID: 67330064
Info : SerialNumber: TLTKDK15A
Info : Description: Turtelizer JTAG/RS232 Adapter A
Info : clock speed 50 kHz
Info : JTAG tap: lpc1766.cpu tap/device found: 0x4ba00477 (mfg: 0x23b,
part: 0xba00, ver: 0x4)
Info : lpc1766.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection from 3333
Warn : acknowledgment received, but no packet pending
undefined debug reason 6 - target needs reset
Info : JTAG tap: lpc1766.cpu tap/device found: 0x4ba00477 (mfg: 0x23b,
part: 0xba00, ver: 0x4)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc
force hard breakpoints
flash 'lpc2000' found at 0x00000000
Warn : Verification will fail since checksum in image (0x00000000) to be
written to flash is different from calculated vector checksum
(0xefff7f43).
Warn : To remove this warning modify build tools on developer PC to
inject correct LPC vector checksum.
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xffffffc4
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xffffffc4
Warn : Block read error address 0xffffffc0
Warn : stepi ignored. GDB will now fetch the register state from the
target.
Warn : lpc1766.cpu -- clearing lockup after double fault
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xfffffffc
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xfffffffc
Warn : Block read error address 0xfffffff8
------------------------------------------------

Looks like the problem is all error up in the 0xfffffffx area ..

What do I do now? Is it a possiblity my JTAG hardware is faulty?
(Turlilizer2)

Thanks,
Bernie


-----------------------------------------------------------------
Hi All

I am here new, this is my first message, and may not be send overall.

I use FT2232H (self-made). Mometally with LPC1768 (is almost same as
LPC1766).

This is my .gdbinit

file <name>.elf
target remote localhost:3333
monitor reset halt
monitor gdb_breakpoint_override hard
monitor flash probe 0
load

Cfg.File:

# NXP LPC1768 Cortex-M3 with 512kB Flash and 32kB+32kB Local On-Chip
SRAM, clocked with 4MHz internal RC oscillator

if { [info exists CHIPNAME] } {
 set  _CHIPNAME $CHIPNAME
} else {
 set  _CHIPNAME lpc1768
}

if { [info exists ENDIAN] } {
 set  _ENDIAN $ENDIAN
} else {
 set  _ENDIAN little
}

if { [info exists CPUTAPID ] } {
 set _CPUTAPID $CPUTAPID
} else {
 set _CPUTAPID 0x4ba00477
}

#delays on reset lines
jtag_nsrst_delay 200
jtag_ntrst_delay 200

# LPC2000 & LPC1700 -> SRST causes TRST
reset_config trst_and_srst separate srst_gates_jtag trst_open_drain
srst_open_drain

# Voltage output for device powering
voltage_config vout_5v0

jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf
-expected-id $_CPUTAPID

set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME cortex_m3 -endian $_ENDIAN -chain-position
$_TARGETNAME

# LPC1768 has 32kB of SRAM on its main system bus (so-called Local
On-Chip
SRAM)
$_TARGETNAME configure -work-area-phys 0x10000000 -work-area-size 0x8000
-work-area-backup 0

$_TARGETNAME configure -event reset-init {
#       do not remap 0x0000-0x0020 to anything but the flash
}

# LPC1768 has 512kB of user-available FLASH (bootloader is located in
separate dedicated region).
# flash bank lpc1700 <base> <size> 0 0 <target#> <variant> <cclk>
[calc_checksum]

set _FLASHNAME $_CHIPNAME.flash
flash bank $_FLASHNAME lpc2000 0x0 0x80000 0 0 $_TARGETNAME lpc1700
10000 calc_checksum

# 4MHz / 6 = 666kHz, so use 500
jtag_khz 500

########################################################################
###############

All this works very fine. I suggest to place pull-up at pin P2.10. (The
Olimex board has probably jumper there).
Otherwise after each reset command "mwb 0x400FC040 0x01" must be issued.

command:
reset halt always stops execution at 0x00000000 after the BootLoader
prolog was executed. Bootloader prolog reads P2.10 and if High execution
at 0x00000000 starts, OpenOCD ocd executes "reset halt" as placing
temporarely breakpoint at address 0x00000000.

As I understood it the "Error: JTAG-DP STICKY ERROR" access to location
which is either not existent or powerred down was executed. In this case
0xFFFFFFFC address, this will cause BusFault Error at CPU.

Checksum error is not relevant OpenOCD corrects it. Checksum is only
used by bootloader. OpenOCD uses part of BootLoader in form of IAP
commands, but the checksum is check only when flashing via UART.

Lubomir VALEK

> Message: 3
> Date: Tue, 12 Oct 2010 09:04:56 +1300
> From: "Bernard Mentink" <[email protected]>
> To: <[email protected]>
> Subject: [Openocd-development] Problem getting reliable "reset init"
> on LPC1766 target.
> Message-ID:
> <f7c0aa5dd1508f4789e10b6cc9bb75db03dbd...@nzc-ap-xch-02.ap.trimblecorp
> .net>
>
> Content-Type: text/plain; charset="us-ascii"
>
>
>> Hi All,
>>
>> I am using an FT2232D based debugger board with the Olimex LPC1766 
>> STK development board. I have compiled the latest OpenOCD and am 
>> running it from Cygwin.
>> I also am running GDB from within eclipse(Zylin) ... although that is

>> irrelevant since the same error exists on the command line.
>>
>> My problem is this:
>>
>> I am not getting a reliable target reset, sometimes the PC ends up in

>> the booloader area, sometimes at the end of memory, and sometime I 
>> end up correctly in Main().
>> It seems to be more reliable when I run the JTAG at 50khz rather than

>> the suggested 500Khz (assuming running on internal 4Mhz clock), as I 
>> don't know what the bootloader does with the PLL, I have no idea what

>> the JTAG clock should be ..
>>
>> This is a dump of the output from OpenOCD when I start from power up 
>> with a 50Khz clock, the 1st part of the log, I get dumped staight 
>> into bootloader, the flash erase does not happen. I then Re-connect 
>> GDB and I get a sucessful halt at main.
>>
>> ---------------------------------------------------------------------
>> -
>> -----------------------------------------------
>> $ ./openocd.exe
>> Open On-Chip Debugger 0.5.0-dev (2010-09-29-12:40) Licensed under GNU

>> GPL v2 For bug reports, read
>>         http://openocd.berlios.de/doc/doxygen/bugs.html
>> Info : only one transport option; autoselect 'jtag'
>> adapter_nsrst_delay: 300
>> jtag_ntrst_delay: 300
>> none srst_pulls_trst
>> 50 kHz
>> Info : device: 4 "2232C"
>> Info : deviceID: 67330064
>> Info : SerialNumber: TLTKDK15A
>> Info : Description: Turtelizer JTAG/RS232 Adapter A Info : clock 
>> speed 50 kHz Info : JTAG tap: lpc1766.cpu tap/device found: 
>> 0x4ba00477 (mfg: 0x23b,
>> part: 0xba00, ver: 0x4)
>> Info : lpc1766.cpu: hardware has 6 breakpoints, 4 watchpoints Info : 
>> accepting 'gdb' connection from 3333 Warn : acknowledgment received, 
>> but no packet pending undefined debug reason 6 - target needs reset
>> Error: Target not halted
>> Error: failed erasing sectors 0 to 8 (-304)
>> Error: flash_erase returned -304
>> Info : JTAG tap: lpc1766.cpu tap/device found: 0x4ba00477 (mfg: 
>> 0x23b,
>> part: 0xba00, ver: 0x4)
>> Warn : Only resetting the Cortex-M3 core, use a reset-init event 
>> handler to reset any peripherals target state: halted target halted 
>> due to debug-request, current mode: Thread
>> xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc Info : dropped 'gdb' 
>> connection - error -400 Info : accepting 'gdb' connection from 3333 
>> Warn : acknowledgment received, but no packet pending Warn : 
>> Verification will fail since checksum in image (0x00000000) to be 
>> written to flash is different from calculated vector checksum 
>> (0xefff7f43).
>> Warn : To remove this warning modify build tools on developer PC to 
>> inject correct LPC vector checksum.
>> Info : JTAG tap: lpc1766.cpu tap/device found: 0x4ba00477 (mfg: 
>> 0x23b,
>> part: 0xba00, ver: 0x4)
>> Warn : Only resetting the Cortex-M3 core, use a reset-init event 
>> handler to reset any peripherals target state: halted target halted 
>> due to debug-request, current mode: Thread
>> xPSR: 0x01000000 pc: 0x000000cc msp: 0x10007ff0 Info : dropped 'gdb' 
>> connection - error -400
>> ---------------------------------------------------------------------
>> -
>> -----------------------------------------------
>>
>> If I try at 500Khz I usually get this (sometimes I get to main() )
>>
>> ---------------------------------------------------------------------
>> -
>> -----------------------------------------------
>>
>> $ ./openocd.exe
>> Open On-Chip Debugger 0.5.0-dev (2010-09-29-12:40) Licensed under GNU

>> GPL v2 For bug reports, read
>>         http://openocd.berlios.de/doc/doxygen/bugs.html
>> Info : only one transport option; autoselect 'jtag'
>> adapter_nsrst_delay: 300
>> jtag_ntrst_delay: 300
>> none srst_pulls_trst
>> 500 kHz
>> Info : device: 4 "2232C"
>> Info : deviceID: 67330064
>> Info : SerialNumber: TLTKDK15A
>> Info : Description: Turtelizer JTAG/RS232 Adapter A Info : clock 
>> speed 500 kHz Info : JTAG tap: lpc1766.cpu tap/device found: 
>> 0x4ba00477 (mfg: 0x23b,
>> part: 0xba00, ver: 0x4)
>> Info : lpc1766.cpu: hardware has 6 breakpoints, 4 watchpoints Info : 
>> accepting 'gdb' connection from 3333 Warn : acknowledgment received, 
>> but no packet pending undefined debug reason 6 - target needs reset
>> Error: Target not halted
>> Error: failed erasing sectors 0 to 8 (-304)
>> Error: flash_erase returned -304
>> Info : JTAG tap: lpc1766.cpu tap/device found: 0x4ba00477 (mfg: 
>> 0x23b,
>> part: 0xba00, ver: 0x4)
>> Warn : Only resetting the Cortex-M3 core, use a reset-init event 
>> handler to reset any peripherals target state: halted target halted 
>> due to debug-request, current mode: Thread
>> xPSR: 0x01000000 pc: 0x000000cc msp: 0x10007ff0 Info : dropped 'gdb' 
>> connection - error -400 Info : accepting 'gdb' connection from 3333 
>> Warn : acknowledgment received, but no packet pending Warn : 
>> Verification will fail since checksum in image (0x00000000) to be 
>> written to flash is different from calculated vector checksum 
>> (0xefff7f43).
>> Warn : To remove this warning modify build tools on developer PC to 
>> inject correct LPC vector checksum.
>> Info : JTAG tap: lpc1766.cpu tap/device found: 0x4ba00477 (mfg: 
>> 0x23b,
>> part: 0xba00, ver: 0x4)
>> Warn : Only resetting the Cortex-M3 core, use a reset-init event 
>> handler to reset any peripherals target state: halted target halted 
>> due to debug-request, current mode: Thread
>> xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc Warn : lpc1766.cpu --

>> clearing lockup after double fault
>> Error: address + size wrapped(0xfffffffe, 0x00000004)
>> Error: JTAG-DP STICKY ERROR
>> Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xfffffffc
>> Error: JTAG-DP STICKY ERROR
>> Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xfffffffc Warn : Block read

>> error address 0xfffffff8 Warn : lpc1766.cpu -- clearing lockup after 
>> double fault
>> Error: address + size wrapped(0xfffffffe, 0x00000004)
>> Error: JTAG-DP STICKY ERROR
>> Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xfffffffc
>> Error: JTAG-DP STICKY ERROR
>> Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xfffffffc Warn : Block read

>> error address 0xfffffff8 Warn : lpc1766.cpu -- clearing lockup after 
>> double fault
>> Error: address + size wrapped(0xfffffffe, 0x00000004)
>> Error: JTAG-DP STICKY ERROR
>> Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xfffffffc
>> Error: JTAG-DP STICKY ERROR
>> Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xfffffffc Warn : Block read

>> error address 0xfffffff8 Info : dropped 'gdb' connection - error -400
>>
>> ---------------------------------------------------------------------
>> -
>> -----------------------------------------------
>>
>> As you see the PC ends up at the top end of memory .. I also am not 
>> sure if the checsum error is relevant .. But it appears on both a 
>> good boot and a bad ..
>> My Config file is:
>>
>> ---------------------------------------------------------------------
>> -
>> -----------------------------------------------
>>
>> interface ft2232
>> ft2232_device_desc "Turtelizer JTAG/RS232 Adapter A"
>> ft2232_layout turtelizer2
>> ft2232_vid_pid 0x0403 0x6010
>>
>> # NXP LPC1766 Cortex-M3 with 256kB Flash and 32kB+32kB Local On-Chip 
>> SRAM,
>>
>> if { [info exists CHIPNAME] } {
>> set  _CHIPNAME $CHIPNAME
>> } else {
>> set  _CHIPNAME lpc1766
>> }
>>
>> # After reset the chip is clocked by the ~4MHz internal RC
oscillator.
>> # When board-specific code (reset-init handler or device firmware) # 
>> configures another oscillator and/or PLL0, set CCLK to match; if # 
>> you don't, then flash erase and write operations may misbehave.
>> # (The ROM code doing those updates cares about core clock speed...) 
>> # # CCLK is the core clock frequency in KHz if { [info exists CCLK ] 
>> } { set _CCLK $CCLK } else { set _CCLK 4000 } if { [info exists 
>> CPUTAPID ] } { set _CPUTAPID $CPUTAPID } else { set _CPUTAPID 
>> 0x4ba00477 }
>>
>> #delays on reset lines
>> adapter_nsrst_delay 300
>> jtag_ntrst_delay 300
>>
>> # LPC2000 & LPC1700 -> SRST causes TRST reset_config srst_pulls_trst
>>
>> # reset_config trst_and_srst separate # reset_config trst_and_srst 
>> srst_pulls_trst # reset_config srst_only combined srst_gates_jtag
>>
>> jtag newtap $_CHIPNAME cpu -irlen 4 -expected-id $_CPUTAPID # jtag 
>> newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf 
>> -expected-id $_CPUTAPID
>>
>> set _TARGETNAME $_CHIPNAME.cpu
>> target create $_TARGETNAME cortex_m3 -chain-position $_TARGETNAME
>>
>> # LPC1766 has 32kB of SRAM In the ARMv7-M "Code" area (at 0x10000000)

>> # and 32K more on AHB, in the ARMv7-M "SRAM" area, (at 0x2007c000).
>> $_TARGETNAME configure -work-area-phys 0x10000000 -work-area-size 
>> 0x8000 # $_TARGETNAME configure -work-area-phys 0x10000000 
>> -work-area-size 0x8000 -work-area-backup 0
>>
>> # LPC1766 has 256kB of flash memory, managed by ROM code (including a

>> # boot loader which verifies the flash exception table's checksum).
>> # flash bank <name> lpc2000 <base> <size> 0 0 <target#> <variant> 
>> <clock> [calc checksum] set _FLASHNAME $_CHIPNAME.flash flash bank 
>> $_FLASHNAME lpc2000 0x0 0x40000 0 0 $_TARGETNAME lpc1700 $_CCLK 
>> calc_checksum
>>
>> # Run with *real slow* clock by default since the # boot rom could 
>> have been playing with the PLL, so # we have no idea what clock the 
>> target is running at.
>> jtag_khz 50
>> # jtag_khz 500   # Actually should be 4Mhz/6 = 666khz, so use 500
>>
>> $_TARGETNAME configure -event reset-init { # Do not remap 
>> 0x0000-0x0020 to anything but the flash (i.e.
>> select
>> # "User Flash Mode" where interrupt vectors are _not_ remapped, # and

>> reside in flash instead).
>> #
>> # See Table 612. Memory Mapping Control register (MEMMAP - 0x400F 
>> C040) bit description # Bit Symbol Value Description Reset # value # 
>> 0 MAP Memory map control. 0 # 0 Boot mode. A portion of the Boot ROM 
>> is mapped to address 0.
>> # 1 User mode. The on-chip Flash memory is mapped to address 0.
>> # 31:1 - Reserved. The value read from a reserved bit is not defined.

>> NA # # 
>> http://ics.nxp.com/support/documents/microcontrollers/?scope=LPC1768&;
>> t
>> ype=user
>>
>> mww 0x400FC040 0x01
>> }
>>
>> ---------------------------------------------------------------------
>> -
>> -----------------------------------------------
>>
>>  .. And my gdb init sequence is:
>>
>> target remote localhost:3333
>> load
>> mon reset init
>> thb main
>>
>> ---------------------------------------------------------------------
>> -
>> -----------------------------------------------
>>
>> Can someone please advise on how to preseed with this ... it is so 
>> flakey it is hard to debug ..
>>
>> Many Thanks,
>> Bernie
>>
>>
>>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 11 Oct 2010 23:27:16 +0200
> From: Freddie Chopin <[email protected]>
> To: [email protected]
> Subject: Re: [Openocd-development] Problem getting reliable "reset 
> init" on LPC1766 target.
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 2010-10-11 22:04, Bernard Mentink wrote:
>>> target remote localhost:3333
>>> load
>>> mon reset init
>>> thb main
>
> You need to halt the chip before flashing anything on it. Try this:
>
> target remote localhost:3333
> mon reset init
> load
> thb main
>
> 4\/3!!
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 12 Oct 2010 12:23:46 +1300
> From: "Bernard Mentink" <[email protected]>
> To: "Freddie Chopin" <[email protected]>, 
> <[email protected]>
> Subject: Re: [Openocd-development] Problem getting reliable "reset 
> init" on LPC1766 target.
> Message-ID:
> <f7c0aa5dd1508f4789e10b6cc9bb75db03dbd...@nzc-ap-xch-02.ap.trimblecorp
> .net>
>
> Content-Type: text/plain; charset="us-ascii"
>
>
>
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of 
> Freddie Chopin
> Sent: Tuesday, 12 October 2010 10:27 a.m.
> To: [email protected]
> Subject: Re: [Openocd-development] Problem getting reliable "reset
init"
> on LPC1766 target.
>
> On 2010-10-11 22:04, Bernard Mentink wrote:
>>> target remote localhost:3333
>>> load
>>> mon reset init
>>> thb main
>
> You need to halt the chip before flashing anything on it. Try this:
>
> target remote localhost:3333
> mon reset init
> load
> thb main
>
> 4\/3!!
>
> ---------------------------------------
>
> Hi Freddie,
>
> I had tried that, it gets to the main breakpoint ok, but then when I 
> continue goes off into the weeds, please see the attached .doc file 
> for a snapshot of the error in eclipse ... Seems to try to execute 
> code at 0xfffffff0.
>
> Thanks,
> Bernie
>
> -------------- next part -------------- A non-text attachment was 
> scrubbed...
> Name: error.doc
> Type: application/msword
> Size: 134144 bytes
> Desc: error.doc
> URL: 
> <https://lists.berlios.de/pipermail/openocd-development/attachments/20
> 101012/29e69357/attachment.doc>
>
> ------------------------------
>
> _______________________________________________
> Openocd-development mailing list
> [email protected]
> https://lists.berlios.de/mailman/listinfo/openocd-development
>
>
> End of Openocd-development Digest, Vol 49, Issue 15
> ***************************************************
>
> __________ Informacia od NOD32 5443 (20100911) __________
>
> Tato sprava bola preverena antivirusovym systemom NOD32.
> http://www.eset.sk
>
> 

_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to