Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
21 years ago

Proble opening the /dev/epcs_controller device

Hi all,

My application can not open the /dev/epcs_controller device for reading the EPCS flash.

We do NOT have the probleem during debugging/running inside the NIOS IDE (thus downloading codes onto the board).

However, after we program the application (using the flash programming tool) onto the EPCS flash, our application could not open the EPCS flash device.

The rare thing is that the application CAN run, but can NOT open the mentioned EPCS device!

Hope someone has an answer!

Regards,

Kwok Wong

16 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    originally posted by kwokwong@Jan 5 2005, 09:46 AM

    i would like to call the alt_epcs_flash_* functions directly (thus not using hal).

    but i got link errors: undefined references to these functions.

    i am sure that these functions do exist and are called in alt_sys_init().

    apparently these functions will be linked later in the make process.

    can anyone tell me how to workaround these?

    --- Quote End ---

    Our application has inly a main function (thus not the alt_main function).

    According the NIOS documentation the alt_main functions takes care the initialisation of the HAL drivers.

    However, can I still rely that the HAL drivers got initialised if we put our application on the EPCS flash?

    Or should we provide our our own alt_main() to init the HAL drivers?

    Regards,

    Kwok Wong
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    The reason you're not able to call the alt_epcs_* functions are that they are all declared static (with the exception of alt_epcs_flash_init). This is because they are private to the driver and should not be called directly from your application. You should instead use the HAL flash API.

    The call to alt_epcs_flash_init() will be made for you before main() regardless of how you boot (assuming you do not provide your own implementation of alt_main()). The only reason this would not be the case is if you have selected "small footprint drivers". This option disables the EPCS driver completely.

    If you do want to use the EPCS driver while using "small footprint drivers" then you should define the preprocessor macro ALT_USE_EPCS_FLASH for your system library project.

    If that isn't the cause of the problem, then I'd recommend stepping through the alt_sys_init() function in the debugger. This may reveal while the driver is failing to initialise.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    It seems that the epcs_read_electronic_signature(..) function (return code is -ENODEV) can NOT read a valid 'id' in the alt_sys_init() function, if the application is booted from the EPCS flash.

    Since the application does run well in the debugger, I suspect that maybe the epcs_read_electronic_signature(..) function is called 'too early'.

    Therefore I call the alt_epcs_flash_init(..) function later again in our main function, if the first time that this funcion was called, failed.

    AND IT WORKS.

    Now, I wonder why the first time that alt_epcs_flash_init function was called, failed?

    FYI:

    Our application is to be booted from the EPCS serial flash and the EPCS bootloader copies the application onto RAM and starts the application from there.

    Would someone clarify the above??

    Regards,

    Kwok Wong
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    This is a bug in the bootloader code. Thanks for raising the issue.

    Background: the bootloader code sets the EPCS device chipselect to active state in order to transfer data more quickly. The bug is that upon completion of the transfer, it leaves the chipselect active. The result is that the next EPCS command will not be interpreted correctly. The first EPCS command issued by the EPCS device driver is the Read Electronic Signature command; when that command delivers a bad result, the driver decides that no EPCS device is attached.

    Here's a quick hack to get you running again. I'll submit this bug, with my suggested real fix, to the Nios2 group and let them decide how to handle it.

    Quick hack: issue a "dummy" command to the EPCS, which will have the side effect of reseting the device chipselect to inactive state. Implementation: in the file Nios II Device Drivers/altera_avalon_epcs_flash_controller/HAL/src/altera_avalon_epcs_flash_controller.c, find the lines:

    /* Send the RES command sequence */

    flash->silicon_id =

    epcs_read_electronic_signature(flash->register_base);

    Modify that to this:

    /* Send any dummy command to reset device chipselect */

    flash->silicon_id =

    epcs_read_electronic_signature(flash->register_base);

    /* Send the RES command sequence */

    flash->silicon_id =

    epcs_read_electronic_signature(flash->register_base);

    Rebuild your system library and your application with this change, and you should be able to open your EPCS flash dev from a bootloaded application.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Thank you for clarifying this for me.

    We tested the bug-fix and we have no problem now.

    FYI: since we are also using NIOS-II v1.1 release, we have also to use the bug-fix for the EPCS bootloader.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    had the same problem:

    running software via NIOS-IDE worked, reboot after EPCS programming failed when opening epcs_controller. After patching 'altera_avalon_epcs_flash_controller.c' everything is OK now.

    Thanks Kero Kero Keroppi for your help.

    Mike