RES: Strange behavior when running RTEMS on an ERC32 chipset Tharsys board

Joel Sherrill <> joel.sherrill at
Fri Sep 9 14:16:30 UTC 2005

Fabrício de Novaes Kucinskis wrote:
> Jiri,
> Thank you very much for the explanation! I was sure that a trap was
> happening and overwriting the trap table, but I could not find what trap,
> nor the reason!
> I didn't realize that "mov %gX, %tbr" is a synthetic instruction, and it is,
> in fact, a "wrtbr", which is a privileged instruction! And because there is
> a "ta 0" in the address of the trap type "privileged instruction", the TBR
> continues to show me that the last trap ocurred is Ticc (the same as before
> the TBR is set), not a privileged instruction. Now everything is clear!

I thought Jiri's discussion deserved to be Wiki'ed.  It is now at and linked to by the
Erc32 BSP.  The other SPARC BSPs should link there was well.

Please feel free to add any comments or corrections, you think are needed.


> Thank you again!
> Best regards,
> Fabrício.
> -----Mensagem original-----
> De: Jiri Gaisler [mailto:jiri at]
> Enviada em: quinta-feira, 8 de setembro de 2005 20:44
> Para: joel.sherrill at
> Cc: Fabrício de Novaes Kucinskis; RTEMS - Mailing List
> Assunto: Re: Strange behavior when running RTEMS on an ERC32 chipset
> Tharsys board
> This is not a bug. The whole process is somewhat complex
> to explain though. So here we go ...
> 1. The sparc port of rtems generates binaries that do
>     not perform any board initialisation, and that are
>     linked to the begining of the RAM. The idea behind
>     this is to avoid having a separate bsp for every
>     possible board around. Instead, a boot-prom builder
>     (mkprom) is used to create a selft-extracting prom
>     image that initialises all board registers, loads the
>     application to ram, and the starts it. The parameters
>     to mkprom defines memory sizes, waitstates, frequency
>     stack pointer and so on. So far so good...
> 2. When running on a (recent) erc32 simulator, the rtems
>     image is loaded into the emulated ram and started from
>     there. The simulator detects that the start address is
>     not 0 (sparc reset vector) and perform the necessary
>     board init routines that would have been make by mkprom
>     on real hardware.
> 3. An issue with the 3-chip version of ERC32 is that the
>     timer scaling register can not be read, only written (!).
>     The rtems application can therefore not read the timer
>     scaler to figure out which frequency the board is running
>     at. To solve this, both the mkprom loader and the simulator
>     writes a copy of the scaler value to trap entry 0x7e in
>     the sparc trap table, because this trap can never occur
>     anyway. The rtems application picks up the value from
>     there and now knows the frequency and can generate proper
>     timer events etc.
> 4. Possible cause of the problem: Fabrício could be running rdbmon
>     debug monitor on his board, using it to download and start
>     applications. rdbmon is an application on its own, and needs
>     to insert its trap vectors into the rtems applications
>     trap table. This is done by starting the application in
>     user mode. The first priviledged instruction that occurs
>     is a write to %tbr (trap base register). This instruction
>     will trap and control is transfered to rdbmon. The monitor
>     can read out the value of the new %tbr, insert its trap
>     entries there, write the scaler value in 0x7e of the new
>     trap table, and re-start the application is supervisor mode.
>     What can not be done (and this is also mentioned in the
>     leccs/rdbmon manual) is to single step through this
>     procedure. What can also not be done is to use a custom
>     loader that does not write 0x7e, or custom start up code
>     that re-allocates the trap table.
> Note that these issues are commented in start.S and spurious.c
> of the sparc/erc32 bsp.
> start.S
> ===============
> /*
>     This is a sad patch to make sure that we know where the
>     MEC timer control register mirror is so we can stop the timers
>     from an external debugger. It is needed because the control
>     register is write-only. Trap 0x7C cannot occur in ERC32...
>     We also use this location to store the last location of the
>     usable RAM in order not to overwrite the remote debugger with
>     the RTEMS work-space area.
> */
> 	.global SYM(_ERC32_MEC_Timer_Control_Mirror), SYM(rdb_start),
> 	.global SYM(Configuration)
> SYM(rdb_start):
> SYM(_ERC32_MEC_Timer_Control_Mirror):
>    BAD_TRAP; BAD_TRAP;                           ! 7C - 7D undefined
>    .word	0x0a, 0, 0, 0				! 7E (10 MHz default)
> spurious.c
> ===============
>    for ( trap=0 ; trap<256 ; trap++ ) {
>      /*
>       *  Skip window overflow, underflow, and flush as well as software
>       *  trap 0 which we will use as a shutdown. Also avoid trap 0x70 - 0x7f
>       *  which cannot happen and where some of the space is used to pass
>       *  paramaters to the program.
>       */
>       if (( trap == 5 || trap == 6 ) ||
>       	(( trap >= 0x11 ) && ( trap <= 0x1f )) ||
>       	(( trap >= 0x70 ) && ( trap <= 0x83 )))
>        continue;
>      set_vector( (rtems_isr_entry) bsp_spurious_handler,
>           SPARC_SYNCHRONOUS_TRAP( trap ), 1 );
>    }
> Joel Sherrill <joel at> wrote:
>>What version of RTEMS is this with?  I was seeing an issue today with
>>the CVS head on SIS.  It turned out that the start.s code is copying
>>initialized data from ROM to RAM but I didn't see anywhere in the
>>linkcmds where the initialized data was actually placed there.
>>Commenting out "copy_data" loop fixed it.
>>Can anybody comment on what sections need to be added to the
>>linkcmds to make this work?
>>Fabrício de Novaes Kucinskis wrote:
>>>I'm working with a Tharsys board with a ERC32 chipset (TSC691E + TSC69È +
>>>TSC69É), and I noticed a very strange behavior when the RTEMS is being
>>>When trying to execute the example program "rtems-task" in the board, the
>>>RTEMS freezes for some seconds, and then the watchdog timer resets the
>>>After many hours of debugging, I discovered that the problem occurs
>>>when the
>>>RTEMS tries to read _ CLOCK_SPEED, stored in the address 0x020007e0.
>>>address is in the trap table area of the ERC32.
>>>At the moment where the RTEMS tries to read this value, what is
>>>written in
>>>this position of memory is not the clock value, but the instruction
>>>"ta 0".
>>>What I noticed was that, in the first instructions of the RTEMS, the Trap
>>>Base Register (TBR) is configured. At this moment, some addresses of the
>>>trap table have its routines modified, including the address of
>>>What I don't understand is that the overlapping of trap table occurs
>>>in the
>>>execution of the instruction that modifies the TBR, what for me
>>>doesn't make
>>>sense. I verified the system registers, and none trap occurred at this
>>>It is important to notice that this problem doesn't happen in the Sparc
>>>Instruction Simulator.
>>>I solved the problem with a small patch, rewriting the address _
>>>after the TBR configuration, but I would like to know what is
>>>triggering the
>>>overwriting of the trap table.
>>>Did somebody already find this problem using RTEMS with ERC32 (the
>>>real one,
>>>not the simulator)?
>>If you get a chance, I would like the output of at least a few of the
>>tmtests on real hardware at a known clock speed to compare to the
>>simulator.  That was what I was trying to look at today on the simulator
>>but became uncertain that the numbers reported were right.  I need a
>>sanity check against real hardware. :)
>>>Thanks in advance and best regards,
>>>Fabrício de Novaes Kucinskis - DEA / INPE
>>>Divisão de Eletrônica Aeroespacial
>>>Instituto Nacional de Pesquisas Espaciais

Joel Sherrill, Ph.D.             Director of Research & Development
joel at                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985

More information about the users mailing list