debugging the IXP432

Development Boards MicroMod
1

I have now successfully used the OpenOCD with an IXP432 processor.

There was a lot of mucking around to get the DDR controller working as some of the register definitions appear to be missing form the Intel data sheet. I finally found them in the Redboot source code.

I have now programmed the flash on my board by down loading a program and running it.

I have supplied the setup which may help other in the future.

I used the following config file

#daemon configuration
telnet_port 4444
gdb_port 3333

#interface
interface ft2232
ft2232_device_desc "Amontec JTAGkey A"
ft2232_layout jtagkey
ft2232_vid_pid 0x0403 0xcff8
jtag_speed 3

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

#format     L  IRC    IRCM   IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
tag_device 7  0x1    0x7f   0x09	# 2 IXP432

verify_ircapture disable

#target configuration
daemon_startup reset

#target <type> <endianess> <startup mode> <variant>
target  xscale little         reset_halt      0  IXP43x
run_and_halt_time 0 3

and the following script file to initialise the ddr and flash

There appears to be a lot of operations which I can only assume were to initialise the DDL in the DDR interface, but it does seem to work.

# initialise the memory comtroller
mww 0xcc00e504 0x72222312	// SDRC0 tRAS=40ns;tRP=15ns;tRCD=15ns;EDP=2;tWDL=2;CAS=4;DBW=16;DDR-II;32bits
mww 0xcc00e508 0x687144a7	// SDRC1 DQS=0;RTCMD=6;WRCMD=8;RTW=5;RFC=14;WR=3;RC=10;WTRD=7
mww 0xcc00e50c 0x00000000	// SDBR SDRAM Base register
mww 0xcc00e510 0x80000002	// SBR0 Bank0 boundary register
mww 0xcc00e514 0x80000002	// SBR1 Bank1 boundary register (not configured)
mww 0xcc00e51c 0x00000000	// ECCR  ECC control register (disabled)

mww 0xcc00e548 0		// Disable Refresh
mww 0xcc00e500 3		// NO-OP command
mww 0xcc00e500 2		// Prechage command
mww 0xcc00e500 7		// extended mode register 2 command
mww 0xcc00e500 8		// extended mode register 3 command
mww 0xcc00e500 4		// extended mode register 1 command
mww 0xcc00e500 1		// Mode command
mww 0xcc00e500 2		// Prechage command
mww 0xcc00e500 6		// Refresh command
mww 0xcc00e500 6		// Refresh command
mww 0xcc00e500 0		// Mode command
mww 0xcc00e500 15
mww 0xcc00e548 3120		// Refresh cycle count


mww 0xcc00f550 0x00000004
mww 0xcc00f554 0x00000000
mww 0xcc00f558 0x00000000
mww 0xcc00f55c 0x00000000
mww 0xcc00f560 0x00000000
mww 0xcc00f564 0x00000004
mww 0xcc00f568 0x00000000
mww 0xcc00f574 0x0000000a
mww 0xcc00f578 0x0002d400
mww 0xcc00f578 0x0002d400
mww 0xcc00f578 0x0002d400
mww 0xcc00f578 0x0002d400
mww 0xcc00f578 0x0002d400
mww 0xcc00f578 0x0002d400
mww 0xcc00f578 0x0002d000
mww 0xcc00f57c 0x0000889c
mww 0xcc00f57c 0x0000889c
mww 0xcc00f57c 0x0000889c
mww 0xcc00f57c 0x0000889c
mww 0xcc00f57c 0x0000809c
mww 0xcc00f500 0x81000006
mww 0xcc00f500 0x81000106
mww 0xcc00f500 0x81000206
mww 0xcc00f500 0x81000306
mww 0xcc00f500 0x81000406
mww 0xcc00f500 0x81000506
mww 0xcc00f500 0x81000606
mww 0xcc00f500 0x81002006
mww 0xcc00f500 0x81002106
mww 0xcc00f500 0x81002206
mww 0xcc00f500 0x81002306
mww 0xcc00f500 0x81002406
mww 0xcc00f500 0x81002506
mww 0xcc00f500 0x81002606
mww 0xcc00f500 0x81002706
mww 0xcc00f500 0x81004006
mww 0xcc00f500 0x81004106
mww 0xcc00f500 0x81004206
mww 0xcc00f500 0x81004306
mww 0xcc00f500 0x81004406
mww 0xcc00f500 0x81004506
mww 0xcc00f500 0x81004606
mww 0xcc00f500 0x81004706
mww 0xcc00f500 0x81006006
mww 0xcc00f500 0x81006106
mww 0xcc00f500 0x81006206
mww 0xcc00f500 0x81006306
mww 0xcc00f500 0x81006406
mww 0xcc00f500 0x81006506
mww 0xcc00f500 0x81006606
mww 0xcc00f500 0x81006706


