[En-Nut-Discussion] Code size to large for one flash bank

Bernd Walter enut at cicely.de
Mon Dec 27 16:18:28 CET 2010


On Mon, Dec 27, 2010 at 03:07:18PM +0100, Andre Riesberg wrote:
> Bernd Walter schrieb:
> >On Mon, Dec 27, 2010 at 10:37:13AM +0100, Andre Riesberg wrote:
> >  
> >>Hello all!
> >>
> >>The codes size of my application grows and exceeds the limit of 262144 
> >>bytes.
> >>Now I got the message from OpenOCD:
> >>"Warn: writing 262144 bytes only ??? as image section is 270228 bytes and 
> >>bank is only 262144 bytes."
> >>I use a board like the EIR with ARM7TMI and the Turtelizer2 with the 
> >>command line: "C:\ethernut-4.8.3\nut\tools\win32\openocd.exe -f 
> >>interface\turtelizer2.cfg -f eir.cfg".
> >>
> >>So, I have two questions:
> >>
> >>How I have to modify the config scripts to support the second flash bank?
> >>    
> >
> >IIRC you just need to setup the bigger rom size in the loader script.
> >>From the software point of view this is just a single large rom space.
> >  
> I use the "at91sam7se512_rom.ld" script. This file is for 512k flash (  
> "rom(rx)   : org = 0x00000000, len = 512k"  ).

Oh - my fault - I didn't read your error message in detail.
I have a similar problem - I use a software via SAM-BA, which can't
write the second bank util I enhance it.
But I never needed it yet, so there wasn't any pressure.
I use the SAM7X512 in some projects, but so far only for RAM.

> >Care must be taken if you write data to the flash - I'm not sure if the
> >ethernut flashing routine supports multiple banks.
> >If you don't use this feature there is no problem.
> >  
> This is the point! I use OpenOCD and the Turtelier2 JTAG. I use a self 
> written tool ("TCPSend") to send command via localhost:4444 to OpenOCD.
> My command will invoke the function "nut_flash" with one paremeter: my 
> application "flash.bin".
> 
> Here is the codes snipped from "eri.cfg":
> 
> # Write image to flash.
> #
> proc nut_flash {IMGFILE {TYPE ""} {OFFSET ""}} {
>    reset init
>    flash protect 0 0 15 off
>    set TYPE [nut_imgtype $IMGFILE $TYPE]
>    set OFFSET [nut_imgtypeoffset $TYPE $OFFSET 0x100000]
>    flash write_image erase $IMGFILE $OFFSET $TYPE
>    verify_image $IMGFILE $OFFSET $TYPE
>    at91sam7 gpnvm 2 set
> }
> 
> I think the command "flash write_image erase...." can ony write on bank 
> at once. No problem to add another "flash write_image erase..." command 
> with a different offset for the second bank. But how can I split the 
> *.bin file? Or, how I can say, write the first 256k into the first bank 
> and the rest to the second bank?
> Ther must be a common way to do this job! If I be despaired enough, I 
> can write a rom file file splitter....

Likely there is a way - you surely are not the first one with this problem.
Since I'm not using OpenOCD for AT91 I can't say anything about it.

> >>It is possible to force some functions (module) into thump mode to save 
> >>space? I have seen thump-interwork is enabled in NutOS. Is there 
> >>something like __attribute__((thump)) for functions?
> >>    
> >
> >Not that I know.
> >I've declared many Makefiles for thumb in my own environment, which is
> >based on 4.9.8.
> >First I'd started with my application code and than with all possible
> >Ethernut sourcefiles.
> >Generally speaking it is mostly the interrupt routines left and the
> >size difference was rather hughe.
> >I'm able to run Nut/OS on SAM7S32 and SAM7S321 with this - although
> >without IP on those.
> >Speedwise it is also a win with SAM7S/X since the flash controller has
> >waitstate-free prefetching for 16bit instructions only.
> >
> >  
> Hello Bernd,
> 
> thank you for the fast answer! See my commend above.
> 
> I will dig into your diff file an try to setup a small applcation with 
> modules in thump mode.

This will get you the missing bytes to get below 256k for sure.
My thumb binaries für SAM7X256/512 are usually somewhat around 110k - 120k,
unless I use Lua, but you must have much more compiled in.

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.



More information about the En-Nut-Discussion mailing list