Hi, I observe a strange behavior when I perform a binary read of more than 128KB (almost 140KB) from SD card to external SRAM memory at 0x2800000. Everything works well for the firsts 128KB but from here on 0x2800000 address memory and above are overwritten with wrong data. It really puzzles me.
More hints: - RL-ARM Rev.: V4.12 - 256KB of external SRAM buffer size - FAT16 SD format
IDE-Version: µVision V4.14.4.0 Copyright (C) 2010 KEIL(TM) Tools by ARM
Tool Version Numbers: Toolchain: RealView MDK-ARM Version: 4.14 Toolchain Path: BIN40\ C Compiler: Armcc.Exe V4.1.0.567 Assembler: Armasm.Exe V4.1.0.567 Linker/Locator: ArmLink.Exe V4.1.0.567 Librarian: ArmAr.Exe V4.1.0.567 Hex Converter: FromElf.Exe V4.1.0.567 CPU DLL: SARM.DLL V4.14 Dialog DLL: DARMST9.DLL V1.07 Target DLL: BIN\UL2ARM.DLL V1.64 Dialog DLL: TARMST9.DLL V1.08
Could anybody help me? Thanks in advance, Gaston
Does your external memory pass a memory test for arbitrary patterns for the entire 256K?
Andrew
Andrew, thank you for your response. I've gone back to my code and talked with my colleague about the test you have suggested. We have performed several test with 0x55555555 and 0xAAAAAAAA patterns. All read/write transfers are ok so we decided to going deeper by debugging the application. There, we found that if we write at 0x28000000 with some data, the address 0x28020000 is also written with the same value! As if the memory was dual-mapped. The same happens with consecutive address, for example writing at 0x28000004 implies another write at 0x28020004 with the same value.
This is the reason why the writing of a data block of more than 128KB (0x20000) results in an overlap at the start address + 0x20000. We've checked memory configuration, hardware address lines and everything seems ok. What could be the problem?
Regards, Gaston
You have looked at hw address lines - but have you looked at the decoding of the address lines?
You get aliasing when a memory-mapped device doesn't decode all address lines.
And you haven't told use what processor you have, and what capabilities it has for mapping external and/or internal memory.
Per, it's true. I forgot some important details so here's a summary:
- MCU: STR912FAW44 - IS61LV25616A 256Kx16-bit external memory - Based on AN2647 Application Notes (Using the STR91xFA external memory interface (EMI) Page 6/34 (Figure 2) - EMI configuration:
SCU_AHBPeriphClockConfig(__EMI | __EMI_MEM_CLK, ENABLE); // Enable the clock for EMI SCU_EMIBCLKDivisorConfig(SCU_EMIBCLK_Div1); // BCLK=80Mhz SCU_EMIModeConfig(SCU_EMI_MUX); // EMI mode = Multiplexed SCU_EMIALEConfig(SCU_EMIALE_LEN2, SCU_EMIALE_POLHigh); // ALE length and polarity definition
EMI_DeInit ();
// External Memory, CS1 --------------------------------------------------- // Addresses 0x28000000 to 0x28080000 (512Kb) EMI_StructInit(&EMI_InitStructure); EMI_InitStructure.EMI_Bank_IDCY = 0x0F; EMI_InitStructure.EMI_Bank_WSTRD = 0x1F; EMI_InitStructure.EMI_Bank_WSTWR = 0x1F; EMI_InitStructure.EMI_Bank_WSTROEN = 0x1F; EMI_InitStructure.EMI_Bank_WSTWEN = 0x1F; EMI_InitStructure.EMI_Bank_MemWidth = EMI_Width_HalfWord; EMI_InitStructure.EMI_Bank_WriteProtection = EMI_Bank_NonWriteProtect; EMI_InitStructure.EMI_BurstModeWrite_Selection = EMI_NormalMode; EMI_InitStructure.EMI_AccessWrite_Support = EMI_Write_Asyn; EMI_InitStructure.EMI_AccessRead_Support = EMI_Read_Asyn; EMI_InitStructure.EMI_ByteLane_Selection = EMI_Byte_Select_disabled;
EMI_Init(EMI_Bank1, &EMI_InitStructure);
Hi Gaston,
Like Per is saying - it looks like a decoding problem. There could be several reasons:
- incorrect configuration of the memory controller - incorrect timing - schematic errors - HW problem (shorted traces or pins/balls)
Andrew, Per, I've gone back again to my code and I found that A16 and A17 were not configured as EMI outputs (Alternate 2 function). I've changed the code to add this configuration and now it works as I expected! Thank you very much for your help.