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? -- Regards, Denis Obrezkov
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel