[solved] Programming with JTAG Adapater

Development Boards MicroMod
1

Hi, I’m completely new to ARM and this is my first time working with JTAG interfaces. I’ve created a board with an LPC2138 and have been trying to get it programmed. I bought an Olimex [ARM-USB-TINY and installed the “WinARM + OpenOCD debugger + Eclipse” tool they provided. I feel like I’m very very close to making an LED blink, but after several hours I have’t made much headway. Here’s what my procedure looks like:

  1. Open Eclipse and the Olimex LPC2138 sample project

  2. Clean and Build

  3. Launch the External Tool “OpenOCD Tiny” and get back:

Open On-Chip Debugger 1.0 (2008-10-04-10:00) svn:exported
$URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $
Info:    options.c:50 configuration_output_handler(): jtag_speed: 20, 20
Info:    options.c:50 configuration_output_handler(): Open On-Chip Debugger 1.0 (2008-10-04-10:00) svn:exported
Info:    jtag.c:1389 jtag_examine_chain(): JTAG device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4)
Info:    jtag.c:1389 jtag_examine_chain(): JTAG device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4)
  1. Appears fine, I then run the debugger:
Warning: /cygdrive/C/gccfd/projects/lpc2138/.settings: No such file or directory.
Warning: /cygdrive/C/gccfd/projects/lpc2138: No such file or directory.
mi_cmd_break_watch: Missing <expression>
No registers.
target remote localhost:3333
0x7fffd2da in ?? ()
monitor sleep 500
monitor poll
target state: halted
target halted in Thumb state due to debug request, current mode: Supervisor
cpsr: 0x800000f3 pc: 0x7fffd2da
monitor flash probe 0
flash 'lpc2000' found at 0x00000000
monitor flash erase_sector 0 0 0
erased sectors 0 through 0 on flash bank 0 in 0.219012s
monitor flash write_image main.bin 0x0
wrote 604 byte from file main.bin in 0.365021s (1.615917 kb/s)
monitor reset run
JTAG device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4)
monitor sleep 500
monitor soft_reset_halt
requesting target halt and executing a soft reset
monitor arm7_9 force_hw_bkpts enable
force hardware breakpoints enabled
symbol-file main.out
thbreak main
Hardware assisted breakpoint 1 at 0xe8: file main.c, line 32.
continue

And this is where things stop for me…It looks like it was going well, I could see it clearing the flash, and successfully writing the main.bin into flash, but for some reason it keeps stopping at this non-existent breakpoint. At the bottom right in eclipse I see a little message saying “Launching LCP2138: (27%)” and it just says there. So to me it seems like I just need to get rid of this breakpoint or step through it, but I can’t figure out how to do either.

Then again, it says continue after that so perhaps that isn’t problem…in which case I’m even more puzzled. I’ve also tried messing with a few things in the .cfg file that seem to solve lots of other peoples problems, but both times I’ve done that it had no effect.

Any thoughts?](http://www.sparkfun.com/products/8278)

2

Okay I think I’ve realized to program flash, I only need to run the OpenOCDTiny script correct? I don’t care so much about debugging.

This is my config file, everything seems correct:

telnet_port 4444 
gdb_port 3333 

interface ft2232 
ft2232_device_desc "Olimex OpenOCD JTAG TINY A" 
ft2232_layout "olimex-jtag" 
ft2232_vid_pid 0x15BA 0x0004 

jtag_speed 3

reset_config trst_and_srst separate 

jtag_device 4 0x1 0xf 0xe 

jtag_nsrst_delay 333 
jtag_ntrst_delay 333 

daemon_startup reset 

target arm7tdmi little run_and_halt 0 arm7tdmi-s_r4 

run_and_halt_time 0 30 

target_script 0 reset oocd_flash2294.script 

working_area 0 0x40000000 0x4000 nobackup 

flash bank lpc2000 0x0 0x40000 0 0 0 lpc2000_v1 14746 calc_checksum

I get no warnings or errors when I run the script but also nothing about it flashing the memory. This is what it tells me after I compile and run OpenOCD Tiny:

Open On-Chip Debugger 1.0 (2008-10-04-10:00) svn:exported
$URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $
Info:    options.c:50 configuration_output_handler(): jtag_speed: 3, 3
Info:    options.c:50 configuration_output_handler(): Open On-Chip Debugger 1.0 (2008-10-04-10:00) svn:exported
Info:    jtag.c:1389 jtag_examine_chain(): JTAG device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4)
Info:    jtag.c:1389 jtag_examine_chain(): JTAG device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4)

