New ContributorFailed driver initialization of Serial Flash Controller II Intel FPGA IP
Hi all,
I'm having a little trouble initializing the driver of a Serial Flash Controller II Intel FPGA IP core within a Nios2 system on a Cyclone 10 (10CX220YF780) FPGA.
The flash device is connected to the FPGA's dedicated Active Serial pins.
In the Platform Designer, I've added the IP core according to its documentation, selected the appropriate configuration device type (in my case a MT25QU01G) and connected the 50 MHz clock, reset, and both the Avalon MM Slaves.
After successfully creating the .sopcinfo and .sof files, I generate a BSP and build the software that will be running on the Nios2.
Here comes the part I'm struggling with:
From my understanding and with my current settings, before my main() function is called, the alt_main() is called which in turn calls alt_sys_init(), that has automatically been created in the BSP project. In there, all the system devices' inititialization functions are called to initialize all of their drivers, and so my altera_epcq_controller2_init() function for the serial flash controller is called as well. But: this function returns early, with return code -19 (or -ERNODEV).
The reason for this, as I found out while debugging into the altera_epcq_controller2_init() function, is a mismatch between the deduced number of sectors and the actual number of sectors of the device. This sector count is derived from a silicon_id that is either read from the flash controller's DEVICE_ID_DATA_0 register, or - if this is empty -, the RDID register:
In my case, the latter is the case and the RDID leads to an silicon_id of 0x20, which later on indicates 1024 sectors, yet there are actually 2048. This leads to a failed size check and eventually a skipped registration of the flash device, which prevents me from using it later on.
Now here's a twist: If I run the same alt_sys_init() (or even only altera_epcq_controller_init()) again in main(), it gets the number of sectors right, because now, the DEVICE_ID_DATA_0 register is not empty any more, but apparently contains the correct data.
This leads me to the question: Is this a bug in the IP core to initialize the DEVICE_ID_DATA_0 register with 0 when I select the MT25QU01G, or am I missing some crucial detail?
Obviously, I would expect the initialization to succeed the first time.
Can anyone shed some light on this matter or has anyone experienced the same issue?
I appreciate any help, thank you!
Hi Sheng,
I have received some information regarding this topic from another end. An acqaintance of mine contacted the Intel support directly and just heard back from them.
Here's the answer he received:
There is a mistake in the Platform Designer for the "Serial Flash Controller II"
The "Serial Flash Controller II" IP does not support external flash such as Micron.
If you refer to the document located here:
https://www.intel.com/content/www/us/en/docs/programmable/683130/22-2/configuration-device-types-85589.html
Somehow there is a bug in the platform designer for the "Serial Flash Controller II" that the drop down list showed other flash option than intended.
The correct IP that the customer should use is the "Generic QUAD Flash Controller II".
If you see the code, there is a shift of 2 bytes to properly read the "memory capacity" byte instead of the device ID.I verified his suggestion to use the "Generic QUAD SPI Controller II" instead. Now it gets initialized automatically in alt_main() like a charm.
Thank you for your effort!
Best regards
Dominik
