2017-01-06 05:08 AM
I�m running an unmodified FMC_SDRAM example on 2 different STM32F769I-EVAL boards and am seeing the same failures on both, more details below.
Are there any jumpers or 0-Ohm restores that need to be added or removed?
Has anyone else managed to get it to work?
Note: The Camera module and the LCD are removed, just in case.
Note: The SRAM example works.
Environment
Target Board: STM32F769I_EVAL (MB1219 Rev.B)
Compiler:
System Workbench for STM32 - C/C++ Embedded Development Tools for MCU
Version: 1.11.0.201610101240
Platform:
vagrant-ubuntu-trusty-64 3.13.0-79-generic x86_64
SDRAM Test
Example: STM32Cube_FW_F7_V1.5.1/Projects/STM32F769I_EVAL/Examples/FMC/FMC_SDRAM
4 different variations:
a) Running Unmodified
Doesn�t work, all values in the rxBuffer are the same and an unexpected value:
Expected:
Hex:0xa244250f
Binary:10100010010001000010010100001111
Actual:
Hex:0xa244350f
Binary:10100010010001000011010100001111
b) Sanity test
For sanity testing I changed the example to write/read to/from internal RAM instead of SDRAM, this works ok.
c) Alternate value
Writing 0x00000000 results in an 0x0fe followed by 0xff�s being read back in 'rxBuffer'
d) Alternate offset
I changed the WRITE_READ_ADDR from the default of 0x0800 to 0x0000 and this seems to work, but is worrying as the SDRAM is much larger than 2k so should of worked at 0x0800
SRAM Test:
This works ok: ~/STM32Cube/Repository/STM32Cube_FW_F7_V1.5.1/Projects/STM32F769I_EVAL/Examples/FMC/FMC_SRAM
#stm32f7 #sdram #fmc #stm32f769i-eval2017-01-06 06:40 AM
I changed the WRITE_ADDR (offset) to 0x0 (i.e. start at 0xc0000000) and the test values start at 0 and are increment by 1 for each offset.
Using the debugger I am seeing the memory dump below (in System Workbench), which is promising, but why the red ??'s ?
2017-01-06 12:32 PM
I'd probably look at what's going on with PE15 (D12), and SB57.
Sorry not a board I have.
2017-01-16 07:48 AM
Thanks Clive,
It was a combination of a short on D12 and also the CubeMX project remapping the SDRAM Write line from PH5 to PC0 (as well as a couple of other pins)
The cause of the pin remap was either due to fat fingers on the 'Pinout' and/or 'Pin Config' window in CubeMX and/or not electing 'Keep Pin Assignments' - A PICNIC error either way.