From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21047 invoked by alias); 27 Oct 2003 10:32:47 -0000 Mailing-List: contact ecos-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@sources.redhat.com Received: (qmail 21038 invoked from network); 27 Oct 2003 10:32:47 -0000 Received: from unknown (HELO anchor-post-33.mail.demon.net) (194.217.242.91) by sources.redhat.com with SMTP; 27 Oct 2003 10:32:47 -0000 Received: from calivar.demon.co.uk ([212.228.213.211] helo=miso.calivar.com) by anchor-post-33.mail.demon.net with esmtp (Exim 3.35 #1) id 1AE4g2-000AbY-0X; Mon, 27 Oct 2003 10:32:46 +0000 Received: from miso.calivar.com (miso.calivar.com [127.0.0.2]) by miso.calivar.com (Postfix) with ESMTP id 18B6328DF46; Mon, 27 Oct 2003 09:46:51 +0000 (GMT) To: "Uwe Kindler" Cc: References: <000d01c39ba1$7077b880$53d7b43e@uwepc> From: Nick Garnett Date: Mon, 27 Oct 2003 10:32:00 -0000 In-Reply-To: <000d01c39ba1$7077b880$53d7b43e@uwepc> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [ECOS] EDOSK2674 GDB stub problem X-SW-Source: 2003-10/txt/msg00452.txt.bz2 "Uwe Kindler" writes: > Hello, > > I almost finished porting to a new architecture (Renesas H8S), variant > (H8S/2674) and platform (EDOSK2674). How does this differ from the EDOSK2674 support that is already present in the H8/300 HAL? > > When I build GDB stubs for the EDOSK board and use these stubs for > debugging, then everything works fine. > I can connect to target, upload, single step, set breakpoints and interrupt > running programs with ctrl c. It is no > problem to disconnect and reconnect to target. > > > If I now build Redboot with GDB stubs included then debugging works fine. > But when I disconnect from target then > it is not possible to reconnect and I cannot communicate with Redboot with > the CLI annymore. > > Does someone have any idea why the GDB stubs work fine outside of Redboot > and crash when deconnecting if used inside Redboot. > I do not have any idea and it is almost impossible to debug this. Support for reconnecting to GDB is mainly supported by resetting the system. Since there is no way of knowing what the application has done to the hardware, the safest way of dealing with this is to force a hardware reset. However, RedBoot does not do this by default, the command "maintenance packet r" to GDB will cause RedBoot to reboot when GDB disconnects. There is support for newlib based applications to call an exit syscall which should return to the RedBoot prompt. However, I don't know whether the H8/300 support in newlib provides this. -- Nick Garnett eCos Kernel Architect http://www.ecoscentric.com The eCos and RedBoot experts -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss