Yes I think the RB Heap would be an ideal solution. My intuition is that the exception is caused exactly by the heap (workspace) metadata being written, but Hesham should hook up a debugger to verify the source of the exception.
-Gedare On Wed, Aug 28, 2013 at 3:00 AM, Sebastian Huber <sebastian.hu...@embedded-brains.de> wrote: > On 2013-08-28 02:00, Hesham Moustafa wrote: >> >> Hey all, >> >> I want to allocate memory within an application code, set >> memory access attributes on it, and check whether these >> permissions are set correctly or not. >> >> I tried to use _Workspace_Allocate(), malloc(), and partition and region >> managers to allocate a region of memory, but just after I set the >> allocated region to READ_ONLY attribute, an exception occurs. There is >> no problem when I set WRITE attribute. Also when I use hard-coded >> addresses ( that do not belong to any used section by RTEMS), I get it >> working correctly. > > > Why do you get an exception? The heap manager places some administration > data right at the begin and end of an allocated block. See also > > http://www.rtems.org/onlinedocs/doxygen/cpukit/html/group__RBHeap.html > > >> >> Is there a way to allocate memory without hard-coded addresses >> (target-independent), or the previous "exception-after-set" problem ? >> >> Regards, >> Hesham >> _______________________________________________ >> rtems-devel mailing list >> rtems-devel@rtems.org >> http://www.rtems.org/mailman/listinfo/rtems-devel >> > > > -- > 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.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > > _______________________________________________ > 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
