TI LaunchPad 120XL BSP issue.

Sebastian Huber sebastian.huber at embedded-brains.de
Mon Aug 12 12:56:52 UTC 2013


On 2013-08-12 14:44, Karel Gardas wrote:
>
> 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

This a very low stack size.  You can use the stack checker to see the actual 
stack usage.

You can also use

#define CONFIGURE_DISABLE_NEWLIB_REENTRANCY

#define CONFIGURE_UNIFIED_WORK_AREAS

#define CONFIGURE_IDLE_TASK_INITIALIZES_APPLICATION

as additional options.

>
> #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

Be careful if you want to use printf() etc. with such a low stack size.

> #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...

32KiB is enough for simple C applications on RTEMS if you are careful.  Its not 
something that works out of the box.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.



More information about the devel mailing list