LOGIN   :::   RECOVER PASS   :::   GET ACCOUNT    
Browse
  • Projects
  • Code (CVS)
  • Forums
  • News
  • Articles
  • Polls
  •  
    OpenCores
  • FAQ
  • CVS HowTo
  • Mission
  • Media
  • Tools
  • Advertise
  • Mirrors
  • Logos
  • Contact us
  • Find Resources
  • Job Opportunity
  •  
    Tools
  • Search
      
  • Download Cores (CVSGet)
  •  
    More
  • Wishbone
  • Perlilog
  • EDA tools
  • OpenTech CD
  •  
    Navigation: All forums > Openrisc > Message List > Message Post

    Message

    Reply | Reply all
    Date Prev | Date Next | Thread Prev | Thread Next Date Index | Thread Index

    From: verno@a...<verno@a...>
    Date: Thu Aug 5 13:19:22 CEST 2004
    Subject: [openrisc] dbg-jp1
    Top
    Dear Matjaz,
    I think I solved the memory problem, the ISE can't give parameters to the memory
    module so I wrote it to the BLKMEMSP_V5_0 and it works properly.

    I can write data to memory addresses I think the or1200, debug unit, the cop
    matrix, and the onchip ram works properly. I use the hello.c file and put some
    REG32 function in the main function. The momory addresses where I put some
    data with the REG32 function are appear in the addresses, so the main function is
    run, but I can't see the hello word on my minicom window. I measured the fpga srx,
    stx legs with scope they are always logical one before the program run and after
    too. It seem the uart or the uart.h has a problem.
    When in the gdb I push the c button the gdb write continuing and it could quit with
    ctrl c, and after I restart the jp1 server it isn't write the same numbers the second
    column last two digits. I have to reload the Soc to the FPGA.
    Last time you write me send the error code, here it is the gdb error:
    [root@smart hello-uart]# or32-uclinux-gdb hello.or32
    GNU gdb 5.0
    Copyright 2000 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.
    There is absolutely no warranty for GDB. Type "show warranty" for details.
    This GDB was configured as "--host=i686-pc-linux-gnu --target=or32-uclinux"...
    (gdb) target jtag jtag://localhost:9999
    Remote or1k debugging using jtag://localhost:9999
    0xc in ?? ()
    (gdb) load
    Loading section .vectors, size 0x128 lma 0x0
    Loading section .text, size 0x368 lma 0x200
    Loading section .data, size 0x4 lma 0x568
    Loading section .rodata, size 0x10 lma 0x56c
    Start address 0x200 , load size 1188
    Transfer rate: 9504 bits in <1 sec, 237 bytes/write.
    (gdb) set $pc=0x100
    (gdb) c
    Continuing.
    status 1 1
    An error was reported by the proxy server. The command was:
    "JTAG_COMMAND_WRITE",0,0x0000000100000004
    The command returned 1.


    I hope yuo have some good idea about the problem.
    Thanks a lot!
    Erno Varga
    ----- Original Message -----
    From: Matjaz Breskvar<phoenix@o...>
    To:
    Date: Wed Aug 4 11:15:11 CEST 2004
    Subject: [openrisc] dbg-jp1

    > * verno@a... (verno@a...)
    > wrote:
    > > Dear Damjan,
    > >
    > > I rewrite the hello.c file because I can't manage a bigger
    > memory in the
    > > ise (and I don't know why). So i have 1 kb onchip memory, and
    > wrote a
    > > program which write something to a concrate memory address. In
    > the
    > > gdb I watch the memory address before and after the program
    > run, and
    > > the program write the memory address, so the processor and the
    > > memory are work. The problem is that when I push the c button
    > in the
    > > gdb, the gdb write continuing and I don't get back the gdb
    > prompt
    > > (gdb). It looks like it is in an endless loop. I try the
    > original and rewrite
    > > hello.c but the result was the same. Sometimes when I push
    > ctrl c the
    > > gdb is mend but sometimes it isn't and the jp1 proxy go wrong
    > too. Do
    > > you know what cause the problem exactly.
    > i do not have any concrete information. so maybe you can trace
    > it a bit and send some findings to the list, maybe sombody will
    > have
    > an idea.
    > regards,
    > p.
    >
    >

     
    Copyright (c) 1999 OPENCORES.ORG. All rights reserved.