Home/Support/Support Forum/xalloc (bbram) not working on rcm6600w
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.

xalloc (bbram) not working on rcm6600w

0 votes
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 ?
asked Mar 14, 2018 in Rabbit Software by pvecchio New to the Community (3 points)

Please log in or register to answer this question.

2 Answers

0 votes
 
Best answer
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.
answered Mar 28, 2018 by TomCollins Veteran of the Digi Community (1,439 points)
selected Apr 3, 2018 by pvecchio
+1 vote
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:
Code:
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];
answered Mar 15, 2018 by TomCollins Veteran of the Digi Community (1,439 points)
edited Mar 15, 2018 by TomCollins
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
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.
...