- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page