cancel
Showing results for 
Search instead for 
Did you mean: 

Problem with STM32F407 RAM

jforrest
Associate
Posted on April 20, 2012 at 09:21

I have recently assembled 6 PCBs with STM32F407IGT6 micros on them.

I seem to be having a problem reading from RAM.

This was first noticed when one of the boards was hard faulting and returning a non-precise bus error.

When this was tracked down through the stack pointer/program counter the problem occurred when data was being sent down USART2.

Instead of looking at 0x40004400 for the status register, the micro appearred to be trying to look at 0x48004400 which of course is outside the register addresses. This didn't happen everytime, just sometimes.

We put a conditional break point just before the register read checking for 0x48004400. When this broke we looked at the disassembly. It had a line:

ldr r0, [r4, #0]

When I looked at the memory location pointed to by r4 the memory said 0x40004400 however the value that ended up in r0 was 0x48004400. An extra bit had been set for no apparent reason.

The following code was then added as the first thing the micros did after initialisation:

// in INTs.

#define MEM_SIZE 2048

volatile uint32_t memtest[MEM_SIZE];

volatile uint32_t mem_errors;

void setMem(uint32_t val)

{

    uint32_t i;

    for (i = 0; i < MEM_SIZE; i++)

    {

        memtest[i] = val;

    }

}

void galTest()

{

    uint32_t testCell;

    setMem(0);

    for (testCell = 0; testCell < MEM_SIZE; testCell++)

    {

        uint32_t compare;

        memtest[testCell] = ~memtest[testCell];

        for (compare = 0; compare < MEM_SIZE; compare++)

        {

            if (compare == testCell)

            {

                continue;

            }

            uint32_t cmpVal = memtest[compare];

            uint32_t cellVal = memtest[testCell];

            if (cmpVal != 0)

            {

                mem_errors++;

            }

            else if (cellVal != ~cmpVal)

            {

                mem_errors++;

            }

        }

        memtest[testCell] = ~memtest[testCell];

    }

}

void doMemTest()

{

    mem_errors = 0;

    gpio_off(&runup1_pin);

    while (1)

    {

        galTest();

        if (mem_errors > 0)

            gpio_on(&runup1_pin);

    }

}

On 2 boards, mem_errors stays 0 for at least half an hour of run time.

On the other 4 boards mem_errors keeps ramping up. Slow on some boards, faster on others.

When debugging on the worst of these boards, if I pause at any point in time and look at memtest, approximately half the values in the array will be zero and half of the values in the array will be 0x08000000. The same bit that was causing the hard fault is set. This appears to be happening when the value is loaded from RAM into a register. Then when the value is stored from the register back into RAM it stays as 0x08000000.

Has anyone seen anything like this? It looks like a problem with the ICs themselves. I even swapped a good IC and a bad IC to make sure it was the micro and not the PCB that was causing the problem.

We are probably just going to buy some more micros, change them over and hope the problem goes away. But if anyone has any good ideas...
21 REPLIES 21
Posted on August 09, 2012 at 17:23

The OP had a 407, I believe Alex got here based on the instruction GNU/GCC was generating that tickles this critical path, and entered the thread with a ''ME TOO'' post.

Given the rather awful search capabilities of this Microsoft forum I think we need to be generally accommodating to the way threads might evolve based on Google/Bing hits, or however people stumble upon them.  Who knows, we might get even more input from people arriving here with similar problems, and get a better understanding about the situations and configurations where this occurs.

Yeah, the forum seem a little slow and crashing again, differently, this last week or so. Seem to relate to when it tries to display new posts as it refreshes the thread view.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Bassett.David
Senior
Posted on September 29, 2012 at 05:23

I suggest you transplant one of the ''bad'' micros into the Discovery board and retest!