# "out of xmem code space" when there should be plenty of xmem left **URL:** \ **Category:** Rabbit\ **Tags:** compiler, rabbit-4000, bl4s200, xmem, memory\ **Created:** [September 23, 2016, 2:08am UTC](https://forums.digi.com/t/out-of-xmem-code-space-when-there-should-be-plenty-of-xmem-left/17442 "2016-09-23T02:08:42Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![ethan-lpi](https://avatars.discourse-cdn.com/v4/letter/e/f0a364/32.png) [@ethan-lpi](https://forums.digi.com/u/ethan-lpi)\ **Post date:** [September 23, 2016, 2:08am UTC](https://forums.digi.com/t/out-of-xmem-code-space-when-there-should-be-plenty-of-xmem-left/17442/1 "2016-09-23T02:08:42Z")
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. ---
**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:** [September 26, 2016, 1:44pm UTC](https://forums.digi.com/t/out-of-xmem-code-space-when-there-should-be-plenty-of-xmem-left/17442/2 "2016-09-26T13:44:26Z")
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. ---
**Author:** ![ethan-lpi](https://avatars.discourse-cdn.com/v4/letter/e/f0a364/32.png) [@ethan-lpi](https://forums.digi.com/u/ethan-lpi)\ **Post date:** [September 26, 2016, 3:42pm UTC](https://forums.digi.com/t/out-of-xmem-code-space-when-there-should-be-plenty-of-xmem-left/17442/3 "2016-09-26T15:42:16Z")
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” ---
**Author:** ![ethan-lpi](https://avatars.discourse-cdn.com/v4/letter/e/f0a364/32.png) [@ethan-lpi](https://forums.digi.com/u/ethan-lpi)\ **Post date:** [September 26, 2016, 4:03pm UTC](https://forums.digi.com/t/out-of-xmem-code-space-when-there-should-be-plenty-of-xmem-left/17442/4 "2016-09-26T16:03:08Z")
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” ---
**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:** [September 26, 2016, 4:19pm UTC](https://forums.digi.com/t/out-of-xmem-code-space-when-there-should-be-plenty-of-xmem-left/17442/5 "2016-09-26T16:19:49Z")
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? ---
**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:** [September 26, 2016, 4:20pm UTC](https://forums.digi.com/t/out-of-xmem-code-space-when-there-should-be-plenty-of-xmem-left/17442/6 "2016-09-26T16:20:12Z")
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? ---
**Author:** ![petermcs](https://avatars.discourse-cdn.com/v4/letter/p/4af34b/32.png) [@petermcs](https://forums.digi.com/u/petermcs)\ **Post date:** [September 27, 2016, 9:31am UTC](https://forums.digi.com/t/out-of-xmem-code-space-when-there-should-be-plenty-of-xmem-left/17442/7 "2016-09-27T09:31:20Z")
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 ---
**Author:** ![arizzorabbit](https://avatars.discourse-cdn.com/v4/letter/a/a87d85/32.png) [@arizzorabbit](https://forums.digi.com/u/arizzorabbit)\ **Post date:** [March 4, 2020, 10:06am UTC](https://forums.digi.com/t/out-of-xmem-code-space-when-there-should-be-plenty-of-xmem-left/17442/8 "2020-03-04T10:06:36Z")
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.