TWR-K20D72M - help add a new target

Development Boards MicroMod
1

I got this eval board from freescale: TWR-K20D72M because I like the features of the K20 - especially the built-in 2-channel 16-bit ADC.

I’m using a bleeding edge version of openocd:

0.7.0-dev-00228-g2cb4862-dirty (2013-04-17-21:23)

I tried release 0.6.1 but I couldn’t get past opening osbdm device with that.

I’m on a mac (64-bit x86 Lion) and I use macports to install all the dependencies, mainly just libusb I think.

Here’s the configure command I used to build:

env CC=gcc CPPFLAGS="-I/opt/local/include" LDFLAGS="-L/opt/local/lib" ./configure --enable-osbdm --enable-maintainer-mode

I had to add entries in the osdbm.c for the vendor ID and product ID for the USB device on the eval board. Here are the lines with the entries added:

/* Lists of valid VID/PID pairs
 */
static const uint16_t osbdm_vid[] = { 0x15a2, 0x15a2, 0x15a2, 0 };
static const uint16_t osbdm_pid[] = { 0x0042, 0x0058, 0x005e, 0 };

Once I did that, it looks like it is mostly working, but it gives me an error when I try to load my program.

Here is the .cfg file I use (all combined into one for debugging):

#source [find interface/osbdm.cfg]
#
# P&E Micro OSBDM (aka OSJTAG) interface
#
# http://pemicro.com/osbdm/
#
interface osbdm
reset_config srst_only


#source [find board/twr-k20d72m.cfg]
#
# Freescale TWR-K20D72M development board
#

#source [find target/k20.cfg]
#
# Freescale Kinetis K20 devices
#

#
# K20 devices support both JTAG and SWD transports.
#
source [find target/swj-dp.tcl]

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

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

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

set _TARGETNAME $_CHIPNAME.cpu

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

target create $_TARGETNAME cortex_m3 -chain-position $_CHIPNAME.cpu

$_CHIPNAME.cpu configure -event examine-start { puts "START..." ; }
$_CHIPNAME.cpu configure -event examine-end { puts "END..." ; }

# if srst is not fitted use SYSRESETREQ to
# perform a soft reset
cortex_m3 reset_config sysresetreq


$_TARGETNAME configure -event reset-init {
	puts "-event reset-init occured"
}

proc my_attach_proc { } {
    echo "Reset..."
    reset halt
}
$_TARGETNAME configure -event gdb-attach my_attach_proc
$_TARGETNAME configure -event gdb-attach {
    echo "Reset..."
    # To make flash probe and gdb load to flash work we need a reset init.
    reset init
}

# 32K SRAM for work area
$_TARGETNAME configure -work-area-phys 0x1fff8000 -work-area-size 0x8000

#
# Bank definition for the 'program flash' (instructions and/or data)
#
# flash bank name    driver  base       size    chip_width bus_width target
flash bank pflash.0 kinetis 0x00000000 0x40000 0 4 $_TARGETNAME

scan_chain
gdb_memory_map disable

Problems I see:

  1. Sometimes before I enter any debug commands, openocd repeats the following:
Polling target k20.cpu succeeded again
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000042, MEM_AP_TAR 0xe000edf0
Polling target k20.cpu failed, GDB will be halted. Polling again in 100ms
Polling target k20.cpu succeeded again
  1. Sometimes I can program flash and sometimes not. Tried to reproduce some errors for this post and of course it worked! So, here’s what it looks like when it seems to work:
Open On-Chip Debugger
> program /Users/roger/Dev/kinetis/getting_started/Debug/getting_started
JTAG tap: k20.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: 0xfffffffe msp: 0xfffffffc
** Programming Started **
auto erase enabled
Probing flash info for bank 0
Padding image section 0 with 1988 bytes
wrote 4096 bytes from file /Users/roger/Dev/kinetis/getting_started/Debug/getting_started in 21.725399s (0.184 KiB/s)
** Programming Finished **
shutdown command invoked
> Connection closed by foreign host.
  1. Then when I try to load it to debug it, it has never worked. Here’s the output of openocd:
Open On-Chip Debugger 0.7.0-dev-00228-g2cb4862-dirty (2013-04-17-21:23)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
srst_only separate srst_gates_jtag srst_open_drain connect_deassert_srst
cortex_m3 reset_config sysresetreq
Info : add flash_bank kinetis pflash.0
   TapName             Enabled  IdCode     Expected   IrLen IrCap IrMask
-- ------------------- -------- ---------- ---------- ----- ----- ------
 0 k20.cpu                Y     0x00000000 0x4ba00477     4 0x01  0x0f
Info : OSBDM has opened
Info : This adapter doesn't support configurable speed
Info : JTAG tap: k20.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
START...
Info : k20.cpu: hardware has 6 breakpoints, 4 watchpoints
END...
Info : accepting 'gdb' connection from 3333
Reset...
Info : JTAG tap: k20.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
START...
END...
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
-event reset-init occured
Warn : acknowledgment received, but no packet pending
Error: address + size wrapped(0xfffffffe, 0x00000004)
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0x4
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0x4
Warn : Block write error address 0x0, wcount 0xf
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0x804
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0x804
Warn : Block write error address 0x800, wcount 0x192
Info : dropped 'gdb' connection