Is my chip programmed?

3

Hello Logotech,

Is my chip programmed? In a word, No!

You have set up the JTAG debugger and defined some of the chip parameters. The JTAG link is working.

Your configuration file is incomplete.

You have not really given the MCU any instructions/work to do. Not certain what you want to do but I presume downloading a program into memory and running it.

I suggest you look at other threads here on using OpenOCD, on using a JTAG link, and on the particular chip/dev board you have.

You need to understand the memory map of your chip/board first.

Decide where to put your program (That you have compiled

in the IDE or copied from some reference source)

Download a suitable binary image and then past control to it.

I suggest you read the OpenOCD manual to understand what is required in the cfg files. You may also find the debugging logs useful when it gets a little more involved.

Ernest

4

Thank you Ernest! You answered several of my questions. After some more tinkering I think I’m very very close now. I changed my .cfg file and added a missing .script file. It now will erase the memory but the write commands don’t seem to do anything. Here’s what it looks like:

Console Output:

Open On-Chip Debugger 1.0 (2008-10-04-10:00) svn:exported

$URL: http://svn.berlios.de/svnroot/repos/ope … /openocd.c $

Info: options.c:50 configuration_output_handler(): jtag_speed: 10, 10

Info: options.c:50 configuration_output_handler(): Open On-Chip Debugger 1.0 (2008-10-04-10:00) svn:exported

Info: jtag.c:1389 jtag_examine_chain(): JTAG device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4)

Info: jtag.c:1389 jtag_examine_chain(): JTAG device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4)

Info: target.c:237 target_init_handler(): executing reset script ‘lpc2138_flash.script’

Info: options.c:50 configuration_output_handler(): dcc downloads are enabled

User: target.c:957 target_arch_state(): target state: halted

User: armv4_5.c:307 armv4_5_arch_state(): target halted in Thumb state due to debug request, current mode: Supervisor

cpsr: 0x800000f3 pc: 0x7fffd2d6

Info: options.c:50 configuration_output_handler(): flash ‘lpc2000’ found at 0x00000000

Info: options.c:50 configuration_output_handler(): erased sectors 0 through 0 on flash bank 0 in 0.188011s

[info about writing to flash should be here!]

Info: jtag.c:1389 jtag_examine_chain(): JTAG device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4)

Warning: arm7_9_common.c:743 arm7_9_poll(): DBGACK set, but the target did not end up in the halted stated 1

User: target.c:436 target_process_reset(): Timed out waiting for halt after reset

lpc2138_flash.script:

arm7_9 dcc_downloads enable
wait_halt
sleep 10
poll
flash probe 0

flash erase_sector 0 0 0
flash write_image 0 main.bin 0x00

reset run

sleep 10
shutdown

Config file:

#
# Flash LPC2138 memory using openocd 
# and a FTDI FT2232-based JTAG-interface
#
# created by Martin Thomas 
# based on information from Dominic Rath
#

#daemon configuration
telnet_port 4444
gdb_port 3333

#interface
interface ft2232 
ft2232_device_desc "Olimex OpenOCD JTAG TINY A" 
ft2232_layout "olimex-jtag" 
ft2232_vid_pid 0x15BA 0x0004
jtag_speed 10
jtag_nsrst_delay 100
jtag_ntrst_delay 100

#use combined on interfaces or targets that can't set TRST/SRST separately
reset_config trst_and_srst srst_pulls_trst

#jtag scan chain
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
jtag_device 4 0x1 0xf 0xe
#jtag_device 5 0x1 0x1 0x1e

#target configuration
daemon_startup reset

#target  
#target arm7tdmi    
target arm7tdmi little run_and_init 0 arm7tdmi-s_r4
run_and_halt_time 0 30

