Building Dynamic C 10.70 on a BL4S200.
This board has 512K of program space (I understand this is 64K of root and 448k of XMEM)
The code compiles to 348160 bytes, says the size of the BIN file and the Dynamic C download window. If I add a line or two of code anywhere, I get “out of xmem code space, refer to DC user manual…”
I referred to the DC 10 user manual AND TN238 “Rabbit memory usage tips” and neither has shed light on why I’m running out of XMEM when I should have almost 100k of it left.
Also, many of the suggestions in TN238 are out of date or deprecated (things I only learned on other forum posts!) Is there a more up to date version of this file?
For reference, I’m compiling with separate I&D, and I have ROOT_SIZE_4K defined to 0x04.
Can you post a copy of the .MAP file for that project, both from a successful compilation and from an aborted one? Please include any macros you’ve defined in the project as well. You might want to try increasing ROOT_SIZE_4K, since a value of 4 seems very tight. There’s a chance that’s somehow impacting the compiler’s ability to place functions in far memory, and it’s throwing an imprecise error message. I assume you’re not using the RemoteProgramUpdate functionality – if so, some of its configuration macros limit your program size.
Hi Tom, Thanks so much for helping!
I’ve generated the map files, but they’re nearly a megabyte each, too big for Pastebin. Any ideas on how to post them?
The .map files each start with:
Succeed:
//Segment Origin Size
Root Code 0000:0000 00b626
Root Data 0010:b800 003b22
Xmem Code 000e:e000 043d2c
Fail:
//Segment Origin Size
Root Code 0000:0000 00ae05
Root Data 0010:ad6f 000a90
Xmem Code 0000:e756 0518a2
Difference between the files is only about 15 lines in main().
There was a time when increasing the ROOT_SIZE_4K worked, but now it doesn’t seem to change anything, all the way up to 0x07.
I am using Remote Update. The bin file is downloaded over a modem and stored on FAT on an SD card and installed directly from the SD card. It’s configured with:
#define FAT_BLOCK
#define FAT_USE_FORWARDSLASH
#use “fat16.lib”
#define BOARD_UPDATE_VERBOSE
#define BU_TEMP_USE_FAT
#define BU_TEMP_FILE “code.bin”
#use “board_update.lib”
Other config macros I’m using:
#define DEBUG
#define USE_FAR_STRING_LIB
#define SOCKERR_NO_RETURN_NULL
#define TCPCONFIG 5
#use “BLxS2xx.lib”
Hi Tom, Thanks so much for helping!
I’ve generated the map files, but they’re nearly a megabyte each, too big for Pastebin. Any ideas on how to post them?
The .map files each start with:
Succeed:
//Segment Origin Size
Root Code 0000:0000 00b626
Root Data 0010:b800 003b22
Xmem Code 000e:e000 043d2c
Fail:
//Segment Origin Size
Root Code 0000:0000 00ae05
Root Data 0010:ad6f 000a90
Xmem Code 0000:e756 0518a2
Difference between the files is only about 15 lines in main().
There was a time when increasing the ROOT_SIZE_4K worked, but now it doesn’t seem to change anything, all the way up to 0x07.
I am using Remote Update. The bin file is downloaded over a modem and stored on FAT on an SD card and installed directly from the SD card. It’s configured with:
#define FAT_BLOCK
#define FAT_USE_FORWARDSLASH
#use “fat16.lib”
#define BOARD_UPDATE_VERBOSE
#define BU_TEMP_USE_FAT
#define BU_TEMP_FILE “code.bin”
#use “board_update.lib”
Other config macros I’m using:
#define DEBUG
#define USE_FAR_STRING_LIB
#define SOCKERR_NO_RETURN_NULL
#define TCPCONFIG 5
#use “BLxS2xx.lib”
In a working build, what’s the value of MAX_FIRMWARE_BINSIZE? Since you’re not using power-fail safe (PFS) updates, I don’t think the RPU features would limit firmware size.
Maybe main() has grown too large. I know functions can grow to over 4KB, but there could be a limit to 4KB for a single loop (like your main event loop). Could you try moving some code from main() and into a separate function?
In a working build, what’s the value of MAX_FIRMWARE_BINSIZE? Since you’re not using power-fail safe (PFS) updates, I don’t think the RPU features would limit firmware size.
Maybe main() has grown too large. I know functions can grow to over 4KB, but there could be a limit to 4KB for a single loop (like your main event loop). Could you try moving some code from main() and into a separate function?
The default memory map for DC in most cases reserves half the XMEM for code and half for data which means you can run out of code and still have plenty of XMEM if your data usage is less than half.
You can adjust the split using the XMEMCODE_SIZE macro which you can define in the Project Options\defines tab, e.g. XMEMCODE_SIZE=0x60000
Your 15 lines of code might make a big difference to the overall code size if they cause additional code from libraries to be included.
Can you post the .org file from the successful compile to show your current memory layout?
Regards,
Peter
1 Like
Hi
I have the same problem with the XMEM memory.
Before i used a BL2665 and i don’t have problem after change the DATA_ORG
The map is:
//Segment Origin Size
Root Code 00:0000 003dbd
Root Data 10:bdff 006168
Xmem Code 0e:e000 040b14
Noow i want to load the program on a BL4S200 and i have the message:
line 2161 : ERROR STDIO.C : Out of xmem code space. Please refer to the Dynamic C User’s Manual for more information.
The map is :
//Segment Origin Size
Root Code 0000:0000 003674
Root Data 0010:9620 0021df
Xmem Code 0000:e756 0518a4
I load the program in Flash and i use the Enable separate instruction and date option.
The product BL2665 and BL4S200 have the same memory but in the stdbios of the DC10.72D i dont know for mofify the DATA_ORG
Thanck you for the answer.