Need a little hint on FMC SDRAM read memory address caused Hard Fault with STM32H7

[Minamiya Natsuki]

Sorry to disturb again ;)

I'm trying to add FMC function to STM32H7 series, right now the FMC function is not implemented by other people  yet.

Basically I just copied and modified FMC related code from arch/arm/stm32f7 to arch/arm/stm32h7.Make some changes in stm32h7's Kconfig file to be able to select FMC in makemenu. And created stm32_extmem.c file (learn from board/stm32746g-disco) in my costom board's src folder , add it to Makefile.

Then I modified apps's hello example to write a float value to external memory and read from it:

#define SDRAM_BANK_ADDR ((uint32_t)(0x70000000))
......

    *(double *)(SDRAM_BANK_ADDR) = o;

    for (count = 0; count < 10000000; count++) {

    };      /* Delay */

    p = *(double *)(SDRAM_BANK_ADDR);

    printf("%d\n",p);

and then Hard Fault happened

up_hardfault: PANIC!!! Hard fault: 40000000

up_assert: Assertion failed at file:armv7-m/up_hardfault.c line: 148

up_registerdump: R0: 00000016 70000000 00989680 00000001 00000000 00000000 00000000 38001e90

up_registerdump: R8: 00000000 00000000 00000000 00000000 00000000 38001e90 0801710d 08017132

up_registerdump: xPSR: 81000000 BASEPRI: 000000f0 CONTROL: 00000000

up_registerdump: EXC_RETURN: ffffffe9

up_dumpstate: sp:         38001d18

up_dumpstate: stack base: 38001ed0

up_dumpstate: stack size: 000007e4

up_stackdump: 38001d00: 38001ed0 38001d18 38001d00 38001d00 38001d18 38001dbc 00000000 00000000

up_stackdump: 38001d20: 38001d28 0800156f 38001d18 380012b0 000007e4 38001ed0 38001d48 08001635

up_stackdump: 38001d40: 00000094 38001d58 00000094 080180e4 38001d58 080024a3 38001d60 00000000

up_stackdump: 38001d60: 38001dbc 00000003 00000007 00000080 f0000001 000000f0 38001d80 08002cc9

up_stackdump: 38001d80: 38001dbc 00000003 38001d90 00000003 00000000 08002469 38001da0 08002447

up_stackdump: 38001da0: 38001dbc 00000003 0000000a 00000000 38001e90 08001ae9 08019f94 38001e90

up_stackdump: 38001dc0: 000000f0 00000000 00000000 00000000 38001e90 00000000 00000000 00000000

up_stackdump: 38001de0: 00000000 ffffffe9 00000000 00000000 00000000 00000000 00000000 00000000

up_stackdump: 38001e00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

up_stackdump: 38001e20: 00000000 00000000 00000016 70000000 00989680 00000001 00000000 0801710d

up_stackdump: 38001e40: 08017132 81000000 00000000 00000000 00000000 00000000 00000000 00000000

up_stackdump: 38001e60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

up_stackdump: 38001e80: 00000000 00000000 00000000 cc000ccc 38001ed4 00000001 9999999a 3fb99999

up_stackdump: 38001ea0: cccccccd 401ccccc 00000000 00000001 38001eb8 08003309 00000000 00000000

up_stackdump: 38001ec0: 380012b0 00000001 00000000 00000000 560ce8ef 38001edc 00000000 6e6f6e3c

