Posted on June 16, 2017 at 06:27 Thank you for all thevaluable suggestions and comments,
We have resolvedthis issue by Setting RBURST bit in theSDCR Register of SDRAMas per the errata,
https://community.arm.com/cfs-file/__key/communityserver-discussions-components-files/10/18pastedimage1497518039523v3.png
Screenshot- 1
But after the fix we saw that the above fix will can introduce SDRAM bank address corruption
https://community.arm.com/cfs-file/__key/communityserver-discussions-components-files/10/3pastedimage1497518039523v4.png
Screenshot- 2
Can any one suggest the steps to do the Second or third work around mentioned in the Screenshot- 2 without affecting the Previous fix.
/external-link.jspa?url=http%3A%2F%2Fwww.st.com%2Fcontent%2Fccc%2Fresource%2Ftechnical%2Fdocument%2Ferrata_sheet%2F38%2Fe6%2F37%2F64%2F08%2F38%2F45%2F67%2FDM000686pdf%2Ffiles%2FDM000686pdf%2Fjcr%3Acontent%2Ftranslations%2Fen.DM000686pdf
Our queries:
1. What happens if an interrupt occurs during an CPU AHB burst read access to one SDRAM internal bank, and a different SDRAM bank is read from within the interrupt? Will the issue be applicable here? If the issue is applicable, would a write to a dummy SDRAM location in some arbitrary bank at the beginning of the interrupt service routine be a safe work around?
2. Is the issue valid for burst and not burst types of read for the 'second read to another SDRAM internal bank' ?
3. Should we take care of any thing else if there are nested interrupts and there is a chance of burst reads to different banks being interrupted in a nested manner? i.e., say the following occurs:
interrupt-1 interrupts a burst read to SDRAM bank-1 and
in interrupt-1 service routine a burst read to SDRAM bank-2 is interrupted by interrupt-2 and
in interrupt-2 service routine a burst read to SDRAM bank-3 is performed and finally it returns to interrupt-1 service routine and then back to non-interrupt level
4. If we do a dummy write to some fixed SDRAM location after all burst reads that are followed by a read to another SDRAM bank in all interruptible contexts (including lower priority interrupt routines), can we be assured that there will be no corrupted data durung SDRAM read?
5. If consequtive burst reads from a particular SDRAM bank is of size greater than the SDRAM read FIFO (all different addresses), can we be sure that there will be no data in the SDRAM read FIFO that is from a different bank, and thereby the subsequent read to a different SDRAM bank will not be corrupted?
NOTE: The workaround to 'disable the SDRAM read FIFO' cannot be used in our project as our SDRAM uses a 16-bit data interface and due to errata clause 2.5 titled 'Interruption of CPU read burst access to an end of SDRAM row', as a workaround we are forced to enable SDRAM read FIFO.
Regards,
Krishna Prasad