# Configure memory map
mww 0xc4000020 0x0000126	// set normal mapping

Dave :slight_smile:

2

Hi tazzieboy,

you are the only one on the net I have found who uses a IXP43x Processor. I have designed a PCB with the IXP430 which is close to the IXP435 Gateway Reference Design with a some differences but with the same JTAG Interface. I have a lot of problems programming the IXP430. I’m using a Olimex Wiggler clone and I’m able to read the IDCODE. And when I type the command “poll” it states that the target is in halt state in supervisor mode with cspr:0x800000d3 and pc:0x0 , MMU, D-Cache and I-Cache disabled. I really have no clue what to do now. Can you please give some more infos what you did to programm the IXP43x?

Did you get the command “daemon_startup reset” work?

#daemon configuration

telnet_port 4444

gdb_port 3333

#interface

interface parport

parport_port parport0

parport_cable wiggler

jtag_speed 3

jtag_nsrst_delay 200

jtag_ntrst_delay 200

#use combined on interfaces or targets that can’t set TRST/SRST separately

#reset_config srst_only srst_pulls_trst

reset_config trst_and_srst separate

#jtag scan chain

#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)

jtag_device 7 0x1 0x7f 0x19261013 #0x7e

verify_ircapture disable #neu

#target configuration

#daemon_startup reset

#target

#target arm7tdmi

target xscale big 0 IXP43x

With this script I’m able to handle debugging with telnet but I’m stuck.

Please help!

3

Sciencesky,

You are correct there is very little on the WEB about IXP43x processors.

I am using the AMONTEC JTAG Key successfully (well almost). I have also

just changed to the latest version on the OpenOCD which has improved things.

Before you go any further you must make sure that the JTAG signals are clean.

I had a lot of trouble on my board which I put down to noise on the clock signal.

I discovered this one day when the JTAG was not working so I was probing

the signals with an oscilloscope and it started working. Take the probe off

and it stopped! I then placed a 22pf capacitor on the clock signal after

the 100R series resistor from the connector and this improved things a lot.

A later version of the board now has a Schmidt buffer in the clock path.

This has helped but there are still times when it refuses to operate.

I have also read of advice to run the clock as a single track with a series

terminator at the end 68R and 100pf in series to ground.

I have found that the latest software is much faster than the previous version.

They have also removed the need for some of the set-up commands

My current configuration is:

#daemon configuration
telnet_port 4444
gdb_port 3333

interface ft2232
ft2232_device_desc "Amontec JTAGkey A"
ft2232_layout jtagkey
ft2232_vid_pid 0x0403 0xcff8
jtag_speed 1

reset_config trst_and_srst separate
jtag_nsrst_delay 1
jtag_ntrst_delay 1

#format     L  IRC    IRCM   IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
jtag_device 7  0x1    0x7f   0x09	# 2 IXP432

#target <type> <endianess> <startup mode>
target  xscale little            0  xxxx

It is possible that I have removed too many things but as I can currently

download my flash initialisation programs I am not putting any more effort

into understanding how it works.

I still have a problem with running the Linux with the JTAG connected.

After reprogramming the flash I always disconnect the JTAG and power

off the board and then power on for a full startup. It makes some

debugging difficult but print statements are your friend.

When I started to set up my board I also found that I could

read the processor ID but I could not successfully run any other

operations. I tried some of the low level command by hand and gave up.

assuming at the time it was the interface at fault, and after a while it just worked.

Regards Dave

4

Hi Dave,

have you read the Errate from Intel about the IXP43x? It says “Updating the JTAG Parallel Registers Requires an Extra TCK Rising Edge”. It could possibly your problem. What I have done on friday was to use a DLP-Board which is based on the FTDI2232C. It works as USBJTAG with openocd but it doesn’t get me any further. It looks like i can write and read some registers but I don’t know which registers i have to write to nor do i know the initialization sequence for the IXP430. I’m just reading some redboot source-code but I havent found what i need. The funny thing is that i have called the Intel technical support and they told me that they dont give support for the Tray Version of the IXP43x. I didn’t know that there exists a boxed version of it. :shock:

