Dear Renesas team,we are using an RA6M3 in our prototype with a 20 MHz crystal connected to XTAL and EXTAL. I noticed that the write speed to the QSPI flash memory is negatively affected if the XTAL speed is set from 24 MHz to 20 MHz under tab “Clocks” in the configurator in e2Studio. The same flash chip is used on our board as it is utilized on EK-RA6M3, the MX25L25645G. As PCLKA, which is responsible for the QSPI interface, is configured to 120 MHz in both cases, there should be no drawback in write performance. It is also interesting to note that the reading speed is not affected in either case.As I found out, this effect can also be simulated with the EK-RA6M3 (which is known to use a 24 MHz crystal). For this reason, I have included a sample project based on Renesas' FileX sample project for the EK-RA6M3 (FSP version 5.5.0) which can be run on this evaluation board. Two functionalities are provided: 1) flash memory can be erased entirely and 2) write 0 to all flash memory bits.
QSPI_Flash_Write_Time_Deviation_RA6M3.zipThe logged time for erase / write and read is comparable for our prototype with a 20 MHz crystal. It can be reproducibly observed that a 20% reduction in erase / write speed occurs as soon as the XTAL value is changed from 24 MHz to 20 MHz.
24 MHz XTAL setting:Console output on J-Link RTT Viewer:INFO : Erase verification time of QSPI flash memory: 100940 msINFO : Erasing QSPI Flash device successfulINFO : Erase verification time: 2520 msINFO : Writing zero pattern to QSPI flash.INFO : QSPI flash write time: 30070 msINFO : Zero pattern verification time: 2520 ms
20 MHz XTAL setting:Console output on J-Link RTT Viewer:INFO : Erase verification time of QSPI flash memory: 126840 msINFO : Erasing QSPI Flash device successfulINFO : Erase verification time: 2520 msINFO : Writing zero pattern to QSPI flash.INFO : QSPI flash write time: 35520 msINFO : Zero pattern verification time: 2520 msI'm a bit puzzled why this behavior can be provoked with different XTAL frequency settings. Even with a 20 MHz crystal, if the PCLKA frequency remains the same (120 MHz), one should be able to observe roughly the same erase/write speed. But more importantly, what is the solution to the problem? I don't suppose it is correct to leave the frequency setting at 24 MHz in the configurator when actually using a 20 MHz crystal?Thanks in advance!
Hello,
Let me clarify somethings
Does your prototyping board have the same QSPI chip as EK-RA6M3 (MX25L25645G) ?
Is the 1st screenshot from a EK-RA6M3 project, which has a 24MHz main clock oscillator, and the 2nd screenshot a project based on your custom board, which has 20MHz main clock oscillator ?
Sorry for my delayed answer, I am currently on vacation.1. Yes, we use the same QSPI chip as EK-RA6M3 (MX25L25645G), our exact part no. is MX25L25645GM2I-08G.2. The first configuration/screenshot is for an EK-RA6M3 with a 24 MHz oscillator, the second for our custom board with an RA6M3 with a 20 MHz oscillator.Read times stay the same, write/erase times increase with a 20 MHz setting. Due to PLL settings PCLKA speed should be the same (120 MHz) for both scenarios.What's interesting: if the first configuration setting (24 MHz) is used for the board with an ABM10-20.000MHZ-E20-T crystal, write/erase times get better by 20% compared to the 20 MHz setting. Why this works at all is inexplicable to me.I was of the opinion that the XTAL setting must match the actual speed of the connected crystal.
Are you testing with the same project both cases (same QSPI configurations, same Systick timer configuration) ?
After you change the clock configuration from 1st case to 2nd, do you generate project content and build again ?
On my EK-RA6M3 I ran your project and the times are smaller and closer to case 2:
Yes and yes.
I have made further investigations and think the issue can be closed. First, different time values calculated with tx_time_get() were misleading. Periods measured with an external stopwatch revealed that the real execution times remain the same regardless of the XTAL configuration.Even if actual write/erase times are slower in comparison to two tested EK-RA6M3 samples, there is no evidence of a cause dependency on using a crystal with 20 MHz instead of 24 MHz.Furthermore, the measured times are within the regular range according to the data sheet, which is why the observed deviations are probably due to differences between the MX25L25645GM2I-08G / MX25L25645GZNI-08G part variants.
Thanks for testing, your result is interesting, since it is slower than the two EK-RA6M3 boards that I used for comparison.
I think the most accurate way to measure the access time is with a GPT timer instead of using the tx_time_get function.
The deviation between the custom board and EK-RA6M3 could be also because different routing, cable length etc.