Hello Sebastian,
thanks for your note, I've already disabled POSIX and changed ticker
Init.c configuration with information taken from minimal sample to:
#define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
#define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
#define CONFIGURE_MAXIMUM_TASKS 4
#define CONFIGURE_USE_DEVFS_AS_BASE_FILESYSTEM
#define CONFIGURE_RTEMS_INIT_TASKS_TABLE
#define CONFIGURE_UNIFIED_WORK_AREAS
#define CONFIGURE_DISABLE_CLASSIC_API_NOTEPADS
#define CONFIGURE_MINIMUM_TASK_STACK_SIZE 512
#define CONFIGURE_MAXIMUM_PRIORITY 15
#define CONFIGURE_INIT
but still this is no picnic. RTEMS now fails with:
(gdb) bt
#0 0x0000cb04 in _Internal_error_Occurred
(the_source=RTEMS_FATAL_SOURCE_EXCEPTION, is_internal=false,
the_error=536875124) at
/export/home/karel/vcs/rtems/c/src/../../cpukit/score/src/interr.c:43
#1 0x0000aa2a in rtems_fatal (source=RTEMS_FATAL_SOURCE_EXCEPTION,
error=536875124) at
/export/home/karel/vcs/rtems/c/src/../../cpukit/sapi/src/fatal2.c:34
#2 0x00014c6c in _ARM_Exception_default (frame=0x20001074) at
/export/home/karel/vcs/rtems/c/src/../../cpukit/score/cpu/arm/arm-exception-default.c:24
#3 <signal handler called>
#4 __swrite (ptr=0x65e7ae8b, cookie=0xd
<bsp_start_vector_table_begin+13>, buf=0x20003370 "xa", n=1709682315) at
/tmp/archive/gcc-4.7.2/newlib/libc/stdio/stdio.c:81
#5 0x20003088 in bsp_section_work_begin ()
#6 0x20003088 in bsp_section_work_begin ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
at the second ticker task initialization. Looks like I'm really
scratching the limits of RAM and RTEMS here.
Honestly speaking for the project itself I really need just UART driver
and some application code. The project involves some bluetooth security
so the application code is either using pure UART or application
specific bluetooth stack (HCI) in case I'm going to use just HCI-enabled
bluetooth module... Anyway, it's quite hard to judge amount of memory
needed. Is there any way how to instruct RTEMS to trace RAM allocation
and at the end of application print minimal amount of remaining RAM or
maximal consumed RAM (or better is this value saved somewhere so I can
print it from debugger)? If so, then I may switch to STM32F4 which is
also supported by RTEMS and provides more RAM to see my project
application RAM limits...
Thanks!
Karel
On 08/12/13 09:21 AM, Sebastian Huber wrote:
Hello Karel,
with 32KiB RTEMS will only run with a careful chosen configuration. The
POSIX threads use 8KiB stack by default on ARM, so you run quickly out
of memory if you use this.
Please have a look at the Configuration global variable with the
debugger. It tells you the size estimates for a given configuration.
On 2013-08-11 20:42, Karel Gardas wrote:
Hello,
I'm adopting LM369xx BSP to work on LM4F120XL Lanchpad board. The
board does
have Cortex-M4F CPU with 256 kB flash, 32 kB RAM and 2 kB EEPROM. I've
successfully run RTEMS hello world on it already so now I'm on ticker.exe
hacking. I'm debugging it since it always fails with following backtrace:
(gdb) where
#0 _Workspace_Handler_initialization (areas=0x200010c8, area_count=1,
extend=0x0 <bsp_start_vector_table_begin>) at
/export/home/karel/vcs/rtems/c/src/../../cpukit/score/src/wkspace.c:89
#1 0x00001180 in bsp_work_area_initialize_default (area_begin=0x20002938,
area_size=22216) at
../../../../../.././lm4f120/lib/include/bsp/bootcard.h:176
#2 0x000011d0 in bsp_work_area_initialize () at
/export/home/karel/vcs/rtems/c/src/lib/libbsp/arm/lm3s69xx/../../shared/bspgetworkarea.c:57
#3 0x00001122 in boot_card (cmdline=0x0
<bsp_start_vector_table_begin>) at
/export/home/karel/vcs/rtems/c/src/lib/libbsp/arm/lm3s69xx/../../shared/bootcard.c:101
#4 0x00000116 in bsp_start_hook_0_done () at
/export/home/karel/vcs/rtems/c/src/lib/libbsp/arm/lm3s69xx/../shared/start/start.S:311
#5 0x00000116 in bsp_start_hook_0_done () at
/export/home/karel/vcs/rtems/c/src/lib/libbsp/arm/lm3s69xx/../shared/start/start.S:311
Backtrace stopped: previous frame identical to this frame (corrupt
stack?)
(gdb)
I don't know workspace manager at all so I'm curious what's so big
problem that
there is probably some remaining unallocated RAM? I.e. remaining is >
0 ? At
least I hope I interpret this well...
Thanks!
Karel
PS: I've configured rtems with --enable-posix --enable-samples
--disable-itron
--target=arm-rtemseabi --disable-networking --enable-rtemsbsp=lm4f120
-- and
I'm curious if 32 kB RAM is not enough for POSIX?
PPS: I'm using RTEMS HEAD as of Friday last week and of course one I
get this
working I'll submit my changes for inclusion as the TI LaunchPad is
really nice
and cheap board to experiment with RTEMS.
PPPS: linkcmds.lm4f120 looks:
/**
* @file
*
* @brief Memory map.
*/
MEMORY {
RAM_INT (AIW) : ORIGIN = 0x20000000, LENGTH = 32K
ROM_INT (RX) : ORIGIN = 0x00000000, LENGTH = 256K
}
REGION_ALIAS ("REGION_START", ROM_INT);
REGION_ALIAS ("REGION_VECTOR", RAM_INT);
REGION_ALIAS ("REGION_TEXT", ROM_INT);
REGION_ALIAS ("REGION_TEXT_LOAD", ROM_INT);
REGION_ALIAS ("REGION_RODATA", ROM_INT);
REGION_ALIAS ("REGION_RODATA_LOAD", ROM_INT);
REGION_ALIAS ("REGION_DATA", RAM_INT);
REGION_ALIAS ("REGION_DATA_LOAD", ROM_INT);
REGION_ALIAS ("REGION_FAST_TEXT", RAM_INT);
REGION_ALIAS ("REGION_FAST_TEXT_LOAD", ROM_INT);
REGION_ALIAS ("REGION_FAST_DATA", RAM_INT);
REGION_ALIAS ("REGION_FAST_DATA_LOAD", ROM_INT);
REGION_ALIAS ("REGION_BSS", RAM_INT);
REGION_ALIAS ("REGION_WORK", RAM_INT);
REGION_ALIAS ("REGION_STACK", RAM_INT);
INCLUDE linkcmds.armv7m
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel