SH4 Interrupt Handling

[Fernando RUIZ CASAS]

Hi all,

Of course that the interrupts process are different in the new versions of SH.

My idea is only stop the monitor/loader activity and rewrite the .s startup() function
like the ROM needs. 
Starting like a ROM image and not like a RAM/Monitor image.

If you locks the interrupts you can place the new vector with control and you only needs
fill the vector table with the appropiate values and set up VBR vector.


After debug and rebuild a RAM image that it starts very well 
the problem arrives again in the ROM image.

Always a ROM images gives new problems. The BSC controller is ok in 
the RAM/monitor but when the ROM image starts that is the first setup to do. 
The ram area is forbbiden until this. In the SH1 of course.

This is only a best practice to start quickly the new BSP without all the problems that the RAM
images have when the ROM images are built.

I have spent a lot of time to build a ROM image without any system to control the CPU while the 
ROM image starts.

If you start a ROM image then the same RAM image relocated always runs. 
It isn't the reverse case.

BRGDS

Fernando RUIZ CASAS



Ralf Corsepius wrote:

> 
> Am Don, 2002-12-05 um 09.30 schrieb Fernando RUIZ CASAS:
> > Perhaphs you need stop all the interrrupts and 
> > rewrite all the registers like a reset in order to set up the machine
> > before starts again the new program.
> It depends on you board and where the vector table is stored.
> 
> The SH1-port uses 3 vector tables,
> One fixed vector table in ROM, a second one containing the application
> vector table, and a 3rd one being actually used.
> 
> The gensh1 BSP uses the ROM-vector table to boot, then it copies the ROM
> vector table into the 3rd vector table and subsequently merges in the
> 2nd vector table into the 3rd.
> 
> Finally it switches to using the 3rd vector table.
> 
> The basic idea behind this procedure is having a monitor/debugger stub
> in ROM, the application providing its own vector table, but wanting to
> use some interrupts provided by the ROM'ed code.
> 
> [Background: On our boards, the 2nd vector table + the application had
> been in battery buffered, non-volatile RAM, while the "play-area" (3rd
> vector table was in volatile RAM]
> 
> > The problem is the same in SH1 and SH2.
> No. The SH1 and SH2 interrupt handling is different from the SH4.
> 
> Ralf
> 
> > 
> > "Kiran C" wrote:
> > 
> > > 
> > > Hi,
> > > 
> > > I have a small probleming trying to set up
> > > 
> > > the interrupt handling......I am working on an SH4 processor(SH7751)
> > > 
> > > I am trying to write a  monitor program...
> > > 
> > > In the entry point of my program...which is loaded at 0x8c020000 (RAM)
> > > 
> > > I set the VBR to ( a Interrupt Handler function address - 0x0000600) (..The
> > > Interrupt handling is the same as in SH3...)
> > > 
> > > As such now when an interrupt occurs my Handler function should be called...
> > > 
> > > I realize that I need to set up the INTC et al...but am quite ignorant about
> > > that...
> > > 
> > > Can u help me detaling the step by step intialization procedure....
> > > 
> > > I am using REDBOOT to run my proram...soon after I change the VBR....a reset
> > > occurs and control goes back to the REDBOOT Monitor program....
> > > 
> > > What am I missing out???
> > > 
> > > Thanks,
> > > 
> > > Kiran
> > 
> > mailto://correo@fernando-ruiz.com
> -- 
> Ralf Corsepius
> Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung (FAW)
> Helmholtzstr. 16, 89081 Ulm, Germany     Tel: +49/731/501-8690
> mailto:corsepiu at faw.uni-ulm.de           FAX: +49/731/501-999  
> <a
href="http://mail.fernando-ruiz.com/jump/http://www.faw.uni-ulm.de">http://www.faw.uni-ulm.de</a>

mailto://correo@fernando-ruiz.com