Best regards,

Stephan

5

Stephen,

At present the system is working for me, enough so I’m not unhappy.

I am using the OpenOCD server with the telnet interface started with the command

telnet localhost 4444

This allows me to run simple low level commands

have you tried simple operations like

mdw 0xcc00e504

This will read and display one of the memory controller regsiters.

I assume that the processor and memory controller in your processor is the same

as the IXP432. The IXP432 does seem to be the same as the one in the IXP425 where I got most of my info from.

In my config file I have the line

target_script 0 reset /home/drm/openocd/doc/scripts/init.script

which points to the initialisation code shown in a earlier posting on this topic.

The example shown has the wrong comment characters ‘//’ should be ‘#’.

Also I did have some trouble with the comments on the end of the line

so commands and commands have now been separated.

This allows the command “reset init” to reset the processor and program

the memory controller so that a flash initialisation program can be down

loaded an run. It also remaps the memory so it appears at 0 and the flash

at 0x50000000.

I tried to use redboot to load images but had a lot of trouble with it, especially

when I wanted to load little endian images and it appeared that I could not

make it operate in little endian mode, so I have written my own system bootstrap code which is loaded from the flash.

Dave

6

Hi Dave,

thanks for your help. I was able to write and read some registers. For example I was able to let the GPIO’s work. I did some blinking lights and GPIO15 provided a very clean 33MHz Clock signal. I was even able to read and write the registers that were in your script. Except the last command all of them are for configuring the DDR2-RAM Controller. What I don’t understand is why are there so much registers that are not mentioned in the Developers Manual, I mean the registers 0xcc00f550 - 0xcc00f568. I know now that they are defined in Redboot but not in the DevMan.

When you have set the Normal Memory Mapping, were you able to write to the DDR-Memory using a MWW command with an adress starting at 0x0? Do I also have to enable the MMU? Its something that isn’t clear to me I mean I am able to read/write registers but I’m still clueless about filling the Flash.

I even run your script but i wasn’t able to write to 0x0.

interface ft2232
ft2232_layout usbjtag

jtag_speed 1
jtag_nsrst_delay 1
jtag_ntrst_delay 1
 
#use combined on interfaces or targets that can't set TRST/SRST separately
#reset_config srst_only srst_pulls_trst
reset_config trst_and_srst separate 
 
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
jtag_device 7 0x1 0x7f  0x09 

verify_ircapture disable 


target xscale big 0 IXP43x

This was the config file and after that i run a script from the shell via Telnet which is similar to yours but contains the reset init command first, without this command i wasn’t able to write/read registers.

BTW another useful resource is the website bsp.gateworks.com. They have a Board called the Cambria Platform it seems to be the cheapest Board that uses an IXP43x for 330$ :cry:

Best regards

Stephan

7

Stephen,

Almost there!.

I have the “reset init” command setup to run the initialisation script.

It is possible the the final memory map configuration need a different

register value/ register.This would be specific to the processor.

You should be able to check if the mapping has not been made

by looking at the flash CS signal and then doing a read from 0

The system should set the flash to 0x00000000 by default for boot strapping.

OpenOCD can write to flash, you tell it where and what type of flash

and you then run the flash commands. Hopefully you have standard Intel flash.

The gateworks board look interesting.

Dave

8

Hi Dave,

thanks for your help! I was able to write and to read from the Flash. But I have a really weird problem with SVN880 version of Openocd. As I am using Intel P30 Strata Flash the Query Command returns Q, R and Y but in the order R, Q , 0x0001 and Y. It looks like Openocd is reading words and changes both halfwords. Even the change of Endianess in the cfg-file gives the same results. To clearify it looks like this:

0x50000020 → 0x0052 R

0x50000022 → 0x0051 Q

0x50000024 → 0x0001

0x50000026 → 0x0059 Y

I got the same problem with the Manufacturer ID and the Device ID:

0x50000000 → 0x8818 Device ID

0x50000002 → 0x0089 Manufacturer ID

But when I’m manually writing a half-word to address 0x0 and one to 0x2, I don’t have this problem.

With SVN979 Version I have the problem that my Script doesn’t run correctly anymore. Openocd states Couldn’t open Xscale/debug_handler.bin

timed out while waiting for target halted

Failed to reset target into halted mode - issuing halt

timed out while waiting for target halted

Runtime error, file “command.c”, line 436:

If someone has a hint please state it here 8)

9

Stephan,

I had a very similar problem with the flash,

It appears that when you access it as individual halfwords it works

but when you access it in a burst things are swapped. Also when writing in

a burst all was correct but the second halfword was wrong.

I found that this was all down to the bus interface which attempts to

correct for the endianness. In little endian mode an access to loaction 0

came as a access to location 1 and vice-versa. Its all to do with making a

system boot correctly if configured as big endian or little endian, as long

as words are read out of the flash correctly then the software can change

the mode before any half word and byte accesses occur.

In my system I found that the if I compiled and ran the flash writing

program in big-endian mode it all worked correctly, but in little endian

mode it failed.

Eventually I re-wrote the software to swap the half word accesses during

the writes and this corrected every thing.

  U16 *p = FLASH;
  U16 *d = DATA;
  for(i=0;i<cnt; i++) {
    p[i^1] = d[i^1];
  }

My program which read the flash Id information does a swap of the

halfwords before any interpretation.

My interpretation of all this was that the top half of a word was

always in the even location of the flash and the bottom half was always

in the odd location of the flash. What I have never understood

why the xscale chips are more big-endian when ARMs, DEC which made

the strong arm, and Intel are all normally little-endian.

Overall, when you write data in a particular order you get it back in the

same order (a good thing in a computer), but when accessing the flash

directly expect little-endian mode to have things swapped.

The whole business took me a long time to wrap my head around, and

it still takes a lot of convincing each time I need to look at it.

I have never used the OpenOCD to access the flash so I cannot help

with the setup you are using

Dave

10

Hi Dave,

it’s getting more frustrating. On Friday I made some changes in Openocd and after I unplugged my board from the FTDI2232-Board and later put them together again Openocd finds my IXP430 but also 19 other devices. I don’t know what the heck happened but I’m not able to do a single read or write operation anymore.

Open On-Chip Debugger 1.0 (2008-09-15-18:20) svn:979

$URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $

jtag_speed: 6

verify Capture-IR is disabled

Debug: 16 1 target.c:3843 jim_target(): Target command params:

Debug: 17 1 target.c:3844 jim_target(): target xscale big 0 IXP43x

Debug: 18 1 target.c:3922 jim_target(): Target OLD SYNTAX - converted to new syntax

Debug: 19 1 target.c:3843 jim_target(): Target command params:

Debug: 20 1 target.c:3844 jim_target(): target create target0 xscale -endian big -chain-position 0 -variant IXP43x

Debug: 21 2 target.c:3843 jim_target(): Target command params:

Debug: 22 2 target.c:3844 jim_target(): target number 0

Debug: 24 2 command.c:82 script_command(): script_command - bank

Debug: 25 2 command.c:99 script_command(): script_command - bank, argv[0]=ocd_flash_bank

Debug: 26 2 command.c:99 script_command(): script_command - bank, argv[1]=cfi

Debug: 27 2 command.c:99 script_command(): script_command - bank, argv[2]=0x50000000

Debug: 28 2 command.c:99 script_command(): script_command - bank, argv[3]=0x1000000

Debug: 29 2 command.c:99 script_command(): script_command - bank, argv[4]=2

Debug: 30 2 command.c:99 script_command(): script_command - bank, argv[5]=2

Debug: 31 2 command.c:99 script_command(): script_command - bank, argv[6]=0

Debug: 33 2 command.c:82 script_command(): script_command - init

Debug: 34 2 command.c:99 script_command(): script_command - init, argv[0]=ocd_init

Debug: 35 3 openocd.c:107 handle_init_command(): target init complete

Debug: 36 3 ft2232.c:1506 ft2232_init_libftdi(): ‘ft2232’ interface using libftdi with ‘usbjtag’ layout (0403:6010)

Debug: 37 138 ft2232.c:1548 ft2232_init_libftdi(): current latency timer: 2

Debug: 38 141 ft2232.c:1711 usbjtag_init(): 80 18 1b

Debug: 39 144 ft2232.c:253 ft2232_speed(): 86 06 00

Debug: 40 156 openocd.c:114 handle_init_command(): jtag interface init complete

Debug: 41 156 jtag.c:1560 jtag_init_inner(): Init JTAG chain

Debug: 42 156 jtag.c:327 jtag_call_event_callbacks(): jtag event: JTAG controller reset (TLR or TRST)

Debug: 43 156 jtag.c:1301 jtag_reset_callback(): -

