Hello,
In the attachment there is an oscilloscope recording of the SEMC control signals for this test.
Ray description:
Hello , we had the same behaviour as you mentionned .. I don't know if you could solve it , but we had a response from NXP who solve it :
We have identified the additional CE low cycles are resulted from the M7 core,
instead of SEMC. M7 divides the whole 4GB memory map into several regions. Please refer to the cortex_m7 user guide. In 0x60000000~0x9FFFFFFF, writing
operations are buffered; several writing instructions can provide single burst to improve the overall performance. You can try configuring the SRAM base address
as 0xA000_0000 to avoid this behavior.
Note, byte enable signals must be used: UB and LB assertion occurs only in one
of the four CE low cycles. Thus, neighboring bytes could be affected during the additional three CE low cycles, if LB and UB are not implemented for the SRAM device
Regards,
Thank you Sebastien,
This was very helpful! Unfortunately adding the LB UB signals is not possible anymore in our HW.
In fact we are migrating our solution towards QSPI communication. According my measurements this is even faster for burst transfers. I could achieve only 4.6 uint16 reads/us with the parallel bus (using DMA). With dual / quad SPI this should go up to 7.5 / 15 uint16 reads / us. I have to add that too, that the DMA can carry out only ~14 transactions / us (tested with memory copy from OCRAM to DTCRAM)
Best Regards,
Viktor
ps.: I discovered recently that the Atmel ATSAME70 generates also an additional CS pulse without WR on 16 bit external memory bus writes.
Hello,
Have You tried "configuring the SRAM base address as 0xA000_0000 to avoid this behavior" ?
Regards,
Yuri.
Hello,
I have just tested it. I can confirm, that when the FPGA is mapped to 0xA0000000, then it behaves as expected. Only one short 16 bit transaction happens for every write, and no extra BL BH signals are required.
Thank you all your help,
Viktor
I did not try the 0xA000_0000 as SRAM base address yet. The software is already rewritten to SPI communication, and it takes several hours now to put the old system together. I will report when I could test it.
Does the IMXRT1020 behaves the same way?
All the best,
Viktor
Hello,
The i.MX RT1020 has the CM7 core, and architecture options, mentioned in cortex_m7 user guide
above, also take place.
Regards,
Yuri.
Hello,
Mostly we use our own libraries for the initialization.
Here is the initialization part of the SEMC:
------------------------------------------
// Enable SEMC
imxrt_set_clock_gate(3, 4, 3); // SEMC clock
imxrt_set_clock_gate(1, 18, 3); // SEMC exsc clock
uint32_t tmp;
SEMC_Type * regs = SEMC;
/* Initialize all BR to zero due to the default base address set. */
for (tmp = 0; tmp < 9; tmp++)
{
regs->BR[tmp] = 0;
}
/* Software reset for SEMC internal logical . */
regs->MCR |= SEMC_MCR_SWRST_MASK;
while (regs->MCR & SEMC_MCR_SWRST_MASK)
{
}
regs->MCR |= 2; // disable
tmp = 0
| (16 << 24) // BTO: bus timeout
| (80 << 16) // CTO: command timeout
| (1 << 1) // disable
;
regs->MCR = tmp;
tmp &= ~2;
regs->MCR = tmp; // enable
tmp = regs->IOCR;
tmp &= ~7;
tmp |= 3; // set A8 to PSRAM CE = 3, NOR CE = 2
regs->IOCR = tmp;
tmp = 0
| (FPGA_BASE_ADDRESS << 0) // BA: base address
| (0 << 1) // MS(5): 1 = 4 kByte (only 11 address bits are used by the FPGA)
| (1 << 0) // VLD: valid
;
regs->BR[6] = tmp; // set the base register for the (P)SRAM
regs->SRAMCR0 = 0
| (15 << 12) // COL(4): Column address bits ??? 0 = 12 Bits
| (0 << 10) // ADVP: ADV polarity, 0 = low active
| (0 << 8) // AM(2): Address Mode, 0 = Address / Data MUX Mode
| (0 << 4) // BL(3): Burst Length, 0 = 1
| (1 << 0) // PS: Port Size, 1 = 16 Bit
;
regs->SRAMCR1 = 0
| (1 << 28) // REH(4): RE high time
| (1 << 24) // REL(4): RE low time
| (1 << 20) // WEH(4): WE high time
| (1 << 16) // WEL(4): WE low time
| (1 << 12) // AH(4): Address hold time
| (1 << 8) // AS(4): Address setup time
| (0 << 4) // CEH(4): CE hold min time
| (0 << 0) // CES(4): CE setup time
;
regs->SRAMCR2 = 0
| (3 << 24) // CEITV(4): CE interval min time
| (0 << 20) // RD(4): read cycle time
| (0 << 16) // LC(4): latency count
| (0 << 12) // AWDH(4): address to write data hold time cycle
| (1 << 8) // TA(4): turnaround time cycle
| (0 << 4) // WDH(4): write data hold time
| (0 << 0) // WDS(4) write data setup time
;
-----------------------------------
The other untouched SEMC registers are left with their default values.
I've checked the assembly of the test code, for the writes it uses single strh instructions.
I hope this helps, but if not, I'm always ready to give more information.
All the best,
Viktor
Hello,
Looks like the byte select signals (LB, UB) must be used for SRAM-like interface
with the SEMC, since four 16-bit write transactions really take place, as You mentioned.
Regards,
Yuri.
Hello Yuri,
Thank you for your answer. Unfortunatelly this bug makes us the parallel bus connection for the FPGA much less attractive.
Is the IMXRT1020 affected too?
Best regards,
Viktor
Hello,
The byte select signals are controlled by the SEMC, therefore the i.MX RT
is not affected.
Regards,
Yuri.
Hello,
Please verify SEMC settings. What is content of the SEMC registers?
It makes sense to generate assembler code of Your snippet to check
what real instructions are issued for writing.
Have a great day,
Yuri
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------