I'd like to highlight two issues (and potential fixes) I ran into while interfacing the RA6M5 with an octal flash memory device (ISSI IS25LX256)
r_ospi_status_sub() assumes 4 dummy clock cycles when reading the device status in not in extended SPI mode which may not work for all devices. Here's what I changed:
r_ospi_direct_transfer() assumes the byte order which may be incorrect. In my specific case, I needed the DOPI byte order to be byte0, byte1, byte2, byte3. The driver assumes the order setting to be byte1, byte0, byte3, byte2. I believe that this method needs to check the SPI protocol and the byte order then set it accordingly. Here's what I did in my case:
Thank you for reporting these issues. We agree these settings should be configurable and are planning to make improvements in the upcoming FSP 5.0.0 release.
I'd like to highlight two issues (and potential fixes) I ran into while interfacing the RA6M5 with an octal flash memory device (ISSI IS25LX256)
r_ospi_status_sub()
assumes 4 dummy clock cycles when reading the device status in not in extended SPI mode which may not work for all devices. Here's what I changed:r_ospi_direct_transfer()
assumes the byte order which may be incorrect. In my specific case, I needed the DOPI byte order to be byte0, byte1, byte2, byte3. The driver assumes the order setting to be byte1, byte0, byte3, byte2. I believe that this method needs to check the SPI protocol and the byte order then set it accordingly. Here's what I did in my case: