sh architecture, "hello" sample doesn't work
sbattazzo at gmail.com
Sat Jul 3 09:45:53 UTC 2010
Alberico Colpo wrote:
> You probably already checked, but , is also the parity correct?
> Well, after the hello.exe test I rewrote the console driver:
> having only 2 SCI, I'm using SCI1 for both as console and debug port, so I
> have all the console io functions inside the BSP path.
> I'm not aware of the changes in console driver for rtems-4.10 (still working
> on 4.9).
> Anyway, I'm still having some problems (i think mostly configuration problems)
> in getting the termios driver to use the interrupt driven functions.
> I think your debugger hang because the startup code of rtems will reassign the
> vector table, you need to replace the stub traps (at least 32, 33 , 34 and
> NMI) before the change of VBR occurs.
Another update.. as you suggested before, checking the parity.. for some
reason, setting the parity to "odd" on my terminal caused the characters
to come through correctly.Strangely, I set a break just before the
printf, and checked the contents of the serial mode register, and got
back 0x04 which seems wrong.
This means the "multi-processor" bit is enabled, according to the SH
hardware manual. I don't really know what this is for, but the hardware
manual says that parity is NOT supposed to used at all when this bit is
set. Also, looking in sh7_sci.h there is a #define for a flag for it,
but it doesn't actually look to be implemented in sci.c when the SCI SMR
is supposed to be written. So something kind of strange may be going on
I tried replacing the extra traps as you suggested in start.S, but the
debug stub still hangs up.
The only other thing I could think of was overlap of the stack.
The debug stub puts its .bss section at 0xfffff000, though an objdump
estimates the size of this at only 90 some odd bytes. The gensh2 bsp
linkcmds puts the stack at 0xfffffec0, and I see somewhere these lines:
_CPU_Interrupt_stack_low = 0xFFFFF000;
_CPU_Interrupt_stack_high = 0xFFFFFFFF;
I'm actually not really sure what this is for, but I suppose it might
mean that rtems could be overwriting part of the debug stub's workspace?
Though if this is the case, I'm surprised that it doesn't hang up
somewhere in the initialization and memory allocation procedures rather
than in the final application.
The 7145 CPU I have here actually has double the on chip ram, starting
at 0xFFFFE000. So I decided to try adjusting the rtems linkerscript to
put these things all in the part of the RAM that is not being used by
gdbstubs. Unfortunately, this did not change the fact that gdbstub still
hangs up before the rtems program can exit. Maybe there is another
subtle difference between 7045 and 7145 that I haven't noticed yet.
More information about the users