• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 79 subscribers
  • Views 566 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

running short on memory

viney chaddha1
Expert 1280 points
Other Parts Discussed in Thread: MSP430F5529

Hi,

I was trying to do a 1024 point  FFT on the MSP430F5529, in order to conserve the computation time I fed in the Twiddle Factor real and complex as a LUT and defined that array as a constant. But when Using Pointer to it I trying to use that as a variable that would reside on RAM rather than ROM but when i do that i see that my ROM is getting used up and falls short on memory example of the code given below:

const short Twiddle_Complex_40[512] = {

		0,	0,	0,	0,	0,	0,	0,	0,	16384,	16384,	16384,	16384,	-16384,	-16384,	-16384,	-16384,
		-11585,	-11585,	-11585,	-11585,	11585,	11585,	11585,	11585,	-11585,	-11585,	-11585,	-11585,	11585,	11585,	11585,	11585,
		15137,	15137,	15137,	15137,	-15137,	-15137,	-15137,	-15137,	-6270,	-6270,	-6270,	-6270,	6270,	6270,	6270,	6270,
		-6270,	-6270,	-6270,	-6270,	6270,	6270,	6270,	6270,	15137,	15137,	15137,	15137,	-15137,	-15137,	-15137,	-15137,
		13623,	13623,	13623,	13623,	-13623,	-13623,	-13623,	-13623,	9102,	9102,	9102,	9102,	-9102,	-9102,	-9102,	-9102,
		-16069,	-16069,	-16069,	-16069,	16069,	16069,	16069,	16069,	3196,	3196,	3196,	3196,	-3196,	-3196,	-3196,	-3196,
		3196,	3196,	3196,	3196,	-3196,	-3196,	-3196,	-3196,	-16069,	-16069,	-16069,	-16069,	16069,	16069,	16069,	16069,
		9102,	9102,	9102,	9102,	-9102,	-9102,	-9102,	-9102,	13623,	13623,	13623,	13623,	-13623,	-13623,	-13623,	-13623,
		7723,	7723,	7723,	7723,	-7723,	-7723,	-7723,	-7723,	14449,	14449,	14449,	14449,	-14449,	-14449,	-14449,	-14449,
		-15679,	-15679,	-15679,	-15679,	15679,	15679,	15679,	15679,	-4756,	-4756,	-4756,	-4756,	4756,	4756,	4756,	4756,
		10394,	10394,	10394,	10394,	-10394,	-10394,	-10394,	-10394,	-12665,	-12665,	-12665,	-12665,	12665,	12665,	12665,	12665,
		1606,	1606,	1606,	1606,	-1606,	-1606,	-1606,	-1606,	16305,	16305,	16305,	16305,	-16305,	-16305,	-16305,	-16305,
		16305,	16305,	16305,	16305,	-16305,	-16305,	-16305,	-16305,	1606,	1606,	1606,	1606,	-1606,	-1606,	-1606,	-1606,
		-12665,	-12665,	-12665,	-12665,	12665,	12665,	12665,	12665,	10394,	10394,	10394,	10394,	-10394,	-10394,	-10394,	-10394,
		-4756,	-4756,	-4756,	-4756,	4756,	4756,	4756,	4756,	-15679,	-15679,	-15679,	-15679,	15679,	15679,	15679,	15679,
		14449,	14449,	14449,	14449,	-14449,	-14449,	-14449,	-14449,	7723,	7723,	7723,	7723,	-7723,	-7723,	-7723,	-7723,
		3981,	3981,	3981,	3981,	-3981,	-3981,	-3981,	-3981,	15893,	15893,	15893,	15893,	-15893,	-15893,	-15893,	-15893,
		-14053,	-14053,	-14053,	-14053,	14053,	14053,	14053,	14053,	-8423,	-8423,	-8423,	-8423,	8423,	8423,	8423,	8423,
		13160,	13160,	13160,	13160,	-13160,	-13160,	-13160,	-13160,	-9760,	-9760,	-9760,	-9760,	9760,	9760,	9760,	9760,
		-2404,	-2404,	-2404,	-2404,	2404,	2404,	2404,	2404,	16207,	16207,	16207,	16207,	-16207,	-16207,	-16207,	-16207,
		15426,	15426,	15426,	15426,	-15426,	-15426,	-15426,	-15426,	5520,	5520,	5520,	5520,	-5520,	-5520,	-5520,	-5520,
		-14811,	-14811,	-14811,	-14811,	14811,	14811,	14811,	14811,	7005,	7005,	7005,	7005,	-7005,	-7005,	-7005,	-7005,
		-804,	-804,	-804,	-804,	804,	804,	804,	804,	-16364,	-16364,	-16364,	-16364,	16364,	16364,	16364,	16364,
		12140,	12140,	12140,	12140,	-12140,	-12140,	-12140,	-12140,	11003,	11003,	11003,	11003,	-11003,	-11003,	-11003,	-11003,
		11003,	11003,	11003,	11003,	-11003,	-11003,	-11003,	-11003,	12140,	12140,	12140,	12140,	-12140,	-12140,	-12140,	-12140,
		-16364,	-16364,	-16364,	-16364,	16364,	16364,	16364,	16364,	-804,	-804,	-804,	-804,	804,	804,	804,	804,
		7005,	7005,	7005,	7005,	-7005,	-7005,	-7005,	-7005,	-14811,	-14811,	-14811,	-14811,	14811,	14811,	14811,	14811,
		5520,	5520,	5520,	5520,	-5520,	-5520,	-5520,	-5520,	15426,	15426,	15426,	15426,	-15426,	-15426,	-15426,	-15426,
		16207,	16207,	16207,	16207,	-16207,	-16207,	-16207,	-16207,	-2404,	-2404,	-2404,	-2404,	2404,	2404,	2404,	2404,
		-9760,	-9760,	-9760,	-9760,	9760,	9760,	9760,	9760,	13160,	13160,	13160,	13160,	-13160,	-13160,	-13160,	-13160,
		-8423,	-8423,	-8423,	-8423,	8423,	8423,	8423,	8423,	-14053,	-14053,	-14053,	-14053,	14053,	14053,	14053,	14053,
		15893,	15893,	15893,	15893,	-15893,	-15893,	-15893,	-15893,	3981,	3981,	3981,	3981,	-3981,	-3981,	-3981,	-3981,

};

