- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Sorry for getting back to you late as this issue is quite complex. Is it possible we know the Quartus version that you are using? We will get back to you shortly.
Thank you.
Regards,
Kelly
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Kelly,
Thanks for the reply, and don't worry, I am well aware of the complexity of the issue.
I'm using Quartus Prime Pro 20.4.0, Build 72 to be specific
If you need any other information, just let me know and I will provide them, too.
Best Regards,
Dominik
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Check this https://www.intel.com/content/www/us/en/support/programmable/support-resources/design-guidance/configuration-support.html under Intel® Supported Configuration Devices - Intel Supported Third Party Configuration Devices:
- Intel Quartus Programmer set the non-volatile configuration register during programming operation. User need to set the register manually if using a third-party programmer.
So probably have to manually make changes to altera_epcq_controller2_regs.h at line 261:
#define ALTERA_EPCQ_CONTROLLER2_DEVICE_ID_DATA_0_REG (0x20)
Best regards,
Sheng
p/s: If any answer from the community or Intel Support are helpful, please feel free to give best answer or rate 4/5 survey.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Sheng,
I am using the Intel Quartus Programmer, so unfortunately, I don't see how this applies to my case.
But still, I'm curious: what changes to said line 261 would you suggest?
Best Regards,
Dominik
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @DomBraLV ,
Probably you may manually change it to register 0x21 so that you'll have the correct sectors of 2048 to succeed initialization at first time:
#define ALTERA_EPCQ_CONTROLLER2_DEVICE_ID_DATA_0_REG (0x21)
Best regards,
Sheng
p/s: If any answer from the community or Intel Support are helpful, please feel free to give best answer or rate 4/5 survey.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @DomBraLV ,
Any further update?
Have your problem being resolved or still need further help on this thread?
Thanks,
Best regards,
Sheng
p/s: If any answer from the community or Intel Support are helpful, please feel free to give best answer or rate 4/5 survey.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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,
Dominik
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Dominik,
Thanks for your input and explanation. Seems like a bug that Intel FPGA Serial Flash Controller II Core Register Memory Map offset stated in document is different with the offset value in the driver code. Let me further confirm with the expert and get back to you soon.
Thanks,
Best regards,
Sheng
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page