2017-07-24 20:36 GMT+02:00 Joel Sherrill <j...@rtems.org>: > > > On Jul 24, 2017 2:28 PM, "Denis Obrezkov" <denisobrez...@gmail.com> wrote: > > 2017-07-24 8:56 GMT+02:00 Denis Obrezkov <denisobrez...@gmail.com>: > >> 2017-07-24 8:27 GMT+02:00 Hesham Almatary <heshamelmat...@gmail.com>: >> >>> On Mon, Jul 24, 2017 at 8:27 AM, Joel Sherrill <j...@rtems.org> wrote: >>> > >>> > >>> > On Jul 23, 2017 5:15 PM, "Denis Obrezkov" <denisobrez...@gmail.com> >>> wrote: >>> > >>> > 2017-07-23 22:30 GMT+02:00 Joel Sherrill <j...@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@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
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