# flash-options LPC2138
target_script 0 reset lpc2138_flash.script
working_area 0 0x40000000 0x4000 nobackup
# LPC2138 @ 12MHz / 0x7D000 from 500*1024 (not 512!)
## up to version SVN188: 
#flash bank lpc2000 0x0 0x7D000 0 0 lpc2000_v2 0 12000 calc_checksum
## from Version SVN189: 
#flash bank lpc2000 0x0 0x7D000 0 0 0 lpc2000_v2 12000 calc_checksum
flash bank lpc2000 0x0 0x40000 0 0 0 lpc2000_v1 14765 calc_checksum
flash bank cfi 0x80000000 0x400000 2 2 0

I’ve also tried flash write_bank but again, console shows nothing and the LED doesn’t turn on so I’m still not quite there yet.

5

Okay I managed to get the console output I wanted after changing the flash write_image line to just: “flash write_image main.hex”

I then got this:

Open On-Chip Debugger 1.0 (2008-10-04-10:00) svn:exported
$URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $
Info:    options.c:50 configuration_output_handler(): jtag_speed: 10, 10
Info:    options.c:50 configuration_output_handler(): Open On-Chip Debugger 1.0 (2008-10-04-10:00) svn:exported
Info:    jtag.c:1389 jtag_examine_chain(): JTAG device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4)
Info:    jtag.c:1389 jtag_examine_chain(): JTAG device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4)
Info:    target.c:237 target_init_handler(): executing reset script 'lpc2138_flash.script'
Info:    options.c:50 configuration_output_handler(): dcc downloads are enabled
User:    target.c:957 target_arch_state(): target state: halted
User:    armv4_5.c:307 armv4_5_arch_state(): target halted in Thumb state due to debug request, current mode: Supervisor
cpsr: 0x800000f3 pc: 0x7fffd2d8
Info:    options.c:50 configuration_output_handler(): flash 'lpc2000' found at 0x00000000
Info:    options.c:50 configuration_output_handler(): erased sectors 0 through 26 on flash bank 0 in 0.206012s
Info:    options.c:50 configuration_output_handler(): wrote 692 byte from file main.hex in 0.228013s (2.963784 kb/s)
Info:    jtag.c:1389 jtag_examine_chain(): JTAG device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4)
Warning: arm7_9_common.c:743 arm7_9_poll(): DBGACK set, but the target did not end up in the halted stated 1
User:    target.c:436 target_process_reset(): Timed out waiting for halt after reset

