RE: [ECOS] Bootup and Redboot

RE: [ECOS] Bootup and Redboot

[James Yates]

I don't as yet have a working debugger stub, so I have had to rely on diag_printf and turning on/off certain LEDs. Using this technique, I know that the RTC isr is installed/attached but Cyg_RealTimeClock::isr is never called. I believe that the minute the scheduler is started and interrupts are unmasked, an RTC interrupt is generated, the default interrupt vsr is called and after some register and stack manipulation, a jsr to a memory location is attempted and this is where everything goes wrong. This is within cyg_hal_default_interrupt_vsr. Unfortunately due to no debugger, I can't find out what this address is. My knowledge of assembler is very poor so I am not completely sure what is happening.
Have you done any work with eCos on the SH2? No one seems to have and so I am a bit stuck on my own.

	Many thanks for your help and if you think of anything else, I would really appreciate it.

			James Yates

 

-----Original Message-----
From: Satish Kumar [mailto:satish@bvt.sc.sanyo.co.jp]
Sent: 29 October 2003 10:08
To: James Yates
Cc: Ecos Discuss (E-mail)
Subject: Re: [ECOS] Bootup and Redboot


For every RTC interrupt generated ; is the ISR routine called ..? put a
break point in the ISR routine and check what happens there after..
generally DSR routines are followed by ISR routines, so when ur DSR
routine is called, the ticks are initialised and u can get ur schedular
running, else the tick is always zero, and ur code hangs after that..

  if ur DSR routines are not called, check with ur hal_clock_xxxx
routines..in ur target_misc.c file..may be u have to recheck ur
intialisation procedure.

satish

On Wed, 29 Oct 2003 09:59:36 -0000
"James Yates" <j.yates@quartzuk.com> wrote:

> I am currently trying to get a custom board up and running with eCos and I am have hit a brick wall. It seems that as soon as the scheduler is started and interrupts are enabled, and the installed RTC causes and Interrupt, and exception is raised and the code dies. I believe the problem is with the Vector table/VSR table but can't figure out why.
> 
> I assume that the each entry in the Vector table, the entry point for each available ISR, should point to the default VSR handler which then looks up to see if an interrupt has been attached to this and if so then call the relevant ISR.
> I am not running Redboot since I am required to use a custom bootloader. Am I right in saying that Redboot sets up the Vector table correctlt and so my bootloader should do the same. On startup, before the scheduler is started, I print out the vector table pointed to by the VBR.
> The first 32 entries correctly point at the default_exception_vsr but the entries for peripheral Interrupts don't seem to point to anything valid. So I initialise as part of the platform init these entries to point to the default VSR handler. Is this correct? I am really stuck and don't know where to go from here.  This is running on an SH2 platform.
> 
> 
> 		I will be very gratefuly for any help.
> 
> 
> 				James Yates
> 
> -- 
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss

-- 
Satish Kumar <satish@bvt.sc.sanyo.co.jp>


--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

RE: [ECOS] Bootup and Redboot

[James Yates]

Many Thanks for your help Gary. I will carry on looking into this.

The reasons for using a special bootloader are as follows:

The product I am working on is a successor to an existing slower board and so has to work in exactly the same way. All of our existing products are connected together by a custom variant of rs232 comms. Basically it is 38.4kBps Rs232 half duplex so all equipment is connected in a chain by standard coax cable. Our control product contains all of the config for the system associated with it and on boot up it passes relevant configuration to control panels by the above comms method.
We have a program, which is compatible with all our products where we can connect a pc to a serial port  and perform firmware upgrades from the PC to any piece of equipment in the chain. The box the pc is connected to becomes a dumb pass through product.
All products store their firmware in on-board flash. A bootloader is run on powerup which looks to see if the firmware is trying to be upgraded, it then checksums the firmware and if all is ok, it then copies this code to RAM and runs from there. If not, it sits waiting for valid firmware to be sent to it. This uses, and due to specification has to use the default bootloader for all our equipment. It's a pain but is a limitation imposed on me by the spec.

I will look further into my startup initialisation. 


		Thanks for your help.

			James Yates