All that to say… does anyone know how to decode those register values MEM_AP_CSW and TAR to try to figure out what is wrong?

Please help me get this new target supported by openocd so I don’t have to admit defeat. :slight_smile:

Thanks,

Roger

2

Hello Roger,

I am not familiar with TWR-K20D72M and OpenOCD, but maybe I have a hint. Normaly there is a exception vector at the first bytes of the ARM memory map. Do you have a Datasheet from Freescale? I found only this one …

K20 Sub-Family Reference Manual
Supports: MK20DX128VLL7, MK20DX256VLL7, MK20DX64VMC7,
MK20DX128VMC7, MK20DX256VMC7
Document Number: K20P100M72SF1RM
Rev. 1.1, Dec 2012
Preliminary
General Business

Regards

MaTT

Update

e. g.

0x0000_0000–0x07FF_FFFF Program flash and read-only data (Includes exception vectors in first 1024 bytes)

3

The MEM_AP_CSW is a status register and MEM_AP_TAR is the adress register for the access to memory from the

jtag debug interface. So the value of TAR show what location in the processors memory map the debugger

tried to access.

JTAG-DP STICKY ERROR occor when the memory address in TAR is not a valid memory or register address for the target processor,

or trying to write to read only locations, and the MEM_AP access gives a bus fault.

It can also occur when the jtag interface speed is to high.

Regards

Magnus

4

Been a while but got back to it and decided to try again. This time I did not have to patch the code at all (just used a latest development build of openocd).

I finally got it to try to load a program and it looks like it worked but it looks to have silently failed:

Here’s some gdb output:

(gdb) load
Loading section .interrupts, size 0x1bc lma 0x0
Loading section .cfmprotect, size 0x10 lma 0x400
Loading section .text, size 0x2c4c lma 0x800
Loading section .ARM, size 0x8 lma 0x344c
Loading section .init_array, size 0x4 lma 0x3454
Loading section .fini_array, size 0x4 lma 0x3458
Loading section .data, size 0x958 lma 0x345c
Loading section .jcr, size 0x4 lma 0x3db4
Loading section .romp, size 0x24 lma 0x4ebc
Start address 0x8d0, load size 14248
Transfer rate: 4 KB/sec, 1583 bytes/write.
(gdb) x/20xw 0
0x0 <InterruptVector>:	0xffffffff	0xffffffff	0x000009e1	0x000009e1

It did not set the _estack and _start in the first two words of the vector table. And the other words are correct EXCEPT they have a 1 instead of 0 in the lowest order bit.

(gdb) x/xw &_estack
0x20000000:	0xab945571
(gdb) x/xw &_start
0x8d0 <start>:	0xe3b00016
(gdb) x/xw Default_Handler
0x9e0 <Default_Handler>:	0xaf00b480

I should see 0x20000000 and 0x8d0 in first two items of vector table.

And the default handler address should be 0x9e0 not 0x9e1.

Anyone seen this before?

Here is the code for the first 3 items of the vector table:

/* The Interrupt Vector Table */
void (* const InterruptVector[])() __attribute__ ((section(".vectortable"))) = {
    /* Processor exceptions */
    (void(*)(void)) &_estack,
    _start,	/*__thumb_startup,*/
    NMI_Handler,
5

I found the answer to the lowest order bit being set. Addresses to thumb2 instructions must have the lowest order bit set and the actual address is that address without the lowest bit set. Still investigating why the first two words of the vector table did not get programmed.

6

The place I would start looking is in a mapfile of the build and then the linker script to

see what symbols are defined for the stack and the start locations.

Then there is often a file named something like ivt.S, or something, where the actual vector table is defined.

7

Thanks mlu. The .elf seems to have the right stuff for address 0x0 and 0x4:

demo_gpio:     file format elf32-littlearm


Disassembly of section .interrupts:

00000000 <InterruptVector>:
   0:	20000000 	andcs	r0, r0, r0
   4:	00000939 	andeq	r0, r0, r9, lsr r9
   8:	00000ad5 	ldrdeq	r0, [r0], -r5
   c:	00000ad5 	ldrdeq	r0, [r0], -r5

(Got the above with objdump.) See the 20000000 and 00000939. But I get 0xfffffff for both addresses after a gdb load.

The vector table looks correct starting at address 0x8. Is there anything in the processor that protects these two words specifically? If not, I guess the next step is to actually look at the comm between openocd and jtag to see what’s wrong.

8

openocd appears to be trying to write the correct value, I modified a debug line to print out the first word of each block it is writing and I see the 20000000 I was looking for:

Debug: 482 16102 kinetis.c:416 kinetis_write(): write section @ 00000000 with length 1024 bytes: 20000000…