We currently have a prototype board with an RT1052 interfaced with a Cyclone FPGA. We have connected SEMC_DATA00-15 (16-bit address/data muxed), SEMC_DM0 (LB# / BE#), SEMC_ADDR08 (CE#), SEMC_ADDR11 (WE#), SEMC_ADDR12 (OE#), and SEMC_BA1 (ADV#) from the RT1052 over to the Cyclone. Our intent is to create an 8-bit data bus (D7-D0) with a 64 KB address space (A15-A0), similar to a previous implementation using a Kinetis K20 and a Cyclone; in the case of the Kinetis, the bus was not multiplexed.
I have selected all the appropriate GPIO mux settings in the Config Tool. I have created the appropriate mapping in the MPU:
/* Region 11 setting: Memory with Device type, not shareable, non-cacheable */
MPU->RBAR = ARM_MPU_RBAR(11, 0xA8000000);
MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 2, 0, 0, 0, 0, ARM_MPU_REGION_SIZE_64KB);
And I have added the appropriate initialization code (with deeply relaxed timings for testing):
void Board::InitFpgaBus(void) {
semc_config_t semc_config;
semc_sram_config_t sram_config;
uint32_t src_clock_hz = CLOCK_GetFreq(kCLOCK_SemcClk);
memset(&semc_config, 0, sizeof(semc_config));
memset(&sram_config, 0, sizeof(sram_config));
/* Initialize SEMC. */
SEMC_GetDefaultConfig(&semc_config);
semc_config.dqsMode = kSEMC_Loopbackdqspad; /* For more accurate timing. */
SEMC_Init(SEMC, &semc_config);
/* Configure SRAM. */
sram_config.cePinMux = kSEMC_MUXA8; // CS* on SEMC_A8
sram_config.addr27 = kSEMC_MORA27_NONE; // A27 unused
sram_config.address = FpgaMem::kBaseAddress; // 0xA8000000
sram_config.memsize_kbytes = FpgaMem::kLength; // 64 KB
sram_config.addrPortWidth = 16; // A0 - A15 in use
sram_config.advActivePolarity = kSEMC_AdvActiveHigh; // ALE = active high
sram_config.addrMode = kSEMC_AddrDataMux; // A/D multiplexed
sram_config.burstLen = kSEMC_Nor_BurstLen1; // No burst transfers
sram_config.portSize = kSEMC_PortSize8Bit; // 8-bit data bus
sram_config.tCeSetup_Ns = 100u;
sram_config.tCeHold_Ns = 100u;
sram_config.tCeInterval_Ns = 100u;
sram_config.tAddrSetup_Ns = 100u;
sram_config.tAddrHold_Ns = 100u;
sram_config.tWeLow_Ns = 100u;
sram_config.tWeHigh_Ns = 100u;
sram_config.tReLow_Ns = 100u;
sram_config.tReHigh_Ns = 100u;
sram_config.tTurnAround_Ns = 100u;
sram_config.tAddr2WriteHold_Ns = 100u;
auto result = SEMC_ConfigureSRAMWithChipSelection(SEMC, kSEMC_SRAM_CS0,
&sram_config, src_clock_hz);
assert (kStatus_Success == result);
}
The issue is that when we try to do a read (or write) from address 0, or address 0x2400, or any other, the upper 8 bits stay high:
This image shows two 8-bit bus accesses to consecutive addresses (i.e. a 16-bit read). If I put a scope on one of the upper address lines (say, A13), the line does not toggle at all; it stays 1 continuously. However, if I instead set the port size to 16 bits, we do see A13 toggle, indicating that the RT1050 is driving the bus line. Problem is, we don't want a 16-bit data bus (port size), we want an 8-bit data bus.
Here's my basic question -- does the RT1050 support a (multiplexed) 8-bit data bus with a 16-bit address bus? It seems that the RT1050 doesn't drive the high address byte (A8-A15) to SEMC_DATA08-15 even when those pins are selected in the GPIO mux. Does setting the port size to 8-bit also restrict us to an 8-bit address bus?
One thing that I was nervous about... On page 1409, the reference manual says "NOR Flash and SRAM interface -- Supports both 8-bit and 16-bit modes", yet on page 1415, it states “Supports 16 bit mode” for both NOR Flash and SRAM modes, while stating “Supports 8/16 bit modes” for NAND and 8080 display interface modes. So now I'm unsure as to whether a proper 8-bit mode is even supported.
Can you provide any clarification on this? Thanks.
David R.
Solved! Go to Solution.
Hi @dmarks_ls ,
Just came here to say I'm extremely glad to have found this post when starting to implement our 8-bit SEMC SRAM design. It would have been an enormous struggle figuring out why the address pins didn't line up in 8-bit mode. Thankfully for me, I only needed 17 address pins, so that issue was not a problem for us.
However, it is quite unacceptable that the documentation does not describe these issues. It is only by chance that I found this post, created just one month prior to our design of the same type!
Hi @dmarks_ls ,
Hi Jing,
If I'm understanding your reply correctly, you're stating that if I set the port size to 8-bit (SRAMCR0.PS == 0), then I need to use SEMC_ADDR[7:0] instead of SEMC_DATA[15:8] for the high-order address bus bits. I guess my question now is, why is this not documented in the Reference Manual? Table 25-6 "SEMC Pin Mux Overview" provides no indication of this arrangement. If we had known about this arrangement, we could have designed our first prototype board correctly. Thanks.
David R.
Hi @dmarks_ls ,
Yes, this is not documented in the RM. I'm sorry for that. I've reported this issue to product team.
Regards,
Jing
Thank you for confirming the issue.
David R.