FFT_Calculation_Real((short*)Twiddle_Real_15, (short*)&FFTReal_Result);

if I comment out the function call the compilation is not an issue but when i do it with function I get error 10099 - memory allocation error. 

There are 80 0f such data blocks and 40 calls to the function.

Need desperate help.

Regards

Viney Chaddha

  • 0
    Expert 1400 points

    You should check the linker script for your device. Often they put the .const section in ROM. Not sure if its done so that the const memory is actually read-only, or if its or memory optimization, but since that assumption is not working for you, you could change it. Did you try removing the const, and/or making it static? 

  • 0 in reply to Chris Karaplis
    Guru 58965 points
    At least in principle, a "Look up Table" only needs to be "looked" at. That is, it only needs to be "read" at run-time. Thus it can be stored in Flash.

    But, should you choose to do so, you could store LUT in RAM too. The chip has far less RAM as compared with Flash; and anything stored in RAM will be destroyed when power goes down. Thus I cannot see the reason to store LUT in RAN.

    I am not familiar with c, especially the c in CCS. It sounds like you end-up with using both Flash and RAM for the same LUT in duplicate. Is that the case?
  • 0 in reply to old_cow_yellow
    Expert 1280 points

    The look-up table is being stored in flash when defined with a constant type, I have checked the CMD file for that. My issue is not that. Infact i would like to use the LUT with pointers and that too are getting defined as const type and hence I am falling short of memory. In case I do not use the LUT at all in the program but let them be there I am not facing any issue of memory at all. Hence my question is how to have the following situation:

    Let the look up table be a constant and reside in the ROM and use pointers thtare stored in the RAM so that ROM is not used again for the pointers. 

    Atleast that is what I am thinking that the poiters too are getting stored in ROM and hence the need for memory is doubling - I may be wrong there but do not know how to confirm either way.

    Regards

    Viney Chaddha

  • 0 in reply to viney chaddha1
    Expert 1280 points

    Hi,

    I understood - the compiler is ignoring the array and not storing it in the flash if that is not used anywhere in the program. When i use the array in the program then the array is stored in the flash.

    Now my question is as follows:

    MSP430F5529 has two flash regions - FLASH (origin 0x4400 - length 0xBB80) and FLASH2 origin 0x10000 - length 0x14400)

    cmd file has the following line:

    .const      : {} > FLASH | FLASH2

    hence the data is attempted to be store in FLASH region first and if does not fit the FLASH2 is attempted. Since the data is larger than FLASH2 region the error is displayed.

    A go around this would be to force the compiler to use FLASH region for 2 arrays of 1024 bytes each (total number of arrays that I am using for FFT is 40) - so I am storing 38 of them in FLASH2 region and 2 of them in FLASH region by using  #pragma  LOCATION (  X, address ) and the program gets compiled as I have some memory left in FLASH region.

    QUESTION: For the address can I assume thet the .text and any other data would use continuous memory locations? For example

    if the other data and text in FLASH total to 22404 bytes and the origin of FLASH is 0x4400 can I safely assume that I could force the storage at the following locations:

    Array 1 at 0x9B84

    &

    Array 2 at 0x9F84

    Regards

    Viney Chaddha

  • 0 in reply to viney chaddha1
    Expert 1400 points

    Ok thanks for that clarification, I understand what is happening now. Its makes sense the linker will not allow you traverse a region boundary. Your proposed solution may work, but you have to be careful with assumptions like that. Yes, typically if in the linker script you have two contiguous sections defined in one region, they will be back to back. But there is alignment you have to consider. I believe each section and region has to be 2 byte aligned, so in your case, this should work. However, if you change anything, you may push it out of alignment, or it may not fit at all. If you want to take that approach, I recommend you create two new sections, one in FLASH and the other in FLASH2, Set them to have a known size as per your design. Then position your arrays at those respective sections. That way, if your .text or .data sections change, they will not affect the address of the arrays. You will have effectively forced the address of the arrays.

**Attention** This is a public forum