But still no blinky LED :(. Could it have something to do with the last 2 lines?

EDIT: I got it working! I don’t know how, I’m still trying to figure out what I did…but at least I know it works!

6

Hello Logotech,

I suggest you need to be a little more cautious before trying to erase or write to memory. You may have damaged (“bricked”) your device.

The configuration files are better but I suspect you have critical problems.

First - OpenOCD - it is not stable. Between various releases there have been significant changes in how commands work! The number and order of the command variables changes!

So do you know what version of OpenOCD you are using?

Second - Wrong argument values mean BIG changes and problems to your MCU. You should not use trial and error to get things working. One mistake can make the chip inoperable.

I cannot stress RTFM (read the Fine Manual) enough. See link below.

http://openocd.berlios.de/doc/html/Flash-Commands.html

Here is part of it.

12.1 Flash Configuration Commands

— Config Command: flash bank name driver base size chip_width bus_width target [driver_options]

Configures a flash bank which provides persistent storage for addresses from base to base + size - 1. These banks will often be visible to GDB through the target’s memory map. In some cases, configuring a flash bank will activate extra commands; see the driver-specific documentation.

  • name … may be used to reference the flash bank in other flash commands. A number is also available.

  • driver … identifies the controller driver associated with the flash bank being declared. This is usually cfi for external flash, or else the name of a microcontroller with embedded flash memory. See Flash Driver List.

  • base … Base address of the flash chip.

  • size … Size of the chip, in bytes. For some drivers, this value is detected from the hardware.

  • chip_width … Width of the flash chip, in bytes; ignored for most microcontroller drivers.

  • bus_width … Width of the data bus used to access the chip, in bytes; ignored for most microcontroller drivers.

  • target … Names the target used to issue commands to the flash controller.

  • driver_options … drivers may support, or require, additional parameters. See the driver-specific documentation for more information.

Note: This command is not available after OpenOCD initialization has completed. Use it in board specific configuration files, not interactively.

— Command: flash banks

Prints a one-line summary of each device that was declared using flash bank, numbered from zero. Note that this is the plural form; the singular form is a very different command.

— Command: flash list

Retrieves a list of associative arrays for each device that was declared using flash bank, numbered from zero. This returned list can be manipulated easily from within scripts.

— Command: flash probe num

Identify the flash, or validate the parameters of the configured flash. Operation depends on the flash type. The num parameter is a value shown by flash banks. Most flash commands will implicitly autoprobe the bank; flash drivers can distinguish between probing and autoprobing, but most don’t bother.

Third - Your Chip/dev board memory map! Do you have a copy in front of you? Do you know where all the existing code is placed?

Most important - do you know the BASE addr of the flash memory bank (that is unused) you wish to program?

Addr 0x000000 is special on most CPUs. This is where interrupt vector tables, and other important system code/data resides.

Your config file looks like it was trying to write starting at this address. BAD NEWS

(BTW it can happen to all of us. I downloaded some bad code (bricked a board) - I now have a $200 piece of modern art)

Fourth - I suggest you comment out all lines that ERASE or write to the chip.

Get a memory read (mem dump) instruction working first.

Then dump bits of memory and check against the MCU memory map.

Make certain the page 0 (starts at 0x000000) has all the correct values still.

Fifth - Your config file for the JTAG - has the debug option set. It expects the processor to halt but this is not happening.

Not certain if you have incorrectly set up the debug TAP

Again RTFM first.

Get the debug link working properly. Just have the processor start and then stop ( INIT then HALT instructions)

Last - You have to read the debug lines. If you don’t understand then RTFM first. Use the Forum when you get stuck.

Ernest

7

Eeeks, that would have been a nightmare had I bricked it! I’ll be more careful next time.

My openOCD version is a strange one, it’s version “1.0” which apparently is a branch off the official version. I did check the memory maps and oddly enough, the memory map does start from 0x0000 0000, it ends at 0x0007 FFFF.

I suppose I got lucky by patching together config code from various other lpc2138 sources. But the good news is it’s not bricked and I managed to get the chip programmed and working! :smiley:

It did take a strange procedure for me to get it to work however, after a couple hours of tinkering with the procedure I ended up with something like this (still haven’t yet figured it out 100%):

  1. Device Off, Plug in JTAG, ARM-USB-TINY red LED Off

  2. Download program, wait until it times out

  3. Press Reset

  4. Power Off

  5. Remove JTAG

  6. Power On

Is it normal to always have to remove the JTAG interface to run the code?

I think some of these oddities might be related to what you had said about the debug option. Haven’t yet got a real smooth debug session to work yet either. But for now I’m just happy it works!

Thanks Ernest for all your wisdom!

8

Logotech,

You may have it working but it is not right.

It obviously hangs when you download. You should not have to go through the disconnecting, etc.

As I said before your debug link is not set up properly yet. Fix that first before screwing with memory.

I think you may not understand the mem map.

All (99.8%) mem maps start at 0x00000000. This is usually RAM memory for the system.

The memory is made up of chunks of RAM, ROM, reserved addresses as well as Flash memory.

(There is NOR and NAND types of Flash which work differently).

I would have expected the Flash memory to start at a fairly high address - say like 0x00200000.

If you are using 0x00000000 as your base address then you may be writing to RAM - not where you think. If so you risk disaster.

Have you got documentation for your board/chip which splls out where all the mem is?

You need this first.

Ernest

9

Hmm, it looks like you’re right, here’s the documentation I was looking at: http://www.nxp.com/documents/user_manual/UM10120.pdf.

I was only looking at Figure 2.1 but further down I saw what you were talking about with the interrupt memory. Figure 2.1 is kind of misleading labeling the bottom of that sector 0x0000 0000 when down in 2.2.1 they bring up the interrupt vectors that use 0x0000 0000 to 0x0000 001C.

Does this mean interrupts won’t work anymore? Or will they come back once I shift the memory block up?

10

Logotech,

Usually the processor boot up routine is in ROM (so you can not overwrite it). When the processor boots it is first from a ROM block. It usually copies some system code including vector table to page 0 (the first page of mem starts at 0x00000000). It then uses the RAM copy at page zero. Must be in RAM as some mem locations must be read/write for system to work. Page 0 is sort of traditional in that on early processors the access to memory on page 0 was faster than anywhere else and extra processor instructions were available for this set of memory locations.

As to what you have done to your chip? Who knows!. Chances are you are okay. Usually the only code/data in low RAM mem is a test/sample program (from supplier). If you have not destroyed the constants that set the clock speeds correctly the chip will still work.

From here you should comment out erase and write commands. Look up OpenOCD manual for memmory dump command. Add it to config file. Start dumping parts of memory (look at chip manual to find important sections) and check if there is code at the right places.

This takes a bit of time and some effort reading a lot. But it is worth it when you finally understand it.

Ernest

11

Okay I’ve got a dump of the memory and compared it to my program. It appears to me that from 0x0 to 0x40 that my program got overwritten, and from there on out they line up identically. Have a look at the picture attached.

So would my base address be 0x40 then? Makes sense to me, but the only reason I doubt all this is because in all the configuration files I’ve seen for the LCP2138, the base address and offset is set to 0x0. My configuration is based off the one provided by [Martian Thomas and written specifically for the LPC2138.

In both the configuration file:

openocd_lpc2138_flash_ftdi.cfg:
flash bank lpc2000 0x0 0x7D000 0 0 0 lpc2000_v2 12000 calc_checksum

and the script file:

openocd_lpc2138_flash.script:
flash write_bank 0 main.bin 0x00

He uses a base and offset of 0x0.](http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/openocd_intro/index.html)

12

Ernest, I’ve tried my best to find what line you say is putting it into Debug mode but haven’t been successful, you could please point out what line of code it is?

[EDIT] Found the cause of all my problems as far as downloading goes! I didn’t set P0.14 to high! I no longer have to do that weird procedure! This is sooo much better. :smiley:

13

hello logotech,

Sorry for the delay in replying - other projects/work in the way. I have a LPC2138 dev board but I have not had time to work with it. I had a quick look at the manual.

First you say figures 2.1 and 2.2.1 etc. I think you mean sections 2.1, 2.2.1? The figures 2,3,4,5 do show the memory as a graphic picture.

The LPC2138 has a slightly complicated memory system. It is not a simple linear sequence of addresses (actually it is but memory re-mapping shuffles the deck)

The re-mapping of memory by the MAM unit is what is causing some confusion. It moves the base 0x00000000 to various other memory addresses depending on which programming mode you use!. If you are trying to program in Flash memory then it moves the vector tables to TOP of the flash memory section!

I haven’t the time to read the manual, understand it and explain it to you. This is something you will have to do for yourself. You have to read all of chapters 2, 4 and4 and ?? Based on your memory dump it appears that you loading your program down at physical address 0x00000000 (the re-mapping to Flash bank is not happening) and the bootloader is overwriting the first 64 bytes (32 bytes of vector table and 32 bytes of ?). See Chapter 2.? for details.

I think this means the program download configuration file is incorrect in that it has not set the programming to “Flash bank” somehow. I am too tired and too busy at present to dig into it further for you.

You will need to study this a lot as this memory system is not straight forward. If your program is “small” and will fit I suggest you set the base to some higher value (so as to leave page 0 alone). Just look at memory map and make sure it fits into either part of the flash bank (non-volatile) memory range or even into the SRAM memory range.

Just read the memory pages carefully and remember small parts of each memory “block” at the very bottom and the very top addresses is where the bootloader puts system code (vector tables, peripherals, stackes, etc.)

ERnest

14

logotech:
Ernest, I’ve tried my best to find what line you say is putting it into Debug mode but haven’t been successful, you could please point out what line of code it is?

[EDIT] Found the cause of all my problems as far as downloading goes! I didn’t set P0.14 to high! I no longer have to do that weird procedure! This is sooo much better. :smiley:

You should have posted the schematic, someone would probably have noticed that immediately. :slight_smile: