MCUXpresso Heap Usage (FreeRTOS) reporting problem when using Heap 5 memory scheme

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MCUXpresso Heap Usage (FreeRTOS) reporting problem when using Heap 5 memory scheme

Jump to solution
9,781 Views
minibix
Contributor II

Hi,

I'm using the MCUXpresso FreeRTOS SDK and switched over to the Heap 5 memory allocation scheme in order to use both memory regions on the MK22FN1M0VLK12 I'm using (64kB + 64kB).

However, I can no longer accurately analyse how the heap is being used as the Heap Usage table shows blocks that are not part of the heap and it is preventing the green/red bar visualisation from displaying properly.

I am getting a ~500MB block of memory being reported.

How can I fix this?


Thanks

2018-04-05 13_53_47-workspace - Develop - RAPPb_freertos_portable_port.c - MCUXpresso IDE.png

1 Solution
7,486 Views
lpcxpresso_supp
NXP Employee
NXP Employee

As previously stated, we are investigating this issue with the FreeRTOS TAD view. Hopefully we can incorporate a fix in the next IDE release.

Regards,

MCUXpresso IDE Support

View solution in original post

34 Replies
2,232 Views
biafra
Senior Contributor I

Hi Erich,

This is the project without custom code.

Is that what you asked me?

Many thanks

Biafra

2,231 Views
BlackNight
NXP Employee
NXP Employee

Hi Biafra,

I was hoping for something I can compile and run on my side, but this is not the case, as many folders and files are missing. So this does not really help.

Erich

2,227 Views
biafra
Senior Contributor I

Hi BlackNight,

Finally I'm able to reproduce the error!

This is the same project that was displaying correct data in the heap view: the only difference is that this project starts at address 0x10000 (there is a boot loader).

To make it work I inserted the following lines at the beginning of the ResetISR() function (startup_mk66f18.c file) to modify the VBR register to use the correct address of the interrupt vectors (as it was in the previous SDK version).

__asm volatile
(
   "ldr r0, =0xE000ED08\n"
   "ldr r1, =g_pfnVectors\n"
   "str r1, [r0]\n"
   "ldr r2, [r1]\n"
   "msr msp, r2\n"
);

I hope this is useful to reproduce it on your side.

Many thanks,

Biafra

2,227 Views
biafra
Senior Contributor I

Hi Erich,

I just created a new project with the same configuration, but it works as expected: I can see correct data using memory scheme 5.

Many thanks

Biafra

2,232 Views
biafra
Senior Contributor I

Hi Erich,

I'm trying to prepare what you asked for.

Isn't this problem related to the fact that one of the regions is in external RAM?

My configuration is:

static __NOINIT(FLEX_RAM) uint8_t HeapReagion1[ HEAP_REGION1_SIZE ];
static __NOINIT(SRAM_LOWER) uint8_t HeapReagion2[ HEAP_REGION2_SIZE ];
static __NOINIT(EXTRAM) uint8_t HeapReagion3[ HEAP_REGION3_SIZE ];

static const HeapRegion_t xHeapRegions[] =
{
   { HeapReagion1, HEAP_REGION1_SIZE },
   { HeapReagion2, HEAP_REGION2_SIZE },
   { HeapReagion3, HEAP_REGION3_SIZE },
   { NULL, 0 } //Terminates the array
};

EXTRAM is at address 0x90000000

Many thanks

Biafra

2,232 Views
BlackNight
NXP Employee
NXP Employee

Hi Francesco,

would you be able to share that project or files so I can try it on my end? Or at least share your memory configuration so I potentially could replicate this?

Erich

2,232 Views
biafra
Senior Contributor I

Hi Erich,

Sorry, but I can't share the project.

The heap memory configuration is as follows:

Region 1: start address -> 0x14000000, size 0x1000 (K66 internal FLEXRAM)

Region 2: start address -> 0x1FFF0000, size 0xF000 (K66 internal RAM lower bank)

Region 3: start address -> 0x900006A8, size 0x4E000 (external SRAM) (this region size is modified compared to the image I posted)

Many thanks

Biafra

2,232 Views
BlackNight
NXP Employee
NXP Employee

Hi Biafra,

I'm sorry: as I don't have have any K66 and no external SRAM boards, I cannot try your configuration :-(.

Erich

2,232 Views
biafra
Senior Contributor I

Hi Erich,

I think the external SRAM is not needed: in the previous image, in the lower pane, the error is across two different memory blocks that are both internal, one in the lower bank and the other in the upper one.

There is another error (not shown in the image) that is across the upper internal bank and the external SRAM bank.

I don't think the problem is related to the external SRAM, I think it's related simply to the dual banks (heap 5 memory scheme).

Many thanks

Biafra

2,232 Views
lpcxpresso_supp
NXP Employee
NXP Employee

The public release of the next version is expected around late May.

Regards,

MCUXpresso IDE Support

7,487 Views
lpcxpresso_supp
NXP Employee
NXP Employee

As previously stated, we are investigating this issue with the FreeRTOS TAD view. Hopefully we can incorporate a fix in the next IDE release.

Regards,

MCUXpresso IDE Support

2,232 Views
minibix
Contributor II

Great, when's the next IDE release.

2,232 Views
lpcxpresso_supp
NXP Employee
NXP Employee

Thanks for your report. We'll investigate, but I suspect that the FreeRTSO TAD plugin doesn't currently support the use of FreeRTOS's heap5 option (span multiple non adjacent (non-contiguous) memory regions).

Regards,

MCUXpresso IDE Support

2,232 Views
minibix
Contributor II

Thanks.

When do you think you'll get an answer on this please?

I think this feature is important as the MCUXpresso SDK supports all FreeRTOS memory schemes and you'd expect MCUXpresso IDE to do so too.

Otherwise, development slows down.