To start with the compiler bug (small one), see this program: http://mbed.org/users/okano/code/IAP_internal_flash_write/. The IAP library reserves the flash you are going to use, so no other elements can use it. If I got it correct, it does so with:

unsigned char user_area[ USER_FLASH_AREA_SIZE ] __attribute__((section( ".ARM.__at_" USER_FLASH_AREA_START_STR( USER_FLASH_AREA_START ) ), zero_init));

That all works nicely (afaik), but the small bug: If you compile it, the RAM usage according to build detail is above 100%. To be exact, it is an additional 100% for each flash sector you include as yours (32kB). So the compiler does not recognize that char is not in the RAM but in flash memory. Everything does work, so it is just a bug with the calculations for the bar.

The stream one hopefully gets here more attention: You can attach for example your LCD window to stdout to get all printf messages on your LCD. According to early posts here that only works if the Stream object that the LCD class is a child of, was initialized with a name. The option to initialize it with a name was removed from the mbed library. So is there either a workaround for this, or is it really not possible anymore?

Hi Erik,

The ARM compiler, which is the backend of the mbed Compiler build system, accounts these 32KB as ZI data:

      Code (inc. data)   RO Data    RW Data    ZI Data      Debug
      1180        380        368        124      32816        844   Object Totals
     11048        956        572         52        336       9084   Library Totals

Furthermore, the grand total reported by the ARM compiler shows that these 32KB are indeed accounted against the RAM, not the Flash:

    Total RO  Size (Code + RO Data)                13168 (  12.86kB)
    Total RW  Size (RW Data + ZI Data)             33328 (  32.55kB)

I'll forward this to our team for further investigation.

Thanks,
Mihail

Hi Erik, I think your first issue is caused by the attribute zero_init: try to remove it.

Regarding the second issue, I guess you are using an old version of the library, currently the Serial class can be initialized with a name:

Serial(PinName tx, PinName rx, const char *name=NULL);

HTH, Emilio

Look at the date of the post ;). I also replied in an older topic regarding that problem, and in response the name parameter was re-added :).

Regarding the zero_init, when I remove it from the IAP example program, I get:

"Load region LR_IROM1 size (524464 bytes) exceeds limit (524288 bytes). Region contains 478446 bytes of padding and 0 bytes of veneers (total 478446 bytes of linker generated content)." in file "/"

Now this is way outside my area of expertise, so I also have no idea what I am doing. It isn't very important though, it is only that its RAM usage report is inaccurate (which generally won't tell you too much anyway).

Hi Erik, yes, sorry, I did not notice the date, an internal ticket was opened yesterday linking to this thread and I assumed it was recent. When we fixed the stream name issue we missed to reply to this thread.

Regarding the IAP_internal_flash_write program, I think the intent is to reserve an area of flash for a user application, using zero_init it was failing to do so because the array was positioned in ram. Removing the zero_init the area is reserved in flash as intended and the linker correctly notifies you if there is not enough space, ie: you should reduce USER_FLASH_AREA_SIZE.

Cheers, Emilio

Emilio, Erik,

I'm the one to blame about the stream name issue. I also knew it was solved, but forgot to mention it when I opened the ticket - sorry for wasting your time.
I mentioned this link because i wanted to know if there was a solution to the RAM usage graph (didn't want to create a new topic since the question already existed). Next time, i'll pay more attention when I refer to an existing topic.

Frank.