This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Re: eCos invalidating JTAG on ARM architecture ?


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 <cyg/hal/hal_platform_setup.h>

        // 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]