Debug: 44 159 jtag.c:327 jtag_call_event_callbacks(): jtag event: JTAG controller reset (TLR or TRST)

Debug: 45 159 jtag.c:1301 jtag_reset_callback(): -

Info: 46 170 jtag.c:1410 jtag_examine_chain(): JTAG device found: 0x19261013 (Manufacturer: 0x009, Part: 0x9261, Version: 0x1)

Info: 47 170 jtag.c:1410 jtag_examine_chain(): JTAG device found: 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf)

Info: 48 170 jtag.c:1410 jtag_examine_chain(): JTAG device found: 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf)

Info: 49 170 jtag.c:1410 jtag_examine_chain(): JTAG device found: 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf)

Info: 50 170 jtag.c:1410 jtag_examine_chain(): JTAG device found: 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf)

Info: 51 170 jtag.c:1410 jtag_examine_chain(): JTAG device found: 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf)

Info: 52 170 jtag.c:1410 jtag_examine_chain(): JTAG device found: 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf)

Info: 53 170 jtag.c:1410 jtag_examine_chain(): JTAG device found: 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf)

Info: 54 170 jtag.c:1410 jtag_examine_chain(): JTAG device found: 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf)

Info: 55 170 jtag.c:1410 jtag_examine_chain(): JTAG device found: 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf)

Info: 56 170 jtag.c:1410 jtag_examine_chain(): JTAG device found: 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf)

Info: 57 170 jtag.c:1410 jtag_examine_chain(): JTAG device found: 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf)

Info: 58 170 jtag.c:1410 jtag_examine_chain(): JTAG device found: 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf)

Info: 59 170 jtag.c:1410 jtag_examine_chain(): JTAG device found: 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf)

Info: 60 170 jtag.c:1410 jtag_examine_chain(): JTAG device found: 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf)

Info: 61 170 jtag.c:1410 jtag_examine_chain(): JTAG device found: 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf)

Info: 62 170 jtag.c:1410 jtag_examine_chain(): JTAG device found: 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf)

Info: 63 170 jtag.c:1410 jtag_examine_chain(): JTAG device found: 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf)

Info: 64 170 jtag.c:1410 jtag_examine_chain(): JTAG device found: 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf)

Info: 65 170 jtag.c:1410 jtag_examine_chain(): JTAG device found: 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf)

Error: 66 170 jtag.c:1426 jtag_examine_chain(): number of discovered devices in JTAG chain (20) doesn’t match configuration (1)

Error: 67 170 jtag.c:1427 jtag_examine_chain(): check the config file and ensure proper JTAG communication (connections, speed, …)

Error: 68 170 jtag.c:1579 jtag_init_inner(): trying to validate configured JTAG chain anyway…

Debug: 69 170 jtag.c:327 jtag_call_event_callbacks(): jtag event: JTAG controller reset (TLR or TRST)

Debug: 70 170 jtag.c:1301 jtag_reset_callback(): -

Debug: 71 174 openocd.c:120 handle_init_command(): jtag init complete

Debug: 72 174 openocd.c:123 handle_init_command(): jtag examine complete

Debug: 73 175 openocd.c:129 handle_init_command(): flash init complete

Debug: 74 175 openocd.c:133 handle_init_command(): NAND init complete

Debug: 75 175 openocd.c:137 handle_init_command(): pld init complete

Debug: 76 175 gdb_server.c:2116 gdb_init(): gdb service for target xscale at port 3333

Warning: 77 175 tcl_server.c:178 tcl_init(): no tcl port specified, using default port 6666

I’m out…

11

I forgot to mention that i have tried it again with the unchanged version but the behaviour was the same.

By the way:

the change in the code wasn’t that easy as you wrote before. In Xscale.c I changed the method xscale_read_memory for halfwords for the Addresspace 0x50000000 - 0x5fffffff. It’s a dirty hack but it was easier to find. It took a bit to get single- and multiple accesses working but Data-words were displayed correctly until the disaster.

Best regards

Stephan

12

I have also had similar experiences. It is caused by a corruption in the data coming back.

I believe it is caused by noise on the clock, and it appeared to be cured by adding a small capacitor

to the clock as it comes on to the board. I added 22pF. I my latest

board I have added a Schmidt buffer to the clock.

When I had this problem it would take 10 to 20 attempts to program the

board. After one episode I got so annoyed I started probing with the scope

and found that it worked with the scope probe on the clock pin, thus

the small capacitor.

Dave