MAX 10 - Erase CFM sector - IP states "successful" yet sector not erased

Let do a CFM erase operation from beginning:

1. In one cycle, set:

csr_write <= '1'

csr_address <= '1'

csr_writedata(31 downto 23) <= "111100000" --Write protection off for all sectors (max: 2 ufm, 3 ufm. Your device may not have all of this but it don't broke the program.)

onchip_flash_csr_writedata(22 downto 20) <= sector_erase_addr; -- "100" for image 0, "010" and "011" for image 1 (you have to clear one by one for each sector in image 1)

onchip_flash_csr_writedata(19 downto 0) <= "11111111111111111111"; -- rest default

2. In the next cycle, set:

csr_write <= '0'

And wait 350 ms. (Max sector erase time)

3. If you want to erase image 1, go back to first step and set other sector id.

4. Here, your sector must be cleared. You can check it from erase succesfull flag. If you don't have any configuration in the other image you cannot run the fpga if you power-cycle as you said. You don't have to deal with data interface just for clearing. And if you want to check it is really cleared the sector you should read the sector and if it is all FF's then erasing is succesfull.

I use DE10-Lite board which has same FPGA model as your project for testing your code. But before I use MAX1000 (has 10M08) and 10M04 FPGAs and success the RSU operation (erase, rewrite and switch images). May be you can try different FPGA model as you said.

As comes to "fake" an erase, unfortunately it is impossible. Because when erasing, writing "1" to all bits and you can not change "0" to "1" manually. You can just change "1" to "0". But you can try page erase operation. May be it works.

Sanity check question: is your control register address at 100 because of byte addressing?

I see nothing in your code for checking waitrequest. You have the input signal, but you haven't coded for it. You mention a "busy signal". Is that supposed to be waitrequest? Edit: no, you're talking about the busy states of the IP. Nevermind.

Waitrequest could certainly be your problem. Have you set up Signal Tap yet to test while running in hardware?

As mentioned here (https://www.intel.com/content/www/us/en/docs/programmable/683180/18-0/ufm-sector-erase-operation.html) the maximum sector erase time is 350ms, so you can try adding a delay as a workaround. May be for another reason that if one of the CFM images cannot be erased, FPGA switch to that image and program itself from it. So you must be sure that all 2 images erased successfully.

Is the successful erase status appearing on a read you perform when waitrequest is low? That's the only way to know it's valid.

And what you describe is not the proper implementation of waitrequest in a host. It doesn't have a set pattern. You can issue a read/write command (address & data signals) at any time, but if waitrequest is asserted, you need to continue asserting the command signals until one cycle after waitrequest is deasserted. The command is transferred on that cycle and you deassert the control signals after that point.

Don't really have the time right now to figure out that Signal Tap.

Purely as a test, would the following work?

• just writing 1 clock cycle "disable write protection" of my desired sector ID to the csr_control register;
• the next clock cycle "disable write protection + set sector erase address" of my desired sector ID to the csr_control register; and
• then setting csr_write and csr_read to 0, address to 0 and write data to Z or '1'.
• If I then wait a few seconds and then power-cycle my board, should I then see the sector erased and hence no configuration being present?

Because, as I understand the guide, that's all that really needs to happen to erase a Flash sector. (guide only mentions UFM sectors, but I'm guessing this should work for CFM sectors too). (Agreed, checking busy bit and successful bit and re-enabling write protection are crucial steps going forward. The above is purely as a quick check to just erase the CFM sector)

Extra question: my understanding the guide is correct that to just erase CFM sectors, interaction with the csr interface is enough and indeed no interaction with the data interface is necessary?

@jozephka99 Sorry, didn't see that. It's attached here.

I tried your code and either I cannot properly erase CFM sectors. Idk why it needs further investigation but I haven't face any situation like this. I tried several things like erasing all 5 sectors one by one, increasing erase delay, changing address bits and power cycle via dual boot core but when the fpga restarts I can see that the image has not erased. May be the erase operation cannot work because the core is busy. UFM user guide says: "Note: The IP core only accepts the sector erase address when it is in IDLE state; busy field at status register is 2'b00. If the IP core is busy, it will ignore the sector erase address.". You should check this I think.

Another issue that I noticed that, when I use programmer, I erase all sectors first then only write one of the 2 CFM sections, FPGA works and when I switch the other CFM image with dual boot core, FPGA works from other CFM image that I haven't load to FPGA. I use this techinque before with 10M08 and 10M04 devices and normally it shouldn't switch the other CFM because I erased it. Comes to my mind that even programmer cannot erase the CFMs but I don't sure. An addition to that, for example I switch the other CFM with dual boot core and then erase all sectors with programmer then load only one CFM that the opposite of switched one, The FPGA works from switched CFM image that is also wrong.

@jozephka99 Thanks for trying out my code. I also already tried all options you mentioned there, without any success. You're right, I do not check for the IDLE state of the IP core. However, when I disable the write protect and then put the sector erase, I do see the BUSY state and after a (very) short while, I see the ERASE SUCCESS bit. This would assume the core has accepted the command and thinks it executed successfully?

I can erase sectors with the programmer, so the issue you're describing regarding the programmer, I do not have.

I think I figured out the signal tap, and it showed me the same signals as both the simulation as the ones I route to my LEDs. So it does set "BUSY" and after a (very) short while it sets the "ERASE SUCCESS" bit. Nothing is cleared, however.
To be sure, I'll re-do the signal tap in several configurations later this week to make sure the signals I read out are correct.

Reading the manual over and over, and reading the comments here in the thread, I'm more and more convinced my VHDL code is correct. (Or at least is implementing the necessary steps). So that makes me wonder if it is the development board that is not letting me erase the CFM. So I'll see if somewhere another board is in stock and I can try that one. Or are there some settings that are not mentioned anywhere that must also be set/altered?

In the mean time, any other tips or steps I can try in order to get the CFM erased? Is manually writing 0's to each possible address in the CFM address range in option, to "fake" an erase? (although that will probably take a long time).

Thanks. I just ordered 2 MAX1000 at VHDPlus, so once they arrive, I'll try those.