Infinite loop problem in EwInit()

Question

Hi. I am using a custom board using an STM32H7.

In most cases, this works fine, but on some boards, the EwInit() function gets stuck in an infinite loop while running.

Through debugging, we found that the infinite loop was caused by the FindPrevBestFit() function.

There seems to be an issue with the allocation of heap memory allocated to external SDRAM.

 

/* The following helper function traverses the list of free blocks looking
   for a block with optimal size of at aSize bytes. The search operation 
   starts with the block aBlock. The function returns the found block or 0
   if there is no block matching the search condition. Also, the function
   stops if the actual block lies in front of aStop and returns this block. */
static XMemoryBlock *FindPrevBestFit(long aSize, XMemoryBlock *aBlock,
                                     XMemoryBlock *aStop) {
    XMemoryBlock *foundBlock = 0;
    long foundSize = 0x7FFFFFFFl;

    for (; aBlock > aStop; aBlock = aBlock->Prev)
        if ((aBlock->Size >= aSize) && (aBlock->Size < foundSize)) {
            foundBlock = aBlock;
            foundSize = aBlock->Size;
        }

    return foundBlock ? foundBlock : aBlock;
}

In that function, the value of 'aSize' is 128, the address of 'aBlock' is 0xd0a0d0a0, and the address of 'aStop' is 0x7a007a.

The address of aStop has an address value that is unrelated to the SDRAM(16MB) area, so it gets stuck in an infinite loop.

 

The aStop argument is the value of pool->Separator.

 

I'm not sure why only some boards have issues with using Heap.

Of the 16MB SDRAM, 

I use about 2MB for the display buffer and double buffer,  ( display buffer: 0xD0000000 ~ 0xD012BFFF, double buffer 0xD012C000 ~ 0xD0257FFF )

6MB for temporary space of other data, ( 0xD0A00000 ~ 0xD0FFFFFF )

and the remaining 8MB is used for the Heap memory area. ( 0xD0258000 ~ 0xD0BFFFFF )

Can you tell me what might be causing the problem?

Answer 1

Hello,

according to your description I assume there happens some memory corruption within the memory area managed by the Heap Management.

Most likely the SDRAM is not working properly, the timing is not correctly or the refresh does not work properly => Please ensure that the SDRAM is working correctly by using our SDRAM memory test.

Furthermore, please test that the SDRAM refresh is working properly, by adding a longer wait time between writing the memory pattern and reading the memory pattern.

I hope this helps...

Best regards.

Manfred.

Comments

Thank you for your response.

We have already tested writing to and reading from all areas of SDRAM and have been successful.

Below are the areas of SDRAM that I have set up.
 

[SDRAM TOTAL 16MB]

1. Display buffer : 1024 (width) x 600 (height) x 2 (depth) = 1200 KB

2. Double buffer : 1024 (width) x 600 (height) x 2 (depth) = 1200 KB

3. Heap memory : 16MB - 6MB - 2400KB = 7.65625 MB

4. Temporary data buffer : 6MB

 

For testing, I included the area in Heap memory without using the Temporary data buffer and it works fine.

If you use the temporary data buffer again, the same problem occurs.

 

Q1. Is it possible for the Heap memory to overflow?

Q2. Does the double buffer region have to be at the end of SDRAM?

---

As long as there are no overlapping memory areas, it does not have any impact where you have located the Embedded Wizard memory pool (heap).

This leads me to a new question:

6MB for temporary space of other data, ( 0xD0A00000 ~ 0xD0FFFFFF )

and the remaining 8MB is used for the Heap memory area. ( 0xD0258000 ~ 0xD0BFFFFF )

In case the Heap is from 0xD0258000 up to 0xD0BFFFFF, it will overlap with your temporary space that starts at 0xD0A00000.

Can you double-check your address calculations?

Concerning Q2: It is a recommendation of ST to locate two framebuffers in different memory banks.

Best regards,

Manfred.

---

Sorry. I wrote it wrong. The correct address is 0xD0258000 to (0xD0A00000 - 1).

I don't know the cause, but I fixed it by adjusting the Temporary data buffer area.