Thanks.  I had remembered reading that the stack used idata and could be mapped into the upper 128 bytes but didn't realize data and idata were different.  I also see where data access to the upper 128 bytes maps into the CY7C68013's SFR space.

I assume if I set iram-size to 256 I need to set the location to zero.  (duh my bad early senior moment).

Here I've set iram-size to 128 and iram-loc to 128 to get the stack into the upper 128 and leave the lower 128 for data only.  Also eliminated using Register Bank 3 and let the compiler pack the data variables.  Then rewrote two functions to eliminate passing parameters and reduce the data memory size required.  

So much for elliminating global variables for good programming practices.  It doesn't make much sense to do so at this level as both the global variables and the additional passed parameters ended up at fixed locations in data memory thereby doubling the memory required.

Also for reference the code is started at 0x0500, to leave room for an asm program which is used to locate interrupt vectors and USB Jump Vectors starting a 0x0000 similar to Cypress's examples.  Then xdata is placed at 0x3600 to keep it above the code memory and yet stay within the Cypress CY7C68013's 16 kbytes of internal RAM.

Link command line:
sdcc -mmcs51 --model-small --iram-size 128 --idata-loc 128 ^
--code-loc 0x0500 --xram-loc 0x3600 ^
-L c:\SDCC\MyCode\EZ-USB_Lib -l EZUSB -I C:\SDCC\Include ^
fw.rel myStart.rel dscr.rel D2A_A2D.rel gpif_D2A_A2D.rel ^
crtpagesfr.rel myInit.rel myErrorCode.rel

Memory Map:
Internal RAM layout:
      0 1 2 3 4 5 6 7 8 9 A B C D E F
0x10:|2|2|2|2|2|2|2|2|c|c|c|c|c|c|c| |
0x60:|b|b|b|b|b|b|Q|Q|Q| | | | | | | |
0x70:| | | | | | | | | | | | | | | | |
0-3:Reg Banks, T:Bit regs, a-z:Data, B:Bits, Q:Overlay, I:iData, S:Stack, A:Absolute

Stack starts at: 0x80 (sp set to 0x7f) with 0 bytes available.

Other memory:
   Name             Start    End      Size     Max    
   ---------------- -------- -------- -------- --------
   PAGED EXT. RAM                         0      256  
   EXTERNAL RAM     0x3600   0x36c4     197    65536  
   ROM/EPROM/FLASH  0x0000   0x2fca   11412    65536  

Thanks again for all the help and suggestions.  I might actually want to do another embedded design someday.


Hi Kurt,

I think you misunderstand the keywords data and idata
and did not fully graps the (im)possibilities of the
8051 internal ram. Data memory is only 128 bytes big and
it shares space with the registers and bit variables. In
the upper 128 bytes you can only have idata variables
and stack. When using --pack-iram, the stack is
automatically placed after all data and idata variables.

--idata-loc 256 is impossible. There are only 256
addresses (0-255) available.

My recommendation is move some variables to


> We was compiling fine, made a few additions, and now we're out of room. We
> are using a Cypress CY7C68013 with 256 bytes of iram and don't believe we
> should be out of room.
> Exact error message is "?ASlink-Error-Insufficient space in data memory. 9
> bytes short."
> Link command line is in a dos batch file. carrot (^) does a line extend;
> sdcc -mmcs51 --model-small --iram-size 256 --idata-loc 256 ^
> --stack-loc 0xA0 --no-pack-iram ^
> --code-loc 0x0500 --xram-loc 0x3600 ^
> -L c:\SDCC\MyCode\EZ-USB_Lib -l EZUSB -I C:\SDCC\Include ^
> fw.rel myStart.rel dscr.rel D2A_A2D.rel gpif_D2A_A2D.rel ^
> crtpagesfr.rel myInit.rel myErrorCode.rel
> We've set iram size to 256 but it doesn't appear that the compiler will
> let me use it for data memory.  Without the stack location change we get
> an error that we were 14 bytes short.  Is there a compiler limit that does
> not allow for more than 128 bytes of variables?  Added the no pack iram
> option when we moved the stack to no avail.  We'ld like to use pack to get
> the register space back but then it doesn't let us move the stack into the
> upper 128 bytes?  It seems a shame to have 256 bytes of RAM and not be
> able to have the compiler assign it.
> The last thing tried was to pack, eliminate using 3, and move the stack to
> 0x7f, 0x7e, and 0xa0.  With packing the stack move doesn't appear to work
> and its allocated to 0x0000 when the data memory is "out of room".  The
> iram size doesn't seem to allow the stack to be placed above 0x80 when
> pack is enabled.
> Any help is welcome.  Thanks.  (otherwise we'll have to eliminate a few
> variables, using 2, etc., or maybe assign fixed addresses for a few
> variables in the upper 128 bytes, then assign the stack in the upper 128
> bytes, and use the no pack iram option.)
> sdcc version is
> SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08
> 2.9.2 #5524 (Sep 28 2009) (MINGW32)
> Running under Windows XP.
> Kurt M. Sanger

Return on Information:
Google Enterprise Search pays you back
Get the facts.
Sdcc-user mailing list