From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16734 invoked by alias); 6 Jul 2007 17:24:50 -0000 Received: (qmail 16725 invoked by uid 22791); 6 Jul 2007 17:24:49 -0000 X-Spam-Check-By: sourceware.org Received: from stelecom.gomel.by (HELO stelecom.gomel.by) (82.209.213.61) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 06 Jul 2007 17:24:43 +0000 Received: from localhost (localhost [127.0.0.1]) by stelecom.gomel.by (Postfix) with ESMTP id DBC02B01DE82; Fri, 6 Jul 2007 20:24:40 +0300 (EEST) Received: from stelecom.gomel.by ([127.0.0.1]) by localhost (stelecom.gomel.by [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20670-05-5; Fri, 6 Jul 2007 20:24:38 +0300 (EEST) Received: from localhost (unknown [86.57.140.13]) by stelecom.gomel.by (Postfix) with ESMTP id 4A386B01D731; Fri, 6 Jul 2007 20:24:35 +0300 (EEST) Date: Fri, 06 Jul 2007 17:24:00 -0000 From: Sergei Gavrikov To: Alexandre Cc: ecos-discuss@ecos.sourceware.org Message-ID: <20070706172338.GA8127@ubuntu> References: <20070705205321.GA10274@ubuntu> <1183718456.13495.20.camel@sg-ubuntu> <20070706164818.GB6854@ubuntu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070706164818.GB6854@ubuntu> User-Agent: Mutt/1.5.13 (2006-08-11) X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Re: eCos invalidating JTAG on ARM architecture ? X-SW-Source: 2007-07/txt/msg00065.txt.bz2 If the trap will be work for you, here is a small notice about the eCos path. Enter in your HAL platform startup (hal_platform_startup.h) a conditional inclusion, something like this #ifdef CYGHWR_HAL_ARM_LPC2XXX_USE_SECONDARY_JTAG // put that trap code here ... #endif and add in your platform cdl file a CDL rule, well, something like this cdl_option CYGHWR_HAL_ARM_LPC2XXX_USE_SECONDARY_JTAG { display "Second JTAG workaround" flavor bool default_value 0 description "Short story about" } That gives you a choice or to build executables for debugging either to build executables for a release, configuring an ecos.ecc stuff. Sergei On Fri, Jul 06, 2007 at 07:48:44PM +0300, Sergei Gavrikov wrote: > On Fri, Jul 06, 2007 at 01:46:40PM +0200, Alexandre wrote: > > >Well, and what about your own eCos startup file (hal_platform_setup.h)? > > >Did you manage the LPC PINSEL registers correctly? I see that Jani > > >Monoses, for example, didn't overload his own startup files by any extra > > >lines ;) Observe arm/lpc2xxx/*/current/hal/include/hal_platform_setup.h > > >files, for example. It's possible you have to force Debug/Trace pinouts > > >assignment in your own eCos platform startup file. > > > > I thought about that yesterday (maybe i've got the shinning !), but > > thanks for asking, seems like i'm finally heading the right way :) > > Well that's what I wrote: > > > > .macro _gpio_init > > // enable RX and TX on UART0 and the button > > ldr r0,=CYGARC_HAL_LPC2XXX_REG_PIN_BASE > > ldr r1,=0x80000005 > > str r1,[r0,#CYGARC_HAL_LPC2XXX_REG_PINSEL0] > > // added PINSEL1 config to enable JTAG1 & EINT0 > > ldr r1,=0x55400001 > > str r1,[r0,#CYGARC_HAL_LPC2XXX_REG_PINSEL1] > > .endm > > > > The last part is my code, yet it's still not working. Is there any > > other place where any init could occur ? > > > > For reference this register assignment (0x55400001) works in a non > > eCos environment, that is JTAG & External Interrupt 0 both work fine. > > Well, I haven't LPC2106 board to dig deeper, but I remember that two > years ago I downloaded a trial version of CW 1.X for ARM from Rowley > Associates Ltd. I'm still keeping that stuff on my Slackware box, > because they used GNU tool chain. My friend told me in those days that > CW works very smoothly with parallel JTAG wiggler. He has got one > LPC2106 board and played with it using CW. Greping through out their > samples directory, I found a startup.s file for IAR LPC210X Kickstart > board (secondary_jdag dir.). It contains such a trap > > #define PINSEL1 0xE002C004 > > reset_handler: > /* Set P0.27-P0.31 alternative function 1 (secondary JTAG pins). */ > ldr r0, =PINSEL1 > ldr r1, =0x55400000 > str r1, [r0] > > /* Loop forever */ > 1: > b 1b > > Look at the eCos vectors.S for ARM arch., please. It contains > > reset_vector: > PLATFORM_SETUP1 // Early stage platform initialization > // which can set DRAM size at 0x40 > // see > > // Come here to reset board > warm_reset: > > As you can see PLATFORM_SETUP1 is just an inclusion your platform setup > code (that is your own hal_platform_setup.h file). So, try to apply that > CW's trap for the second jtag. And then jump at warm_reset point. Well, > that is a trick, but it's possible, it will be work for you. > > I'm sorry, but I don't use any JTAG for my target. Like Paul I use GDB > stubs (RedBoot) for debugging. My LPC CPUs has EMC (external memory > controller) and I can load and debug code in RAM. I understand what that > isn't your path. So, I would suggest you to get stable results with your > JTAG using minimalist eCos template at first (to save a time). > > regards, > > Sergei > > > > >That already has contained that February fix. > > > > Cool, i had nightmare thinking about patching my sources -.- > > -- > Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos > and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss