Can't enable a dummy clock driver

Joel Sherrill joel at rtems.org
Sun Jul 23 22:27:07 UTC 2017


On Jul 23, 2017 5:15 PM, "Denis Obrezkov" <denisobrezkov at gmail.com> wrote:

2017-07-23 22:30 GMT+02:00 Joel Sherrill <joel at rtems.org>:

> Increasing the stack size effectively eliminated a data corruption issue.
> The memory corrupted likely was an RTEMS internal object structure.
>
> What is the stack frame size required by each subroutine call?
>
How can I determine it?


If it isn't directly in the CPU's ABI definition, then what is pushed to
the stack or reserved on each subroutine call. You may see it in terms of
stack pointer, frame pointer, reserved space, etc.

For example, the m68k had a minimum of 4 registers saved and the return
address. More registers could be saved for complicated methods.

I think some risc CPU has a number like 172 bytes reserved for possible
register saves.

So the scheme varies


> How much stack to call printf()?
>
> The minimum is an educated guess by the porter that is large enough to run
> many/most small applications. You should be able to call RTEMS services and
> do a context switch.
>
> Hope that helps pick one. :)
>

As for now, I have increased the minimum stack size and get the following
output:

*** LOW MEMORY CLOCK TICK TEST ***

TA1 - rtems_clock_get_tod - 09:00:00 12/31/1988

TA2 - rtems_clock_get_tod - 09:00:00 12/31/1988
TA3 - rtems_clock_get_tod - 09:00:00 12/31/1988

I will try to determine how to proceed further.



-- 
Regards, Denis Obrezkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170723/b9d5fd20/attachment-0002.html>


More information about the devel mailing list