Can't enable a dummy clock driver

[Denis Obrezkov]

2017-07-24 20:36 GMT+02:00 Joel Sherrill <joel at rtems.org>:

>
>
> On Jul 24, 2017 2:28 PM, "Denis Obrezkov" <denisobrezkov at gmail.com> wrote:
>
> 2017-07-24 8:56 GMT+02:00 Denis Obrezkov <denisobrezkov at gmail.com>:
>
>> 2017-07-24 8:27 GMT+02:00 Hesham Almatary <heshamelmatary at gmail.com>:
>>
>>> On Mon, Jul 24, 2017 at 8:27 AM, Joel Sherrill <joel at rtems.org> wrote:
>>> >
>>> >
>>> > 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.
>>> >
>>> Do you configure RISC-V to get timer (or any) interrupts? You might
>>> want to disable all sources of interrupts, and make sure no interrupts
>>> are generated at all, just to figure out if the problem is with
>>> interrupt handling (including context save/restore).
>>>
>>>
>>> >
>>> >
>>> > --
>>> > Regards, Denis Obrezkov
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > devel mailing list
>>> > devel at rtems.org
>>> > http://lists.rtems.org/mailman/listinfo/devel
>>>
>>>
>>>
>>> --
>>> Hesham
>>>
>> Interrupts are disabled.
>>
>>
>> --
>> Regards, Denis Obrezkov
>>
>
> Also, though I did almost everything like in v850sim and RISC-V generic
> examples, my dummy clock driver
> doesn't tick. It seems to me that clock_driver_sim_idle_body just never
> runs.
> Should I try to implement an interrupt driven clock?
>
>
> Eventually you need to but if this doesn't run, something is broken. Is
> the configuration magic in bsp.h done? What's the configures is thread body?
>
>
>
> --
> Regards, Denis Obrezkov
>
>
> Yes, I added required lines in bsp.h and in Makefile.am.

Now, I think that something broken during drivers initialization.
I just remembered that I wasn't able to configure a low ticker app without
a console driver.
And I can see now that the console driver configuration process ends with
RTEMS_INTERNAL_ERROR.
I think I will try again to debug a clock driver without a console driver .



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