[ECOS] RE: Power PC Application

[ECOS] RE: Power PC Application

[John Fisher]

Well I have figured the problem I was having out for myself - eventually,
and it's an
interesting trap for young players.

The four byte values that I and gdb itself were attempting to write to
the SYPCR register must be being written to the register byte by byte
instead of one 32 bit write. So after the first byte is redundantly written
(power up value and what I was trying to write were the same), the processor
was refusing to accept any further writes, SYPCR being a write once between
resets register.

It would appear that either the wiggler lacks a mechanism for forcing a 32
bit write or gdb is not using it,
however since I only need to write one byte that's precisely what I'll do.


John Fisher
Transmission Systems Division
NEC Australia Pty Ltd
649 Springvale Road
Mulgrave Vic 3170
Australia
email: jfisher@tns.neca.nec.com.au
ph: + 613 9264 3606
fax: + 613 9264 3892

[ECOS] RE: Power PC Application

[John Fisher]

I also have been trying to get gdb and insight working with BDM and the
Macraigor Wiggler, however I am experiencing the following problem with gdb
and/or wigglers.dll. I am using the Motorola MPC8xxFADS board.

After issuing "target ocd wiggler lpt1"
and "ocd reset" from gdb any attempt to write to the MPC860's SYPCR register
fails. When the register is read back 0xFFFFFF07 is obtained, which is the
boot up value. The reason I am trying to write the SYPCR register is to turn
the watchdog off.

My first thought was that gdb itself is writing this register and since the
register may only be written once following reset, that was the explanation.
However gdb writes the register during its target command - before the
reset - and since it writes 0xFFFFFF88 it is obviously not succeeding
either.

I have no trouble writing the SYPCR register when using OCD commander, the
debugger available from the Macraigor website.

I am taking a slightly different approach from the gdb authors. Writing
0xffffff0f stops the watchdog timer from counting while FRZ is asserted -
this is all that should be necessary. The gdb authors disable it entirely by
writing 0xffffff88.

It appears that gdb and the wiggler are either not resetting the board
properly or are writing the default value of the SYPCR register just after
reset.

Does anyone know whether source is available for wigglers.dll? I have asked
at macraigor but received no reply.

Here is the transcript of the gdb session:


GNU gdb 4.17-ecosSWtools-990319
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.  This version of GDB is supported
for customers of Cygnus Solutions.  Type "show warranty" for details.
This GDB was configured as "--host=i586-cygwin32 --target=powerpc-eabi".
(gdb) set radix 16
Input and output radices now set to decimal 16, hex 10, octal 20.
(gdb) target ocd wiggler lpt1
Remote target wiggler connected to wiggler lpt1
[Wiggler version f.20, capability 0x1d]
0x1000 in ?? ()
(gdb) x 0xff000004
0xff000004:     0xffffff07
(gdb) ocd reset
(gdb) print *(unsigned long *)0xff000004 = 0xffffff0f
$1 = 0xffffff07
(gdb) x 0xff000004
0xff000004:     0xffffff07
(gdb) x 0xff000004
0xff000004:     0xffffff07
(gdb) quit
The program is running.  Exit anyway? (y or n) y
bash-2.02$



Here is wigglers.log:



rewrite LOG
55 F1 01 0E
55 F1 80 00 8F
set_connection
55 F0 01 0F
55 F0 80 06 8A
initialize_target
55 10 00 50 02 9E
55 10 00 00 F0
set_logging
close LOG
55 F1 03 0C
append LOG
55 F1 02 0D
55 F1 00 00 0F
get_version
55 01 FF
55 01 00 00 00 20 00 1D 00 00 00 00 00 00 C2
set_logging
close LOG
55 F1 03 0C
append LOG
55 F1 02 0D
55 F1 00 00 0F
stop_target
55 22 DE
55 22 04 00 DA
set_logging
close LOG
55 F1 03 0C
append LOG
55 F1 02 0D
55 F1 04 00 0B
set_control_flags
55 15 00 01
55 15 04 00 E7
read_register
55 30 00 1A 00 1A 9C
55 30 04 00 04 00 00 10 00 B8
read_register
55 30 08 01 08 01 BE
55 30 04 00 04 00 00 88 7B C5
set_logging
close LOG
55 F1 03 0C
append LOG
55 F1 02 0D
55 F1 04 00 0B
write_register
55 31 00 95 04 20 02 40 00 D4
55 31 04 00 CB
write_memory
55 33 FF 00 00 04 01 00 04 FF FF FF 88 40
55 33 04 00 C9
read_memory
55 32 FF 00 00 04 01 04 C6
55 32 04 00 04 FF FF FF 07 C2
reset_and_halt
FAST DOWNLOAD ENABLED
55 24 DC
55 24 04 00 D8
set_logging
close LOG
55 F1 03 0C
append LOG
55 F1 02 0D
55 F1 04 00 0B
write_memory
55 33 FF 00 00 04 01 00 04 FF FF FF 0F B9
55 33 04 00 C9
read_memory
55 32 FF 00 00 04 01 04 C6
55 32 04 00 04 FF FF FF 07 C2
read_memory
55 32 FF 00 00 04 01 04 C6
55 32 00 00 04 FF FF F



John Fisher
Transmission Systems Division
NEC Australia Pty Ltd
649 Springvale Road
Mulgrave Vic 3170
Australia
email: jfisher@tns.neca.nec.com.au
ph: + 613 9264 3606
fax: + 613 9264 3892

Re: [ECOS] RE: Power PC Application

[Brendan Simon]

John Fisher wrote:

> I also have been trying to get gdb and insight working with BDM and the
> Macraigor Wiggler, however I am experiencing the following problem with gdb
> and/or wigglers.dll. I am using the Motorola MPC8xxFADS board.
>
> After issuing "target ocd wiggler lpt1"
> and "ocd reset" from gdb any attempt to write to the MPC860's SYPCR register
> fails. When the register is read back 0xFFFFFF07 is obtained, which is the
> boot up value. The reason I am trying to write the SYPCR register is to turn
> the watchdog off.
>
> My first thought was that gdb itself is writing this register and since the
> register may only be written once following reset, that was the explanation.
> However gdb writes the register during its target command - before the
> reset - and since it writes 0xFFFFFF88 it is obviously not succeeding
> either.
>
> I have no trouble writing the SYPCR register when using OCD commander, the
> debugger available from the Macraigor website.
>
> I am taking a slightly different approach from the gdb authors. Writing
> 0xffffff0f stops the watchdog timer from counting while FRZ is asserted -
> this is all that should be necessary. The gdb authors disable it entirely by
> writing 0xffffff88.
>
> It appears that gdb and the wiggler are either not resetting the board
> properly or are writing the default value of the SYPCR register just after
> reset.
>
> Does anyone know whether source is available for wigglers.dll? I have asked
> at macraigor but received no reply.

Good luck.  I have hassled them a few times about Linux drivers and have never
heard anything from them.  I offered to develop a free Linux driver for them so
that Linux users could buy Wigglers thus increasing their market potential.  I
didn't here a thing from them.