Reallocating the FlexRAM using values that are not 2 to the power of something

cancel
Showing results for 
Search instead for 
Did you mean: 

Reallocating the FlexRAM using values that are not 2 to the power of something

Jump to solution
241 Views
Gra67
Contributor III

Hi

Has anyone tried to reallocating the FlexRAM using values that are not 2 to the power of something? e.g. values other than: 0x10000, 0x20000, 0x40000 ...

I have an Embedded Artists RT1062 dev board (without the extra SDRAM) and I'd run out of the standard 128KB SRAM_DTC region used for heap and stack.

I followed the example from another post to increase my SRAM_DTC to 256KB and this worked, see post: https://community.nxp.com/t5/i-MX-RT-Knowledge-Base/Reallocating-the-FlexRAM/ta-p/1117649

Towards the end of the post it recommends you choose a FlexRAM configuration that's available via eFuses. I chose one that had the maximum amount of DTC RAM from Table 3 in AN12077: DTC: 448KB, ITC: 0KB, OC:64KB. However when I tried to implement it an assert fires off in board.c:

assert(!(nonCacheStart % size));
assert(size == (uint32_t)(1 << i));

The first assert makes sure the size of the NCACHE_REGION fits an exact number of times into the base address of the NCACHE_REGION memory, which for me is SRAM_DTC (0x20000000).

The second assert makes sure size is something like: 0x10000, 0x20000, 0x40000, 0x80000.

I don't understand why these asserts are here as they contradict Table 3 in application note AN12077.

If I ignore the assert everything works.

I eventually ignored table 3 and moved all the FlexRAM to be DTC, leaving me with 0KB ITC and 512KB in OC RAM. This is the best solution for me, so I'm happy, but concerned I've missed some understanding re the asserts.

Has anyone else had this issue?

Thanks, Graeme

Labels (1)
0 Kudos
1 Solution
172 Views
mjbcswitzerland
Specialist V

Hi Graeme

I think that the second assert should be removed since it effectively stops any RAM sizes that are not 32k, 64k, 128k, 256k or 512k being used, which is more restrictive than the FlexRAM is capable of and so it was presumably an over enthusiastic assert that is basically incorrect.

When setting up, for example, 288k size one needs to set the bank size in the number of 32k block (9) and the memory type sizes (GPR14) to a power of two value. The two asserts are presumably checking that these are both the case but is not possible in this situation since the setting in GPR14 can only be 256k or 512k (so 512k is needed).

I have used most possible FlexRAM software configurations and set the GPR14 value simply to the maximum FlexRAM size since it then doesn't restrict any accesses - since exact values are not always possible - and this simple strategy has proven to be OK for any combination.

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training, solutions to problems or rapid product development requirements

For professionals searching for faster, problem-free Kinetis and i.MX RT 10xx developments the uTasker project holds the key: https://www.utasker.com/iMX/RT1064.html

View solution in original post

0 Kudos
6 Replies
173 Views
mjbcswitzerland
Specialist V

Hi Graeme

I think that the second assert should be removed since it effectively stops any RAM sizes that are not 32k, 64k, 128k, 256k or 512k being used, which is more restrictive than the FlexRAM is capable of and so it was presumably an over enthusiastic assert that is basically incorrect.

When setting up, for example, 288k size one needs to set the bank size in the number of 32k block (9) and the memory type sizes (GPR14) to a power of two value. The two asserts are presumably checking that these are both the case but is not possible in this situation since the setting in GPR14 can only be 256k or 512k (so 512k is needed).

I have used most possible FlexRAM software configurations and set the GPR14 value simply to the maximum FlexRAM size since it then doesn't restrict any accesses - since exact values are not always possible - and this simple strategy has proven to be OK for any combination.

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training, solutions to problems or rapid product development requirements

For professionals searching for faster, problem-free Kinetis and i.MX RT 10xx developments the uTasker project holds the key: https://www.utasker.com/iMX/RT1064.html

View solution in original post

0 Kudos
153 Views
Gra67
Contributor III

Thanks Mark

I thought it must be an incorrect assert, but it's good to have someone else agree rather than just assume.

Regards

Graeme

Tags (1)
0 Kudos
222 Views
crist_xu
NXP Employee
NXP Employee

Hi,

    For rt1060, the block size of the flexram is 32KB, so the total ram size must be a multiple of 32KB, can not be any.

 

Regards,

    Crist

0 Kudos
211 Views
Gra67
Contributor III

Hi Crist

Thanks, but everything I tried was a multiple of 32KB.

Graeme

0 Kudos
191 Views
victorjimenez
NXP TechSupport
NXP TechSupport

Hello Graeme,

I have never seen this issue before. Keep in mind that when reallocating the FlexRAM through software, you can only do this in blocks of 32KB. So implementations like  DTC: 448KB, ITC: 0KB, OC:64KB won't be possible through software, you'll have to do it directly through the fuses. 

The second implementation that you mentioned is correct. You can reallocate all the FlexRAM as DTC without problems. 

Regards,
Victor 

0 Kudos
182 Views
Gra67
Contributor III

Hi Victor

I read that you could reallocate FlexRAM however you want through software (as long as they are multiples of 32KB), but it was better to choose a FlexRAM configuration that's available via eFuses so you have a more permanent option in the future.

All the implementations I tried were multiples of 32KB:

DTC: 448KB, ITC: 0KB, OC:64KB where 448/32=14 and 64/32=2 didn't work

DTC: 512KB, ITC: 0KB, OC:0KB where 512/32=16 did work

Am I missing something obvious?

Regards

Graeme

0 Kudos