# xalloc (bbram) not working on rcm6600w **URL:** \ **Category:** Rabbit Software\ **Tags:** xalloc, xalloc\_bb, xmem, bbram, 6600w\ **Created:** [March 14, 2018, 3:06pm UTC](https://forums.digi.com/t/xalloc-bbram-not-working-on-rcm6600w/19306 "2018-03-14T15:06:58Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![pvecchio](https://avatars.discourse-cdn.com/v4/letter/p/e19adc/32.png) [@pvecchio](https://forums.digi.com/u/pvecchio)\ **Post date:** [March 14, 2018, 3:06pm UTC](https://forums.digi.com/t/xalloc-bbram-not-working-on-rcm6600w/19306/1 "2018-03-14T15:06:58Z")
Hello, I’ve been using rabbit 5600w and now i want to reuse the same code with 6600w and 6650w. So far now, 6650w it’s working fine but 6600w throw a runtime error: Run time error: “Xmem allocation failed (out of memory)” File: MEM:LIB Function: \_xalloc The code with conflict is: unsigned long cant = 255; PtrXmem = \_xalloc(&cant, 1, XALLOC\_BB/_XALLOC\_ANY_/); If 255 is reduced to ie 64 the error is no throwed or even using ‘XALLOC\_ANY’ but still not working ok (not holding data). On 5600w and 6650w works ok with cant = 64 or cant = 255 and XALLOC\_BB. Using the example ‘xalloc\_stats.c’ i discovered available xalloc regions of BBRAM: 5600w -\> 2FF0 6600w -\> 40 6650w -\> 40 and F0A9C Is this ok ? ---
**Author:** ![TomCollins](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.digi.com/tomcollins/32/37_2.png) [@TomCollins](https://forums.digi.com/u/TomCollins)\ **Post date:** [March 15, 2018, 3:15pm UTC](https://forums.digi.com/t/xalloc-bbram-not-working-on-rcm6600w/19306/2 "2018-03-15T15:15:35Z")
What project macros have you defined? How about compilation options? Have you enabled separate instruction and data space? Maybe you have FAT enabled for a small filesystem on the RCM6600W serial flash? When I run xalloc\_stats.c on an RCM6600W, I’m seeing the following for BBRAM: ```auto Low addr High addr Current Avail Type ---------- ---------- ---------- ---------- ------- 20D010 20ED08 20ED08 1CF8 BB RAM ``` Looks like 32KB BBRAM mapped from 20C000 to 213FFF. First 4KB reserved for root variables, next 8KB for xmem, and next 20KB reserved for something else. And it looks like the compiler/linker is favoring that 8KB of space for far memory allocations so it’s getting used up first. I’ll do some more exploration and see if it’s possible to change the memory layout definitions in a way to encourage the compiler to use memory region #10 (0xD0000 to 0xFEFFF) first. A workaround, if you don’t need dynamic allocation at runtime, is to make use of the “bbram” keyword in a global variable declaration that appears before loading any libraries. bbram far char bb\_alloc[1024]; ---
**Author:** ![pvecchio](https://avatars.discourse-cdn.com/v4/letter/p/e19adc/32.png) [@pvecchio](https://forums.digi.com/u/pvecchio)\ **Post date:** [March 16, 2018, 11:43am UTC](https://forums.digi.com/t/xalloc-bbram-not-working-on-rcm6600w/19306/3 "2018-03-16T11:43:33Z")
Thanks for your answer. The biggest doubt is regarding the different behaviors between 6600w and 6650w if both have 32k of bbram Defines: BU\_ENABLE\_SECONDARY MAX\_FIRMWARE\_BINSIZE=0x70000 ROOT\_SIZE\_4K = 6 DISABLE\_ETHERNET Compiler Options Checked Array indices Prototype Demotion Optimize for Speed Strore program in flash Enable istruction and data spaces Inline builtin I\O function ---
**Author:** ![TomCollins](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.digi.com/tomcollins/32/37_2.png) [@TomCollins](https://forums.digi.com/u/TomCollins)\ **Post date:** [March 23, 2018, 1:26pm UTC](https://forums.digi.com/t/xalloc-bbram-not-working-on-rcm6600w/19306/4 "2018-03-23T13:26:43Z")
I don’t know if it’s something we can easily fix. I believe the compiler places “far” variables at the highest address (or the highest XVARORG entry in the orgtable) and works its way down. The RCM6650W has an external 1MB SRAM mapped at a higher memory location than the 32KB of BBRAM. I’ll see if it’s possible to monkey with the org table so the BBRAM is lower priority for placing far variables, but I think the workaround is to declare global variables as “bbram” early in your program, before you #use any libraries. ---
**Author:** ![TomCollins](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.digi.com/tomcollins/32/37_2.png) [@TomCollins](https://forums.digi.com/u/TomCollins)\ **Post date:** [March 28, 2018, 8:07pm UTC](https://forums.digi.com/t/xalloc-bbram-not-working-on-rcm6600w/19306/5 "2018-03-28T20:07:54Z")
Unfortunately there isn’t a simple solution to this issue. The Rabbit6000 has 1MB of built-in RAM and 32KB of built-in battery-backed RAM. The memory map places the 1MB at address 0 (necessary since code runs from that RAM) and the 32KB at 0x200000. The compiler places far variables at the highest address where they’ll fit. As a result, it uses the battery-backed RAM first. It isn’t possible to modify the memory orgs to get the compiler to prioritize the built-in 1MB. I was unable to find a way to mark that memory as unusable for far variables without also making it unavailable for bbram xalloc. On an RCM6650W, there’s an extra, external 1MB SRAM that is battery backed, so you don’t run into this problem. The best workaround I found was to allocate far, battery-backed variables at compile time, before the compiler can place anything else in far memory. Use this syntax early on in your main C file: bbram far char reserve[0x1CF8]; That reserves all available space (from what I could see in my calculations). You can also just declare each variable you’d like to maintain as battery-backed and reference them directly – the character array is just if you wanted to do dynamic allocations. Samples/memory\_usage.c was helpful in understanding the memory layout. Let me know if you have more questions on this topic.