xalloc (bbram) not working on rcm6600w

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 ?

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:


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];

1 Like

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.

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.