-----Original Message-----
From: Gary Thomas [mailto:gary@mlbassoc.com]
Sent: 29 October 2003 10:37
To: James Yates
Cc: Ecos Discuss
Subject: Re: [ECOS] Bootup and Redboot



James Yates said:
> I am currently trying to get a custom board up and running with eCos and I am have hit a brick
> wall. It seems that as soon as the scheduler is started and interrupts are enabled, and the
> installed RTC causes and Interrupt, and exception is raised and the code dies. I believe the
> problem is with the Vector table/VSR table but can't figure out why.
>
> I assume that the each entry in the Vector table, the entry point for each available ISR, should
> point to the default VSR handler which then looks up to see if an interrupt has been attached to
> this and if so then call the relevant ISR.
> I am not running Redboot since I am required to use a custom bootloader. Am I right in saying that
> Redboot sets up the Vector table correctlt and so my bootloader should do the same. On startup,
> before the scheduler is started, I print out the vector table pointed to by the VBR.
> The first 32 entries correctly point at the default_exception_vsr but the entries for peripheral
> Interrupts don't seem to point to anything valid. So I initialise as part of the platform init
> these entries to point to the default VSR handler. Is this correct? I am really stuck and don't
> know where to go from here.  This is running on an SH2 platform.
>

The way most architectures work is that the hardware interrupt/exception
mechanism (pointed to by a VBR or other hardware) chooses which code to
execute when an exception or interrupt happens.  This code is referred to
as the "vector service routine" or VSR.  You'll need some standard VSR
handler - normally these are slightly different for exceptions and interrupts.
In the case of the interrupt VSR, that code needs to save the interrupt
context (state) in a way that the kernel can make use of it.  Then the
interrupt VSR needs to determine what the actual interrupt is.  Sometimes
this is implicit (i.e. there could be a separate VSR for each interrupt)
or it the interrupt may need to be determined explicitly, e.g. reading
an interrupt-pending register.  In any case, you need to distill the
interrupt condition down to the selector - a one of N choice which is
mapped by the HAL_INTERRUPT_xxx defines.  This selector is then used
to look up the "interrupt service routine" (ISR) from a table.  This
table should be filled with "default_ISR" so that you can always handle
an interrupt, even if the program has not registered an ISR.  The interrupt
VSR then calls the appropriate ISR, via that table lookup.

I suspect that you've left out some of this in your initialization.
True, RedBoot normally takes care of this, but it's not necessary at
all.  The eCos application can (and should!) handle this if there is
no known "ROM monitor" supporting it (CYGSEM_HAL_USE_ROM_MONITOR is
not set/defined).

Just OOI, why can't you use RedBoot?  What's special about the bootloader
you have to use?

--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Bootup and Redboot

[Gary Thomas]

James Yates said:
> I am currently trying to get a custom board up and running with eCos and I am have hit a brick
> wall. It seems that as soon as the scheduler is started and interrupts are enabled, and the
> installed RTC causes and Interrupt, and exception is raised and the code dies. I believe the
> problem is with the Vector table/VSR table but can't figure out why.
>
> I assume that the each entry in the Vector table, the entry point for each available ISR, should
> point to the default VSR handler which then looks up to see if an interrupt has been attached to
> this and if so then call the relevant ISR.
> I am not running Redboot since I am required to use a custom bootloader. Am I right in saying that
> Redboot sets up the Vector table correctlt and so my bootloader should do the same. On startup,
> before the scheduler is started, I print out the vector table pointed to by the VBR.
> The first 32 entries correctly point at the default_exception_vsr but the entries for peripheral
> Interrupts don't seem to point to anything valid. So I initialise as part of the platform init
> these entries to point to the default VSR handler. Is this correct? I am really stuck and don't
> know where to go from here.  This is running on an SH2 platform.
>