Then I use look into 8017132 and find it in arm-none-eabi-objdump -Sd nuttx | vim - . It is somewhere at

    *(double *)(SDRAM_BANK_ADDR) = o;
 8017120:       f04f 41e0       mov.w   r1, #1879048192 ; 0x70000000
 8017124:       e9d7 2304       ldrd    r2, r3, [r7, #16]
 8017128:       e9c1 2300       strd    r2, r3, [r1]
    for (count = 0; count < 10000000; count++) {
 801712c:       2300            movs    r3, #0
 801712e:       61fb            str     r3, [r7, #28]
 8017130:       e002            b.n     8017138 <hello_main+0xf8>
 8017132:       69fb            ldr     r3, [r7, #28]                  <------------- at this place
 8017134:       3301            adds    r3, #1
 8017136:       61fb            str     r3, [r7, #28]
 8017138:       69fb            ldr     r3, [r7, #28]
 801713a:       4a24            ldr     r2, [pc, #144]  ; (80171cc <hello_main+0x18c>)
 801713c:       4293            cmp     r3, r2
 801713e:       dbf8            blt.n   8017132 <hello_main+0xf2>
    };      /* Delay */
    p = *(double *)(SDRAM_BANK_ADDR);
 8017140:       f04f 43e0       mov.w   r3, #1879048192 ; 0x70000000
 8017144:       e9d3 2300       ldrd    r2, r3, [r3]
 8017148:       e9c7 2302       strd    r2, r3, [r7, #8]

I guess the read action caused Hard Fault, I'm not familiar with assembly at all, And I don't know what exactly happened. Then I look into stackdump to find some useful information, those address some are related to GPIO operation, in file arch/arm/src/stm32h7/stm32_gpio.c , like 8001e40 is in void stm32_gpiowrite(uint32_t pinset, bool value) function.

I have a working demo use FMC SDRAM without nuttx (which I can read and write to sdram without problem ), I checked every register about FMC ( printf("base: %lu\n", (unsigned long)getreg32(0x52004000));) before read and write to sdram, compared with the FMC register in the working demo, they are all same. And checked every GPIO pin set server times.

Can anyone gives me some hint? What else I need to check?  Thanks.

[Masayuki Ishikawa]

Hello,

Though I don't have STM32H7 series, it seems that something happened when accessing the loop counter (count variable in C) on the stack in SRAM pointed by $r7 + 0x28. I don't know why the hard fault happened because the counter has already been stored on the stack at 0x8017136 and then loaded at 0x8017138.

To see more detailed info on the hard fault, you can enable CONFIG_DEBUG_HARDFAULT_ALERT.

Thanks,

Masayuki

2019年12月27日(金) 23:42 Minamiya Natsuki <yukihi...@gmail.com>:

--
You received this message because you are subscribed to the Google Groups "NuttX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nuttx/aa9a8207-b481-4afa-8084-f713aaa87195%40googlegroups.com.

[Gregory Nutt]

There is not enough there to provide any advice.

> up_hardfault: PANIC!!! Hard fault: 40000000

40000000 is the value of the hard fault status register.  It is
indicating that a configurable fault occurred.  You need to turn on
hardfault debug as Masayuki Ishikawa suggested.  The it should also
print the contents of the configurable fault status register.  Maybe
that would give you more insight in the type of configurable fault you
are seeing.

I would suspect some delayed bus interference problem due to the
preceding SDRAM write... but I don't really have any idea.  The value of
R3 suggests that this was only the second time through the loop but I
would expect the loop to be fully cached.

I think that is all must come back to the SDRAM configuration in some
way.  Is 0x70000000 the correct base address of SDRAM?

[Gregory Nutt]

> ...  The it should also print the contents of the configurable fault

> status register.  Maybe that would give you more insight in the type
> of configurable fault you are seeing.

If it is an imprecise error, for example, then the instruction at the
exact PC does not reflect the cause of the problem.

While googling for hard fault status, I found this article on debugging
hardfaults: https://interrupt.memfault.com/blog/cortex-m-fault-debug 
Seems well written.

[Minamiya Natsuki]

Thank you for your reply.

According Chip's reference manual, 0x7000000 seems same as 0xC000000, They are all SDRAM1. I also tried 0xC0000000, got same result.

在 2019年12月28日星期六 UTC+8上午8:59:51，patacongo写道：

[Minamiya Natsuki]

Thank you Ishiikawa and your suggestions.

I enabled  CONFIG_DEBUG_HARDFAULT_ALERT and tested again, I'm really confused now.

up_hardfault: Hard Fault:

up_hardfault:   IRQ: 3 regs: 0x38001dbc

up_hardfault:   BASEPRI: 000000f0 PRIMASK: 00000000 IPSR: 00000003 CONTROL: 00000000

up_hardfault:   CFAULTS: 00000400 HFAULTS: 40000000 DFAULTS: 0000000a BFAULTADDR: 00000000 AFAULTS: 00000000

up_hardfault: PANIC!!! Hard fault: 40000000

up_assert: Assertion failed at file:armv7-m/up_hardfault.c line: 148

up_registerdump: R0: 00000016 c0000000 00989680 00000001 00000000 00000000 00000000 38001e90

up_registerdump: R8: 00000000 00000000 00000000 00000000 00000000 38001e90 08016af5 08016b24

up_registerdump: xPSR: 01000000 PRIMASK: 00000000 CONTROL: 00000000

up_registerdump: EXC_RETURN: ffffffe9

up_dumpstate: sp:         38001cf0

up_dumpstate: stack base: 38001ed0

up_dumpstate: stack size: 000007e4

up_stackdump: 38001ce0: 38001ce0 38001ce0 38001cf0 00000400 00000000 00000000 38001d00 0800150b

up_stackdump: 38001d00: 38001cf0 380012b0 000007e4 38001ed0 38001d20 080015c1 00000094 38001d40

up_stackdump: 38001d20: 00000094 08017b84 38001d40 08002421 40000000 0000000a 00000000 00000000

up_stackdump: 38001d40: 38001d48 00000000 38001dbc 00000003 38001d58 000000f0 00000000 00000003

up_stackdump: 38001d60: 00000000 4a240000 08016b22 38001dbc 00000001 38001dbc 38001d80 08002c4d

up_stackdump: 38001d80: 38001dbc 00000003 38001d90 00000003 00000000 08002341 38001da0 0800231f

up_stackdump: 38001da0: 38001dbc 00000003 0000000a 00000000 38001e90 08001a5d 08019a34 38001e90

up_stackdump: 38001dc0: 00000000 00000000 00000000 00000000 38001e90 00000000 00000000 00000000

up_stackdump: 38001de0: 00000000 ffffffe9 00000000 00000000 00000000 00000000 00000000 00000000

up_stackdump: 38001e00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

up_stackdump: 38001e20: 00000000 00000000 00000016 c0000000 00989680 00000001 00000000 08016af5

up_stackdump: 38001e40: 08016b24 01000000 00000000 00000000 00000000 00000000 00000000 00000000

up_stackdump: 38001e60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

up_stackdump: 38001e80: 00000000 00000000 00000000 cc000ccc 38001ed4 00000001 9999999a 3fb99999

up_stackdump: 38001ea0: cccccccd 401ccccc 00000000 00000001 38001eb8 08003259 00000000 00000000

up_stackdump: 38001ec0: 380012b0 00000001 00000000 00000000 560868ef 38001edc 00000000 6e6f6e3c

 I don't know where to start actually.

在 2019年12月27日星期五 UTC+8下午10:42:41，Minamiya Natsuki写道：

[Gregory Nutt]

up_hardfault:   BASEPRI: 000000f0 PRIMASK: 00000000 IPSR: 00000003 CONTROL: 00000000

up_hardfault:   CFAULTS: 00000400 HFAULTS: 40000000 DFAULTS: 0000000a BFAULTADDR: 00000000 AFAULTS: 00000000

The configurable fault register (CFAULTS) is 00000400, which means that you have a bus fault and the bus fault status register (bits 8-15) is 0x04 which, as I suspected is an imprecise error. I gave you a reference before:  https://interrupt.memfault.com/blog/cortex-m-fault-debug

Imprecise Bus Error Debug Tips

Imprecise errors are one of the hardest classes of faults to debug. They result asynchronously to instruction execution flow. This means the registers stacked on exception entry will not point to the code that caused the exception.

Instruction fetches and data loads should always generate synchronous faults for Cortex-M devices and be precise. Conversely, store operations can generate asynchronous faults. This is because writes will sometimes be buffered prior to being flushed to prevent pipeline stalls so the program counter will advance before the actual data store completes.

When debugging an imprecise error, you will want to inspect the code around the area reported by the exception for a store that looks suspicious. If the MCU has support for the ARM Embedded Trace Macrocell (ETM), the history of recently executed instructions can be viewed by some debuggers³.

The error is almost certainly caused by the write of the double type to address 0x70000000.  As that reference says, the write is buffered and the error gets reported asynchronously some time laster.

I would try to debug the imprecise error.  You know that it is an error in the SDRAM controller setup.. but have not idea what the error is caused by exactly.

Greg

[Gregory Nutt]

There is a pretty good memory test at apps/system/ramtest.  I performs a lot of tests.  I would use that ramtest with SDRAM until you get the SDRAM to pass the test.  If the SDRAM passes that test, it is probably configured properly.

[patacongo]

Basically I just copied and modified FMC related code from arch/arm/stm32f7 to arch/arm/stm32h7.Make some changes in stm32h7's Kconfig file to be able to select FMC in makemenu. And created stm32_extmem.c file (learn from board/stm32746g-disco) in my costom board's src folder , add it to Makefile.

Hmmm... I don't see any FMC driver for the STM312F7???  Are you sure that is where you got the FMC code?  The only FMC driver is see is for the STM32 F1,2,3,4, L1:

$ find . -name *fmc*.c
./kinetis/kinetis_cfmconfig.c
./kl/kl_cfmconfig.c
./stm32/stm32_fmc.c

You would also need this logic to enable clocking to the FMC:

stm32f72xx73xx_rcc.c:#ifdef CONFIG_STM32F7_FMC
stm32f72xx73xx_rcc.c:  regval |= RCC_AHB3ENR_FMCEN;
stm32f74xx75xx_rcc.c:#ifdef CONFIG_STM32F7_FMC
stm32f74xx75xx_rcc.c:  regval |= RCC_AHB3ENR_FMCEN;
stm32f76xx77xx_rcc.c:#ifdef CONFIG_STM32F7_FMC
stm32f76xx77xx_rcc.c:  regval |= RCC_AHB3ENR_FMCEN;

and, when you are ready to add it to the heap, you would need the changes from stm32f7/stm32_allocheap.c.  I see FMC references in the stm32F7 DMA code as well.

[Minamiya Natsuki]

There is no FMC code for H7 yet, I am implementing it, I do this by take STM32F7's FMC code as a example.

Right now I am try to debug for read operation, cause as write operation is imprecise error due to cache/buffer, the write error is precise.

But after spending days on it, I still with no luck. Read operation's hard fault is like :

up_hardfault:   IRQ: 3 regs: 0x38001dbc

up_hardfault:   BASEPRI: 000000f0 PRIMASK: 00000000 IPSR: 00000003 CONTROL: 00000000

up_hardfault:   CFAULTS: 00008200 HFAULTS: 40000000 DFAULTS: 0000000b BFAULTADDR: c0000000 AFAULTS: 00000000

up_hardfault: PANIC!!! Hard fault: 40000000

up_assert: Assertion failed at file:armv7-m/up_hardfault.c line: 148

up_registerdump: R0: 00000016 00000002 00989680 c0000000 00000000 00000000 00000000 38001e90

up_registerdump: R8: 00000000 00000000 00000000 00000000 00000000 38001e90 08016545 0801655c

up_registerdump: xPSR: 61000000 PRIMASK: 00000000 CONTROL: 00000000

up_registerdump: EXC_RETURN: ffffffe9

up_dumpstate: sp:         38001cf0

up_dumpstate: stack base: 38001ed0

up_dumpstate: stack size: 000007e4

The CFAULTS indicated bus error, located at c0000000. Of course it is, I just read from it...

在 2019年12月29日星期日 UTC+8上午6:27:59，patacongo写道：

[Gregory Nutt]

> There is no FMC code for H7 yet, I am implementing it, I do this by
> take STM32F7's FMC code as a example.

There is not STM32F7 FMC code in the NuttX repository.  None that I can see.

[Minamiya Natsuki]

There is arch/arm/src/stm32f7/stm32_fmc.h, and boards/arm/stm32f746g-disco/src/stm32_extmem.c

I guess that F7's code style may not good, and stm32's FMC implement code style is better. But H7 is similar with F7, so I wanna learn from F7 code first and later on, after successful read/wite from sdram, I'll fix the code style and make a push request to repo.

在 2019年12月29日星期日 UTC+8上午10:01:35，patacongo写道：

[Minamiya Natsuki]

I'm new to nuttx and not very familiar with embed device. I'm a front end engineer. I just interesting about it.

Maybe I need to get a better logic analyzer to find out if the CLK/address/data line is working.

在 2019年12月29日星期日 UTC+8上午10:09:22，Minamiya Natsuki写道：

[Gregory Nutt]

There is arch/arm/src/stm32f7/stm32_fmc.h, and boards/arm/stm32f746g-disco/src/stm32_extmem.c

There is nothing like arch/arm/src/stm32/stm32_fmc.c, but maybe you can get by without that.

You still probably have to enable FMC clocking in the STM32H7 RCC logic by setting RCC_AHB3ENR_FMCEN

[Minamiya Natsuki]

Yes, STM32F7's FMC code "arch/arm/src/stm32f7/stm32_fmc.h", is similar with "arch/arm/src/stm32/hardware/stm32_fmc.h". and F7 is missing "arch/arm/src/stm32/stm32_fmc.[c|h]".

The author of   stm32f746g-disco  implemented his own FMC code in "boards/arm/stm32f746g-disco/src/stm32_extmem.c"

Yes, I have enabled the AHB3 clocking, as same as "boards/arm/stm32f746g-disco/src/stm32_extmem.c" line 182-186

在 2019年12月29日星期日 UTC+8上午10:16:17，patacongo写道：

[Minamiya Natsuki]

I think the original code I learned from is also cause hard fault

https://groups.google.com/forum/#!topic/nuttx/udX_Cy7uja8

在 2019年12月27日星期五 UTC+8下午10:42:41，Minamiya Natsuki写道：

Sorry to disturb again ;)

[Minamiya Natsuki]

I just figured out.

Turns out in STM32H7, there is a register at FMC_BCR1 named FMCEN, which not exists in STM32F7.

I turned it to 0b01, then I can both  read and write to 0xC0000009.

The FMC part for STM32H7 is almost finished, I'm going to clean up my code and make a push request after tomorrow. 

(No body tells my about FMCEN register need to be 1 with SDRAM, even in Reference Manual. In RM, FMCEN is mentioned with SRAM/NOR/NAND section.)

在 2019年12月27日星期五 UTC+8下午10:42:41，Minamiya Natsuki写道：

Sorry to disturb again ;)

[Minamiya Natsuki]

I means that on the Internet, like google results, nobody mentioned about that.
You guys are very helpful, thanks. And I learned alot.
Maybe the hard fault is telling me about that, just I couldn’t understand. I need learn more about debug.

[Gregory Nutt]

> The FMC part for STM32H7 is almost finished, I'm going to clean up my
> code and make a push request after tomorrow.

That is all great news!  Don't forget that the NuttX repository has
moved to https://github.com/apache/incubator-nuttx so we can no longer
take PRs on the old Bitbucket repositories.  Things are still in flux on
github so response will not be fast.  I am hoping that our response time
will improve after the holidays.  Almost everything is on hold now.

Greg

[Gregory Nutt]

Also, you should consider the RAM test at apps/system/ramtest.  It
performs a very exhaustive test on SDRAM.  If that RAM test passed, then
you can have very good confidence that you SDRAM setup is correct.  But,
in order to use that RAM test on SDRAM, you will have to exclude SDRAM
from the heap.  The RAM test is a destructive test and will trash the
heap is the SDRAM is on the heap.

[Minamiya Natsuki]

Struggle with ramtest now.

I can write up to 0xC2000000 by hand without error, it's a 256Mbit SDRAM.

But I getting random error after exec server times RAM test:

nsh> ramtest c0000000 4000
RAMTest: Marching ones: c0000000 4000
RAMTest: Marching zeroes: c0000000 4000
RAMTest: Pattern test: c0000000 4000 55555555 aaaaaaaa
RAMTest: Pattern test: c0000000 4000 66666666 99999999
RAMTest: Pattern test: c0000000 4000 33333333 cccccccc
RAMTest: Address-in-address test: c0000000 4000
nsh> ramtest c0000000 4000
RAMTest: Marching ones: c0000000 4000
RAMTest: Marching zeroes: c0000000 4000
RAMTest: ERROR: Address 0xc00001a6 Found: efff Expected efff
RAMTest: ERROR: Address 0xc00009a6 Found: ffff Expected efff
RAMTest: ERROR: Address 0xc0000da6 up_assert: Assertion failed at file:mm_heap/mm_free.c line: 94
up_registerdump: R0: 00000001 24000270 0000003f 00000000 00000000 00000000 00000000 38001990
up_registerdump: R8: 00000000 00000000 00000000 00000000 00000000 38001970 0800138d 0800164a

Error address is random from several test results.

I'll dig into it and try to find out what happed.

在 2019年12月30日星期一 UTC+8上午7:00:19，patacongo写道：

[spudaneco]

From the assertion it looks looks you still have the SDRAM in the heap.  Is that correcr?

If trhe SDRAM is in the heap, then the memory manager will also be modifying the memory and the memory manager will crash.

Sent from Samsung tablet.

--
You received this message because you are subscribed to the Google Groups "NuttX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/nuttx/fc721852-5493-431b-8b53-89fbf6db4574%40googlegroups.com.

[Minamiya Natsuki]

No, I don't think SDRAM is in heap, I removed declaration of SDRAM from scripts/flash.ld and scripts/memory.ld, also CONFIG_ARCH_HAVE_HEAP2=n

By the way, the error address is not completely random:

nsh> ramtest c0000000 33554430

RAMTest: Marching ones: c0000000 33554430

RAMTest: ERROR: Address 0xc00001e6 Found: 00e1 Expected 0001

RAMTest: ERROR: Address 0xc0000376 Found: 0071 Expected 0001

RAMTest: ERROR: Address 0xc00005e6 Found: 00e1 Expected 0001

RAMTest: ERROR: Address 0xc0000776 Found: 0071 Expected 0001

RAMTest: ERROR: Address 0xc00009e6 Found: 00e1 Expec$RAMTest: ERR����$808�8876 Fx8: 00$8$RA

在 2019年12月31日星期二 UTC+8下午8:45:26，patacongo写道：

To unsubscribe from this group and stop receiving emails from it, send an email to nu...@googlegroups.com.

[Gregory Nutt]

No, I don't think SDRAM is in heap, I removed declaration of SDRAM from scripts/flash.ld and scripts/memory.ld, also CONFIG_ARCH_HAVE_HEAP2=n

By the way, the error address is not completely random:

nsh> ramtest c0000000 33554430

RAMTest: Marching ones: c0000000 33554430

RAMTest: ERROR: Address 0xc00001e6 Found: 00e1 Expected 0001

RAMTest: ERROR: Address 0xc0000376 Found: 0071 Expected 0001

RAMTest: ERROR: Address 0xc00005e6 Found: 00e1 Expected 0001

RAMTest: ERROR: Address 0xc0000776 Found: 0071 Expected 0001

RAMTest: ERROR: Address 0xc00009e6 Found: 00e1 Expec$RAMTest: ERR����$808�8876 Fx8: 00$8$RA

The RAM test is a very good test.  It generates some really crazy noise patterns.

It looks like if address bit 8=1, bit6=1, bit5=1,bit4=0, bit3=0,bit2=1,bit1=1, and bit0=0 you generate the error.

Also notice that bits 5-6 from the address also appear int the data read, implying that when the data was sampled, the address (or part of of it) was still on the bus.  That would be an SDRAM setup problem. (Actually, you can't tell from this if the error occurred on the read or on the write).

[Minamiya Natsuki]

Now I think it's may be a hardware problem and I'm going to by another same board to test it out.

(Or may be it's a cache/buffer problem. I tried to disable/enable DCACHE, but get same corrupted data).

Every time I run ramtest with large size, I got two error: 

Assertion failed at file:mm_heap/mm_free.c line: 94

Assertion failed at file:mm_heap/mm_free.c line: 87 

So I swap the SDRAM space from 0xc000000 to 0x6000000. As I changed the SDRAM address, is not possible that the SDRAM is in the HEAP. But I still got this error

So I wrote another script (modified hello_main.c):

void write_to_memory(uint8_t value) {
  uint8_t *ptr = 0x60000000;
  for (int i = 0; i < 33554410; i += 1)
  {
    *ptr++ = value;
  }
}


void verify_memory(uint8_t value) {
  uint8_t *ptr = 0x60000000;
  for (int i = 0; i < 33554410; i += 1)
  {
    uint8_t v = *ptr;
    if (v != value) {
      printf("error addr: %08x, data: %ld\n", ptr, *ptr);
    }
    ptr++;
  }
  ptr--;
  printf("last verified addr: %08x, data: %ld\n", ptr, *ptr);
}


int main(int argc, FAR char *argv[])
{
  printf("Hello, World!!\n");
  printf("sizeof uint8: %d\n", sizeof(uint8_t));
  for (int i = 0; i < 255; i++)
  {
    write_to_memory(i);
    verify_memory(i);
  }
  return 0;
}

This code covered nearly all SDRAM space, each loop write a number  to SDRAM, from 0 to 255.Every loop takes 1~2 seconds. And the best result is: 

NuttShell (NSH) NuttX-8.2

nsh> hello

Hello, World!!

sizeof uint8: 1

last verified addr: 61ffffe9, data: 0

last verified addr: 61ffffe9, data: 1

last verified addr: 61ffffe9, data: 2

............. ( no error )

last verified addr: 61ffffe9, data: 16

last verified addr: 61ffffe9, data: 17

last verified addr: 61ffffe9, data: 18

last verified addr: 61ffffe9, data: 19

error addr: 61248266, data: 4

error addr: 61248267, data: 4

error addr: 61248666, data: 4

error addr: 61248667, data: 4

error addr: 61248a66, data: 4

error addr: 61248a67, data: 4

error addr: 61248e66, data: 4

error addr: 61248e67, data: 4

error addr: 61249666, data: 4

error addr: 61249667, data: 4

last verified addr: 61ffffe9, data: 20

last verified addr: 61ffffe9, data: 21

.............. (some errors)

last verified addr: 61ffffe9, data: 135

last verified addr: 61ffffe9, data: 136

last verified addr: 61ffffe9, data: 137

.............. (some errors)

last verified addr: 61ffffe9, data: 253

last verified addr: 61ffffe9, data: 254 

I'll keep trying after the new board arrive.

在 2019年12月31日星期二 UTC+8下午9:38:59，patacongo写道：

[Gregory Nutt]

Now I think it's may be a hardware problem and I'm going to by another same board to test it out.

That is possible, but I would not think likely.  It is also possible that the board design has some noise-related problem.

(Or may be it's a cache/buffer problem. I tried to disable/enable DCACHE, but get same corrupted data).

It is necessary for the SDRAM memory region to be strongly ordered during SDRAM initialization.  You can control whether SDRAM is cacheable or not.

You would think that the effect of data cache, if write buffered would be that possible SDRAM errors would be missed (since the data should always be correct in the data cache).

Every time I run ramtest with large size, I got two error: 

Assertion failed at file:mm_heap/mm_free.c line: 94

Assertion failed at file:mm_heap/mm_free.c line: 87

This means that something has corrupted the heap.  Of course, something related to SDRAM would be suspected in this case.   But since you are certain that the SDRAM is not in the heap, then it is not clear how SDRAM accesses could cause this unless they are interfering with the bus in some odd way or if addressing was being aliased.

However, the normal cause an error like this is because the stack size is insufficient or a bad pointer is being used.  You might try increasing all of the stack sizes in the .config file to see if this goes away.

[Minamiya Natsuki]

Oh, increase stack size Works! You are breathtaking.

And I find if I write twice before verify, the ramtest of full SDRAM can be complete:

write_memory(info, pattern);
write_memory(info, pattern);
verify_memory(info, pattern);

NuttShell (NSH) NuttX-8.2

nsh> ramtest 60000000 33554420

RAMTest: Marching ones: 60000000 33554420

RAMTest: Marching zeroes: 60000000 33554420

RAMTest: Pattern test: 60000000 33554420 55555555 aaaaaaaa

RAMTest: Pattern test: 60000000 33554420 66666666 99999999

RAMTest: Pattern test: 60000000 33554420 33333333 cccccccc

RAMTest: Address-in-address test: 60000000 33554420

I know it's cheating so I'll keep working on it.

在 2020年1月2日星期四 UTC+8上午1:11:58，patacongo写道：

[Minamiya Natsuki]

I asked the boards manufacturer , they said it must enable MPU for SDRAM, or the data will be corrupted. And I confirmed this by toggle MPU for sdram on bare metal ram test script, I can read and write without any problems with MPU is set.

And I confirmed the corruption happened when write to sdram (If not set MPU for SDRAM).

So I think FMC implement ( for sdram ) is done.

在 2020年1月2日星期四 UTC+8上午2:54:21，Minamiya Natsuki写道：