Forum Discussion

JensVkb's avatar
JensVkb
Icon for Occasional Contributor rankOccasional Contributor
3 years ago
Solved

Does the onchip flash IP block take physical degradation into account?

To support remote updating of my MAX10M08 device, I'm using the onchip flash IP block to access the CFM to erase sectors and program the new configuration.

From the user manual https://www.intel.com/content/www/us/en/docs/programmable/683180/18-0/user-flash-memory-overview.html I can see the onchip flash IP block will set the Write Failed bit when

  • The burst count is not equal to 1 (parallel) or 32 (serial).
  • The given address is out of range.
  • The sector protection mode or write protection mode of the sector is not clear (the value is not 1'b0)

Similarly, the Erase Failed bit is set when

  • You send an illegal sector number
  • The sector protection mode or write protection mode of the sector is not clear (the value is not 1'b0)

Basically, those error flags are set when interacting wrongly with the IP block from VHDL.

Yet, if my device is to operate for multiple years in possibly harsh conditions, the Flash memory itself can also start to degrade, which could also result in failed Write or Erase operations.

Does the IP block take this into account and also set the Failed bit when the physical memory could not execute the desired operation?

Or should I take care of this myself, by reading back the sector is completely empty and reading back the address I just programmed?

  • Hi FvM,


    Thanks for your sharing. Can't deny that readback and compare will be a good measure to ensure data correctness.


    What I mentioned previously is just the ws (write successful) and es (erase successful) bits will always show '0' (failed) if the physical memory could not execute the Write or Erase operations properly.


    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.


4 Replies

  • ShengN_altera's avatar
    ShengN_altera
    Icon for Super Contributor rankSuper Contributor

    Hi,

    Definitely, the ws (write successful) and es (erase successful) bits will be always '0' if the physical memory could not execute the Write or Erase operations. You may check the functionality from On-Chip Flash submodules altera_onchip_flash_avmm_data_controller.v check image:

    So if physical memory fails to execute the Write or Erase operations, the write_timeout and erase_timeout will be '1'. Therefore, csr_status_w_pass and csr_status_e_pass will be always '0'.

    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.

    • FvM's avatar
      FvM
      Icon for Super Contributor rankSuper Contributor

      Hello,
      don't believe that you can be sure about correct flash content without actually reading it back.


      Firstly, the most likely reason for getting incorrect flash content is data corruption on the transport path. Readback and compare will also reveal this error.


      Secondly, I don't see an indication that write success status guarantees correct data. If you think I'm wrong in this point, please refer to the respective product spec.

      Best regards
      Frank

  • ShengN_altera's avatar
    ShengN_altera
    Icon for Super Contributor rankSuper Contributor

    Hi FvM,


    Thanks for your sharing. Can't deny that readback and compare will be a good measure to ensure data correctness.


    What I mentioned previously is just the ws (write successful) and es (erase successful) bits will always show '0' (failed) if the physical memory could not execute the Write or Erase operations properly.


    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.


  • JensVkb's avatar
    JensVkb
    Icon for Occasional Contributor rankOccasional Contributor

    @FvM and @ShengN_Intel

    Thanks for your answers! Since I only could select 1 as a solution, I just chose the final reply, but both of you helped me out!

    Good to know there is a link with the physical memory and that, as I suspected too, it doesn't hurt to implement a readback after each write operation.