The way most architectures work is that the hardware interrupt/exception
mechanism (pointed to by a VBR or other hardware) chooses which code to
execute when an exception or interrupt happens.  This code is referred to
as the "vector service routine" or VSR.  You'll need some standard VSR
handler - normally these are slightly different for exceptions and interrupts.
In the case of the interrupt VSR, that code needs to save the interrupt
context (state) in a way that the kernel can make use of it.  Then the
interrupt VSR needs to determine what the actual interrupt is.  Sometimes
this is implicit (i.e. there could be a separate VSR for each interrupt)
or it the interrupt may need to be determined explicitly, e.g. reading
an interrupt-pending register.  In any case, you need to distill the
interrupt condition down to the selector - a one of N choice which is
mapped by the HAL_INTERRUPT_xxx defines.  This selector is then used
to look up the "interrupt service routine" (ISR) from a table.  This
table should be filled with "default_ISR" so that you can always handle
an interrupt, even if the program has not registered an ISR.  The interrupt
VSR then calls the appropriate ISR, via that table lookup.

I suspect that you've left out some of this in your initialization.
True, RedBoot normally takes care of this, but it's not necessary at
all.  The eCos application can (and should!) handle this if there is
no known "ROM monitor" supporting it (CYGSEM_HAL_USE_ROM_MONITOR is
not set/defined).

Just OOI, why can't you use RedBoot?  What's special about the bootloader
you have to use?

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Bootup and Redboot

[Satish Kumar]

For every RTC interrupt generated ; is the ISR routine called ..? put a
break point in the ISR routine and check what happens there after..
generally DSR routines are followed by ISR routines, so when ur DSR
routine is called, the ticks are initialised and u can get ur schedular
running, else the tick is always zero, and ur code hangs after that..

  if ur DSR routines are not called, check with ur hal_clock_xxxx
routines..in ur target_misc.c file..may be u have to recheck ur
intialisation procedure.

satish

On Wed, 29 Oct 2003 09:59:36 -0000
"James Yates" <j.yates@quartzuk.com> wrote:

> I am currently trying to get a custom board up and running with eCos and I am have hit a brick wall. It seems that as soon as the scheduler is started and interrupts are enabled, and the installed RTC causes and Interrupt, and exception is raised and the code dies. I believe the problem is with the Vector table/VSR table but can't figure out why.
> 
> I assume that the each entry in the Vector table, the entry point for each available ISR, should point to the default VSR handler which then looks up to see if an interrupt has been attached to this and if so then call the relevant ISR.
> I am not running Redboot since I am required to use a custom bootloader. Am I right in saying that Redboot sets up the Vector table correctlt and so my bootloader should do the same. On startup, before the scheduler is started, I print out the vector table pointed to by the VBR.
> The first 32 entries correctly point at the default_exception_vsr but the entries for peripheral Interrupts don't seem to point to anything valid. So I initialise as part of the platform init these entries to point to the default VSR handler. Is this correct? I am really stuck and don't know where to go from here.  This is running on an SH2 platform.
> 
> 
> 		I will be very gratefuly for any help.
> 
> 
> 				James Yates
> 
> -- 
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss

-- 
Satish Kumar <satish@bvt.sc.sanyo.co.jp>


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

[ECOS] Bootup and Redboot

[James Yates]

I am currently trying to get a custom board up and running with eCos and I am have hit a brick wall. It seems that as soon as the scheduler is started and interrupts are enabled, and the installed RTC causes and Interrupt, and exception is raised and the code dies. I believe the problem is with the Vector table/VSR table but can't figure out why.

I assume that the each entry in the Vector table, the entry point for each available ISR, should point to the default VSR handler which then looks up to see if an interrupt has been attached to this and if so then call the relevant ISR.
I am not running Redboot since I am required to use a custom bootloader. Am I right in saying that Redboot sets up the Vector table correctlt and so my bootloader should do the same. On startup, before the scheduler is started, I print out the vector table pointed to by the VBR.
The first 32 entries correctly point at the default_exception_vsr but the entries for peripheral Interrupts don't seem to point to anything valid. So I initialise as part of the platform init these entries to point to the default VSR handler. Is this correct? I am really stuck and don't know where to go from here.  This is running on an SH2 platform.


		I will be very gratefuly for any help.


				James Yates

--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss