stm32f4 - max free mem / ram size
Locked
|
Hi, by try and error I try to determine the max ram for the bytecode
(using life.lua to fill it full). platform_conf.h: #define SRAM_SIZE ( 128 * 1024 ) //was 60 With 128 I get it working, the 140 does [Hard fault handler]------------ R0 = fffe2274------------------- R1 = 20002138------------------- R2 = 134------------------------ R3 = 2001fff8------------------- R12 = fffe226c------------------ LR = 801b06b-------------------- PC = 801a900-------------------- PSR = 81000000------------------ BFAR = 20020000----------------- CFSR = 8200--OO----------------- HFSR = 40000000----------------- DFSR = 8------------------------ AFSR = 0 Is there any good hint how to set the ram to "fully" utilise the f4 space? Thnx,pi. -- Jak se vyhnout nachlazení a dalším zdravotním potížím v nepříjemném podzimním období? Čtěte speciál Zdraví na podzim na http://web.volny.cz/data/click.php?id=1290 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
 
|
Zhanjun Dong |
Re: stm32f4_-_max_free_mem_/_ram_s
|
|
The F4 has 196K in total, but it split into 2 sections:
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K // Major SRAM
CCMRAM (xrw) : ORIGIN = 0x10000000, LENGTH = 64K // Backup SRAM
As you can see, the memory space is not continually, change the SRAM_SIZE over 128K won't work.
Is there a existing way to let eLua access 2nd RAM segment?
Sincerely
Zhanjun Dong
======= 2011-11-10 10:57:20 ：=======
>Hi, by try and error I try to determine the max ram for the bytecode
>(using life.lua to fill it full).
>platform_conf.h:
>#define SRAM_SIZE ( 128 * 1024 ) //was 60
>
>With 128 I get it working, the 140 does
>[Hard fault handler]------------
>R0 = fffe2274-------------------
>R1 = 20002138-------------------
>R2 = 134------------------------
>R3 = 2001fff8-------------------
>R12 = fffe226c------------------
>LR = 801b06b--------------------
>PC = 801a900--------------------
>PSR = 81000000------------------
>BFAR = 20020000-----------------
>CFSR = 8200--OO-----------------
>HFSR = 40000000-----------------
>DFSR = 8------------------------
>AFSR = 0
>
>Is there any good hint how to set the ram to "fully" utilise the f4
>space?
>Thnx,pi.
>
>
>--
>Jak se vyhnout nachlazení a dalším zdravotním potížím v nepříjemném
>podzimním období? Čtěte speciál Zdraví na podzim na
>
>
>
>_______________________________________________
>eLua-dev mailing list
>https://lists.berlios.de/mailman/listinfo/elua-dev
= = = = = = = = = = = = = = = = = = = =
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Well, eLua can certainly work with multiple regions of RAM, however
I'm not sure if there are any caveats to the usage of that additional region of RAM. I seem to recall some discussion related to it when this platform was initially discussed on the list. In any case, take a look at examples of platforms that have SDRAM like some of the avr32 platforms: elua/src/platform/avr32/EVK1100/evk1100_conf.h: // Allocator data: define your free memory zones here in two arrays // (start address and end address) #define MEM_START_ADDRESS { ( void* )end, ( void* )SDRAM } #define MEM_END_ADDRESS { ( void* )( 0x10000 - STACK_SIZE_TOTAL - 1 ), ( void* )( SDRAM + SDRAM_SIZE - 1 ) } As above, you need to define 2 arrays, one for each region. And then you will need to to use allocator=multiple (allocator=newlib might work also, since "multiple" is and "newlib" both use dlmalloc, but historically at some point at least "multiple" used a newer version of dlmalloc). I think that might be it? Unless there's something needed for that region of SRAM to be usable on the platform? 2011/11/10 Zhanjun Dong <[hidden email]>: > The F4 has 196K in total, but it split into 2 sections: > > RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K // Major SRAM > CCMRAM (xrw) : ORIGIN = 0x10000000, LENGTH = 64K // Backup SRAM > > As you can see, the memory space is not continually, change the SRAM_SIZE over 128K won't work. > > Is there a existing way to let eLua access 2nd RAM segment? > > Sincerely > Zhanjun Dong > > ======= 2011-11-10 10:57:20 ：======= > >>Hi, by try and error I try to determine the max ram for the bytecode >>(using life.lua to fill it full). >>platform_conf.h: >>#define SRAM_SIZE ( 128 * 1024 ) //was 60 >> >>With 128 I get it working, the 140 does >>[Hard fault handler]------------ >>R0 = fffe2274------------------- >>R1 = 20002138------------------- >>R2 = 134------------------------ >>R3 = 2001fff8------------------- >>R12 = fffe226c------------------ >>LR = 801b06b-------------------- >>PC = 801a900-------------------- >>PSR = 81000000------------------ >>BFAR = 20020000----------------- >>CFSR = 8200--OO----------------- >>HFSR = 40000000----------------- >>DFSR = 8------------------------ >>AFSR = 0 >> >>Is there any good hint how to set the ram to "fully" utilise the f4 >>space? >>Thnx,pi. >> >> >>-- >>Jak se vyhnout nachlazení a dalším zdravotním potížím v nepříjemném >>podzimním období? Čtěte speciál Zdraví na podzim na >>http://web.volny.cz/data/click.php?id=1290 >> >> >> >>_______________________________________________ >>eLua-dev mailing list >>[hidden email] >>https://lists.berlios.de/mailman/listinfo/elua-dev > > = = = = = = = = = = = = = = = = = = = = > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > > eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Two regions - maybe compiler/linker can do that as well.. My naive
understanding has been we can use the ram in a continuos way.. Would be nice to have 196k handy..p. ----- PŮVODNÍ ZPRÁVA ----- Od: "James Snyder" <[hidden email]> Komu: "eLua Users and Development List (www.eluaproject.net)" <[hidden email]> Předmět: Re: [eLua-dev] stm32f4_-_max_free_mem_/_ram_size Datum: 11.11.2011 - 3:49:46 > Well, eLua can certainly work with multiple > regions of RAM, however > I'm not sure if there are any caveats to the usage > of that additional > region of RAM. I seem to recall some discussion > related to it when > this platform was initially discussed on the list. > > In any case, take a look at examples of platforms > that have SDRAM like > some of the avr32 platforms: > elua/src/platform/avr32/EVK1100/evk1100_conf.h: > // Allocator data: define your free memory zones > here in two arrays > // (start address and end address) > #define MEM_START_ADDRESS { ( void* )end, ( > void* )SDRAM } > #define MEM_END_ADDRESS { ( void* )( 0x10000 > - STACK_SIZE_TOTAL > - 1 ), ( void* )( SDRAM + SDRAM_SIZE - 1 ) } > > As above, you need to define 2 arrays, one for > each region. And then > you will need to to use allocator=multiple > (allocator=newlib might > work also, since "multiple" is and "newlib" both > use dlmalloc, but > historically at some point at least "multiple" > used a newer version of > dlmalloc). > > I think that might be it? Unless there's > something needed for that > region of SRAM to be usable on the platform? > > 2011/11/10 Zhanjun Dong <[hidden email]>: > > The F4 has 196K in total, but it split into 2 sections: > > > > > RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K // Major SRAM > > > > > CCMRAM (xrw) : ORIGIN = 0x10000000, LENGTH = 64K // Backup SRAM > > > > > > > > As you can see, the memory space is not continually, change the SRAM_SIZE over 128K won't work. > > > > > > > Is there a existing way to let eLua access 2nd RAM segment? > > > > > Sincerely > > Zhanjun Dong > > > > ======= 2011-11-10 10:57:20 ：======= > > > >>Hi, by try and error I try to determine the max ram for the bytecode > >>> >>>>(using life.lua to fill it full). > >>platform_conf.h: > >>#define SRAM_SIZE ( 128 * 1024 ) //was 60 > >>>> > >>With 128 I get it working, the 140 does > >>[Hard fault handler]------------ > >>R0 = fffe2274------------------- > >>R1 = 20002138------------------- > >>R2 = 134------------------------ > >>R3 = 2001fff8------------------- > >>R12 = fffe226c------------------ > >>LR = 801b06b-------------------- > >>PC = 801a900-------------------- > >>PSR = 81000000------------------ > >>BFAR = 20020000----------------- > >>CFSR = 8200--OO----------------- > >>HFSR = 40000000----------------- > >>DFSR = 8------------------------ > >>AFSR = 0 > >> > >>Is there any good hint how to set the ram to "fully" utilise the f4 > >>> >>>>space? > >>Thnx,pi. > >> > >> > >>-- > >>Jak se vyhnout nachlazení a dalším zdravotním potížím v nepříjemném > >>> >>>>podzimním období? Čtěte speciál Zdraví na podzim na > >>>>http://web.volny.cz/data/click.php?id=1290 > >> > >> > >> > >>_______________________________________________ > >>eLua-dev mailing list > >>[hidden email] > >>https://lists.berlios.de/mailman/listinfo/elua-dev > >>> > > = = = = = = = = = = = = = = = = = = = = > > > > _______________________________________________ > > eLua-dev mailing list > > [hidden email] > > https://lists.berlios.de/mailman/listinfo/elua-dev > > > > > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > -- Jak co nejlépe přichystat automobil na provoz v nadcházející zimní sezóně? Čtěte speciál Příprava auta na zimu na http://web.volny.cz/data/click.php?id=1292 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Hi,
On Fri, Nov 11, 2011 at 10:23 AM, pito <[hidden email]> wrote: Two regions - maybe compiler/linker can do that as well.. My naive The compiler/linker can't do anything if the memory regions are not _physically_ contiguous in the MCU address space (which is the case here). The allocator, though, can work with two or more isolated memory blocks. It will never be able to allocate 196k in a single piece, but it will be able to allocate smaller pieces from both regions.
Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
> The compiler/linker can't do anything if the
> memory regions are not > _physically_ contiguous in the MCU address space > (which is the case here). > The allocator, though, can work with two or more > isolated memory blocks. It > will never be able to allocate 196k in a single > piece, but it will be able > to allocate smaller pieces from both regions. > > Best, > Bogdan Unless you want to execute from ram (not the elua case) any compiler/linker must be able to handle none contigous ram spaces.. For example all the pic16/18 c-compilers handle that (ie pic16s have 4 ram banks with a happy mixture of various registers and ram).. -- Jak se vyhnout nachlazení a dalším zdravotním potížím v nepříjemném podzimním období? Čtěte speciál Zdraví na podzim na http://web.volny.cz/data/click.php?id=1290 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
2011/11/11 pito <[hidden email]>
The compiler doesn't have anything to do with RAM spaces. The linker can allocate the variables (or code) in your program in different RAM spaces as dictated by your linker command script. The allocator can also handle different RAM spaces at run time. None of these tools are able to make a contiguous RAM space from physically non-contiguous RAM regions. It could be possible to do this at runtime if the MCU had a MMU, but this is certainly not the case here.
Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by jbsnyder
So what about this for F4 (not tested):
// Allocator data: define your free memory zones here in two arrays // (start address and end address) // The F4 has 196K in total, but it split into 2 sections: // RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K // Major SRAM // CCMRAM (xrw) : ORIGIN = 0x10000000, LENGTH = 64K // Backup SRAM #define CCSRAM_SIZE ( 64 * 1024 ) #define CCSRAM_BASE 0x10000000 #define SRAM_SIZE ( 128 * 1024 ) #define MEM_START_ADDRESS { ( void* )end, CCSRAM_BASE } #define MEM_END_ADDRESS { ( void* )( SRAM_BASE + SRAM_SIZE - STACK_SIZE_TOTAL - 1 ), ( CCSRAM_BASE+CCSRAM_SIZE - 1 ) } -- Jak se vyhnout nachlazení a dalším zdravotním potížím v nepříjemném podzimním období? Čtěte speciál Zdraví na podzim na http://web.volny.cz/data/click.php?id=1290 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
2011/11/11 pito <[hidden email]> So what about this for F4 (not tested): That sounds OK. Remember to compile eLua with 'allocator=multiple'. Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
So with this and allocator=multiple
// Allocator data: define your free memory zones here in two arrays // (start address and end address) // The F4 has 196K in total, but it split into 2 sections: // RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K // Major SRAM // CCMRAM (xrw) : ORIGIN = 0x10000000, LENGTH = 64K // Backup SRAM #define CCSRAM_SIZE ( 64 * 1024 ) #define CCSRAM_BASE 0x10000000 #define SRAM_SIZE ( 128 * 1024 ) #define MEM_START_ADDRESS { ( void* )end, (void* )( CCSRAM_BASE ) } #define MEM_END_ADDRESS { ( void* )( SRAM_BASE + SRAM_SIZE - STACK_SIZE_TOTAL - 1 ), (void*)( CCSRAM_BASE + CCSRAM_SIZE - 1 ) } it compiles, and after uploading (via xmodem) the life(32,46) it starts, but crashes: .. -------------------------------- -------------------------------- -------------------------------- Life - generation 5, mem 117.2 kB or with life (34,46): .. ----------------------------------- ----------------------------------- Life - generation 1, mem 120.6 kB Error: [string "xmodem"]:44: attempt to perform arithmetic on field '?' (a boolean value) p. -- Jak co nejlépe přichystat automobil na provoz v nadcházející zimní sezóně? Čtěte speciál Příprava auta na zimu na http://web.volny.cz/data/click.php?id=1292 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
..with bigger life() gc shows nice numbers :), but with following
error: ------------------------------------- ------------------------------------- Life - generation 1, mem 170.4 kB Error: [string "xmodem"]:44: attempt to perform arithmetic on field '?' (a boolean value) or ---------------------------------------- ---------------------------------------- Life - generation 1, mem 167.4 kB Error: [string "xmodem"]:44: attempt to perform arithmetic on field '?' (a boolean value) So the elua takes the table sizes, but there must be something only experts may discover :) p. ----- PŮVODNÍ ZPRÁVA ----- Od: "pito" <[hidden email]> Komu: [hidden email], [hidden email] Předmět: Re: [eLua-dev] stm32f4_-_max_free_mem_/_ram_size Datum: 11.11.2011 - 11:20:55 > So with this and allocator=multiple > > // Allocator data: define your free memory zones > here in two arrays > // (start address and end address) > // The F4 has 196K in total, but it split into 2 > sections: > // RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K > // Major SRAM > // CCMRAM (xrw) : ORIGIN = 0x10000000, LENGTH = > 64K // Backup > SRAM > #define CCSRAM_SIZE ( 64 * 1024 ) > #define CCSRAM_BASE 0x10000000 > #define SRAM_SIZE ( 128 * 1024 ) > #define MEM_START_ADDRESS { ( void* )end, > (void* )( CCSRAM_BASE > ) } > #define MEM_END_ADDRESS { ( void* )( > SRAM_BASE + SRAM_SIZE - > STACK_SIZE_TOTAL - 1 ), (void*)( CCSRAM_BASE + > CCSRAM_SIZE - 1 ) } > > it compiles, and after uploading (via xmodem) the > life(32,46) > it starts, but crashes: > .. > -------------------------------- > -------------------------------- > -------------------------------- > Life - generation 5, mem 117.2 kB > > or with life (34,46): > .. > ----------------------------------- > ----------------------------------- > Life - generation 1, mem 120.6 kB > Error: [string "xmodem"]:44: attempt to perform > arithmetic on field > '?' (a boolean value) > > p. > > > -- > Jak co nejlépe přichystat automobil na provoz v > nadcházející zimní > sezóně? Čtěte speciál Příprava auta na zimu na > http://web.volny.cz/data/click.php?id=1292 > > -- Jak co nejlépe přichystat automobil na provoz v nadcházející zimní sezóně? Čtěte speciál Příprava auta na zimu na http://web.volny.cz/data/click.php?id=1292 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Sooo - I put life(42,46) into /romfs and compiled:
eLua# lua /rom/life.lua Press CTRL+Z to exit Lua .. ------------------------------------------ ------------------------------------------ ------------------------------------------ ------------------------------------------ Life - generation 652, mem 172.1 kB IT WORKS!! GC shows between 120.1-174.0 kB. So the issue is somewhere with xmodem upload.. P. ----- PŮVODNÍ ZPRÁVA ----- Od: "pito" <[hidden email]> Komu: [hidden email], [hidden email] Předmět: Re: [eLua-dev] stm32f4_-_max_free_mem_/_ram_size Datum: 11.11.2011 - 12:01:36 > ..with bigger life() gc shows nice numbers :), but > with following > error: > ------------------------------------- > ------------------------------------- > Life - generation 1, mem 170.4 kB > Error: [string "xmodem"]:44: attempt to perform > arithmetic on field > '?' (a boolean value) > > or > > ---------------------------------------- > ---------------------------------------- > Life - generation 1, mem 167.4 kB > Error: [string "xmodem"]:44: attempt to perform > arithmetic on field > '?' (a boolean value) > > > So the elua takes the table sizes, but there must > be something only > experts may discover :) > p. > > ----- PŮVODNÍ ZPRÁVA ----- > Od: "pito" <[hidden email]> > Komu: [hidden email], > [hidden email] > Předmět: Re: [eLua-dev] > stm32f4_-_max_free_mem_/_ram_size > Datum: 11.11.2011 - 11:20:55 > > > So with this and allocator=multiple > > > > // Allocator data: define your free memory zones > > here in two arrays > > // (start address and end address) > > // The F4 has 196K in total, but it split into 2 > > sections: > > // RAM (xrw) : ORIGIN = 0x20000000, LENGTH = > > 128K > > > // Major SRAM > > // CCMRAM (xrw) : ORIGIN = 0x10000000, LENGTH = > > 64K // Backup > > SRAM > > #define CCSRAM_SIZE ( 64 * 1024 ) > > #define CCSRAM_BASE 0x10000000 > > #define SRAM_SIZE ( 128 * 1024 ) > > #define MEM_START_ADDRESS { ( void* )end, > > (void* )( CCSRAM_BASE > > ) } > > #define MEM_END_ADDRESS { ( void* )( > > SRAM_BASE + SRAM_SIZE - > > STACK_SIZE_TOTAL - 1 ), (void*)( CCSRAM_BASE + > > CCSRAM_SIZE - 1 ) } > > > > it compiles, and after uploading (via xmodem) > > the > > > life(32,46) > > it starts, but crashes: > > .. > > -------------------------------- > > -------------------------------- > > -------------------------------- > > Life - generation 5, mem 117.2 kB > > > > or with life (34,46): > > .. > > ----------------------------------- > > ----------------------------------- > > Life - generation 1, mem 120.6 kB > > Error: [string "xmodem"]:44: attempt to perform > > arithmetic on field > > '?' (a boolean value) > > > > p. > > > > > > -- > > Jak co nejlépe přichystat automobil na provoz v > > nadcházející zimní > > sezóně? Čtěte speciál Příprava auta na zimu na > > http://web.volny.cz/data/click.php?id=1292 > > > > > > > -- > Jak co nejlépe přichystat automobil na provoz v > nadcházející zimní > sezóně? Čtěte speciál Příprava auta na zimu na > http://web.volny.cz/data/click.php?id=1292 > > -- Videokurzy MS Office zdarma! Portál VOLNÝ.cz přináší online výuková videa, která vás rychle, názorně a zábavnou formou naučí ovládat programy Excel, Word a PowerPoint. Seriál najdete na http://web.volny.cz/data/click.php?id=1293 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
So this seems to be the allocator section for stm32f4 (even it has
to be tested by experts): // Allocator data: define your free memory zones here in two arrays // (start address and end address) // The F4 has 196K in total, but it is split into 3 sections: // SRAM (xrw) : ORIGIN = 0x20000000, SIZE = 128K // Major SRAM // CCMDATARAM (xrw) : ORIGIN = 0x10000000, SIZE = 64K // Core Coupled Data SRAM // BKPSRAM, SIZE = 4K // Backup SRAM // #define CCMDATARAM_SIZE ( 64 * 1024 ) #define SRAM_SIZE ( 128 * 1024 ) #define MEM_START_ADDRESS { ( void* )end, (void* )( CCMDATARAM_BASE ) } #define MEM_END_ADDRESS { ( void* )( SRAM_BASE + SRAM_SIZE - STACK_SIZE_TOTAL - 1 ), (void*)( CCMDATARAM_BASE + CCMDATARAM_SIZE - 1 ) } // p. -- Jak co nejlépe přichystat automobil na provoz v nadcházející zimní sezóně? Čtěte speciál Příprava auta na zimu na http://web.volny.cz/data/click.php?id=1292 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
When I increased the stack size (from 2048 to 4096) no issues with
xmodem upload then. The max life size I can run now is LIFE(65,50). GC shows ~150kB in average. p. -- Jak co nejlépe přichystat automobil na provoz v nadcházející zimní sezóně? Čtěte speciál Příprava auta na zimu na http://web.volny.cz/data/click.php?id=1292 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
2011/11/12 pito <[hidden email]> When I increased the stack size (from 2048 to 4096) no issues with Ah, I know this one.No connection with xmodem upload, it has to do with Lua's parser which (for reasons that I have yet to understand) consumes a large ammount of stack on life.lua. This was already discussed on this list.
Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |