DomBraLV
New ContributorJoined 3 years ago
User Profile
New Contributor
User Widgets
Contributions
Re: Failed driver initialization of Serial Flash Controller II Intel FPGA IP
Hi Sheng, Your suggestion to alter the define ALTERA_EPCQ_CONTROLLER2_DEVICE_ID_DATA_0_REG did not work for me, I'm afraid: And from what I understand, this define is only the offset for the DEVICE_ID_DATA_0 register. When looking into the Register Memory Map (20.2.1. Register Memory Map (intel.com)), though, I find the DEVICE_ID_DATA_0 offset being 0x8 rather than 0x20. If I change the define ALTERA_EPCQ_CONTROLLER2_DEVICE_ID_DATA_0_REG to 0x8 instead of 0x20, the initialization seems to succeed. Yet, this is not the only register where this kind of mismatch occurs between the alter_epcq_controller_2_regs.h and the Register Memory Map: FLASH_MEM_OP is 0x3 on intel.com, yet 0xC in the code; FLASH_CHIP_SELECT is 0x6 on intel.com, yet 0x18 in the code. Apparently, all the registers are left-shifted by 2 bits to what intel.com says they would be. Why is that? So at this point, there are three possibilities, the way I see it: The shifting of the register offsets is incorrect and manually correcting them in the altera_epcq_controller2_regs.h would be a short-term workaround until the root of this behavior is fixed. This would not be ideal, to be honest, since this needs to be done every time the BSP has been generated and can easily be overseen. The success in initializing the flash controller by altering the register offset to 0x8, I described above, was a mere coincidence and the actual problem is, that the initalization state of the register DEVICE_ID_DATA_0, which in this scenario would be correctly addressed by the offset 0x20, is not correct, in that it should not be 0, as altera_epcq_controller2.c, line 589 (see screenshot above) implies. Points 1 and 2 are both incorrect and I am missing something. Any thoughts? Best regards, DominikFailed 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!
