Problems with gdb with mcf5235BCC EVB

[matthew riek]

The machine it didnt work had XP installed, running VMWare with fedora 8.  I
tried all both EPP and SPP parallel port modes on this machine and both
produced the same unreliable results.  The motherboard for this machine is a
gigabyte intel 955x chipset.

The machine it did work on is a Advantech PCM-9581 EBX industrial
motherboard, SPP, fedora 8 installed directly on a fresh HDD (no vmware).

The EVB I am using is a "M5235BCC EVB by Axiom Engineering CMM-5235" from
July 2005.  I also had the same problems with the larger M5235 EVB (the
non-BCC and much larger variety ;) ).

In both cases, my BIOS didnt let me choose bi-directional or not.

I am soon to reformat the machine it currently doesnt work (I'll be dual
booting) so I'll let you know if it then works on that machine, which should
then point in the direction of VMWare (at least in my instance).

Regards,

Matt.
On Feb 9, 2008 1:03 AM, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:

> matthew riek wrote:
> > Hi all,
> >
> > My earlier post can be somewhat ignored now.  It seems I have a
> > problem either with VMWare or the machine it is installed on.  I did a
> > fresh install of *nix on another box, and the bdm seems stable now.  I
> > no longer get target bus errors, and things are behaving far more as
> > expected.  At least now, I can launch debug sessions as per the
> > gdb-init supplied with the 5235 BSP.
> > e
>
> Could you give details on the machine that it worked on and the machine
> it did not work on?  Chris Johns, Alan Cudmore and I are trying to track
> down the combination that work and don't work with the Axman mcf5235
> and the P&E BDM module.  Alan has it working and shipped me his
> hardware and bdm binaries.  They didn't work here.
>
> How was the parallel port configured? EPP, ECP, bidirectional, etc.
>
> What type of host computer?
>
> Any other relevant details.
>
> I am sure Chris and/or Alan will speak up.  There has to be something
> common to the configurations that work and those that don't.
>
> > Has anyone else had problems with gdb with dbg monitor on VMWare?  I
> > am still interested to hear about 5329 BSP's, and init scripts that
> > don't require booting and breaking dBug first.  I have pasted my init
> > script below (the attachement didnt work in the earlier post).  I'm
> > sure I will find it, but as of now, this script still has SP issues.
> > I can set the stack pointer to the top of SRAM but the SP keeps being
> > set to 0xfffffffe such that any jsr or rst will throw and exception.
> >
> > Cheers for any help or comments.
> >
> > my .gdb-init script... The goal is to not have to have freescale dBug
> > boot and break first before loading the elf....
> >
> >
> > target remote | m68k-bdm-gdbserver pipe /dev/bdmcf0
> >
> > monitor bdm-reset
> >
> > #
> > # Show the exception stack frame.
> > #
> > define show-exception-sframe
> >  set $frsr = *(unsigned short *)((unsigned long)$sp + 2)
> >  set $frpc = *(unsigned long *)((unsigned long)$sp + 4)
> >  set $frfvo = *(unsigned short *)((unsigned long)$sp + 0)
> >  set $frcode = $frfvo >> 12
> >  set $frvect = ($frfvo & 0xFFF) >> 2
> >  set $frstatus = ((($frfvo >> 10) & 3) << 2) | ($frfvo & 3)
> >  printf "EXCEPTION -- SR:0x%X  PC:0x%X  FRAME:0x%x  VECTOR:%d
> > STATUS:%d\n", $frsr, $frpc, $frcode, $frvect, $frstatus
> >  if $frstatus == 4
> >   printf " Fault Type: Error on instruction fetch"
> >  end
> >  if $frstatus == 8
> >   printf " Fault Type: Error on operand write"
> >  end
> >  if $frstatus == 12
> >   printf " Fault Type: Error on operand read"
> >  end
> >  if $frstatus == 9
> >   printf " Fault Type: Attempted write to write-protected space"
> >  end
> > end
> >
> > # Set RAMBAR = 0x20000001
> > monitor bdm-ctl-set 0xc05 0x20000001
> >
> > # Set PAR_SDRAM to allow SDRAM signals to be enabled
> > set *((char*) 0x40100046) = 0x3f
> >
> > # Set PAR_AD to allow 32-bit SDRAM if the external boot device is 16
> bits
> > set *((char*) 0x40100040) = 0xe1
> >
> > # Turn off WCR
> > set *((short*) 0x40140000) = 0x0000
> >
> > # 1MB ASRAM on CS1 at 0x30000000  (THE 5235 BCC doesn have this, the
> > EVB doesnt populate)
> > set *((short*) 0x4000008C) = 0x3000
> > set *((long*) 0x40000090) = 0x000f0001
> > set *((short*) 0x40000096) = 0x3d20
> >
> > # 2 meg flash on CS0 at 0xffe000
> > set *((short*) 0x40000080) = 0xffe0
> > set *((long*) 0x40000084) = 0x001f0001
> > set *((short*) 0x4000008a) = 0x1980
> >
> > # 16 meg sdram (page 18.6.4 of ref 5235 ref-manual)
> >
> > #powerup sequence
> > set *((short) 0x40000040) = 0x0446
> > set *((long) 0x40000048) = 0x00001300
> > set *((long) 0x4000004c) = 0x00fc0001
> >
> > #precharge
> > set *((long) 0x40000048) = 0x00001308
> > set *((long) 0x00000000) = 0xdeadbeef
> >
> > #refresh sequence
> > set *((long) 0x40000048) = 0x00009300
> >
> > #wait at least 8 auto refresh cycles to occur
> > # I don't know how to wait, so im just getting gdb to print something
> > for a pause
> > print $pc
> >
> > #enable IMRS
> > set *((long) 0x40000048) = 0x00009340
> >
> > #access sd ram to initialize the mode register
> > set *((long) 0x00000400) = 0x00000000
> >
> > #set stack pointer
> > set $sp = 0x2000fffc
> >
> > b _uhoh
> >
> >
> >
> >
>
>
> --
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel.sherrill at OARcorp.com        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>   Support Available             (256) 722-9985
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20080209/44cfcf97/attachment-0001.html>