MAX V 5M*** and MAX II -- Examine - Verify Failure

[TN-Notebooks]

I have to read out various Max V and MAX II  Chips via examine because the POF files are not available and a CLONE of the chips has to be made.
These chips are frequently used

5M80 5M160 5M240 5M570 

EPM240

on all this Chip  (Other chips or series may also be affected)

the content of the CFM although it is empty cannot be successfully read out and verified

This Errors occurred during the tests on Customer boards.
However, in order to exclude any errors on the customer boards, all tests that now follow were carried out on new original Altera development boards.
This excludes all hardware errors or security features - and we do not need to talk about customer Boards 

it would be an advantage if you had an identical DEV KIT DKDEV5M570ZN at your disposal and could reproduce this test here (possibly another MAX V Dev Kit - since apparently all MAX V show this behavior here).

Quartus 24.1 Lite installed by Installer exe - Full Features including MAX V Support - Windows10

System rebooted

connect by USB original Altera Development Board DEV KIT DKDEV5M570ZN
open Quartus
click on Programmer
Select USB Blaster
Click Add Device
Select Max V
Select 5M570ZF256
Selected is 5M570ZF256 -> confirmed on Chip 5M570ZF256C5N
Select Erase and Start operation
-> Successfully performed

Select Blank Check and Start operation
-> Successfully performed

Select Examine and Start operation
-> Successfully performed

Select Verify and Start operation
-> 209048 Verify Failure on device Number 1
-> 209012 Operation Failed

right click on untitled1.pof and save File
Select Verify UFM and Start operation

-> Successfully performed

Select Verify CFM and Start operation
-> 209048 Verify Failure on device Number 1
-> 209012 Operation Failed

repeated all same Steps on a Additional Development Board 5M570ZT100C5N with exact same Results

Here use the external original Altera USB Blaster Rev C   PL-USB-BLTR-RCN to connect it

I Contacted a Friend in USA who have the Same Boards Avail 

he has repeated these steps on his systems and has also come to the same result / error -- the content of the CFM although it is empty cannot be successfully read out and verified

[TN-Notebooks]

@ Community support  .... can you Help ?

[Fakhrul]

Hi TN-Notebooks,

The behavior you observed, being unable to read out or verify the contents of the CFM (Configuration Flash Memory), is expected and by design.  For security reasons, the CFM, which holds the device’s logic, cannot be read back or cloned using Quartus or any other supported tools, even if the memory is empty. This applies to all MAX II and MAX V devices and is confirmed by Altera/Intel documentation.

Only the UFM (User Flash Memory) area is accessible for read and write operations via JTAG or the logic interface. If you need to duplicate or back up device logic, the original programming file (POF) is required. Without it, the logic configuration cannot be extracted or cloned from the device.

This behavior is normal and expected, not a bug or hardware issue.

For further reference, please see the "Design Security" and "User Flash Memory Programming" sections of the MAX V Device Handbook.

If you have any further questions, please let us know.

Regards,

Fakhrul

[TN-Notebooks]

Hallo Fakhrul

thank you for your response.

The Design Security say that it is possible to protect the CFM if you set the Security BIT  -  

However, conversely the wording of the text of the Handbook also states that it is possible to read the CFM if the security bit is not set.

During the test on the development board, the chip was deleted (as described in the Design Security) and no security bit was set.

copy of the text from the manual:

Design Security  All MAXV devices contain a programmable security bit that controls access to the data programmed into the CFM block. If this bit is programmed, you cannot copy or retrieve the design programming information stored in the CFM block. This feature provides a high-level design security because programmed data within flash memory cells is invisible. You can only reset the security bit that controls this function and other programmed data if the device is erased. The SRAM is also invisible and cannot be accessed regardless of the security bit setting. The security bit does not protect the UFM block data, and the UFM is accessible through JTAG or logic array connections

and

User Flash Memory Programming  The QuartusII software (with the use of .pof, .jam, or .jbc files) supports programming of the UFM block independent of the logic array design pattern stored in the CFM block. This allows updating or reading UFM contents through ISP without altering the current logic array design, or vice versa. By default, these programming files and methods program the entire flash memory contents, which includes the CFM block and UFM contents. The stand-alone embedded Jam STAPL Player and Jam Byte-Code Player provide action commands for programming or reading the entire flash memory (UFM and CFM together) or each independently.

This contradicts your statement

According to this information, you should be able to read and copy the CFM

[TN-Notebooks]

Hallo Fakhrul,

could you please look at this again, because your statement contradicts what is written in the manual.

Regards

Thomas

[FvM]

Hi,
I tried your suggested programming sequence with MAX II EPM570 and could verify the reported problem. It's only happing when reading back the configuration of an erased device, which is IMHO pretty useless.

When the device is programmed with a useful configuration, "examined" .pof image can be verified and reprogrammed without problems unless you set the security bit during programming.

I have no MAX V deviced at hand, but I guess it will show the same problem.

Thus I think, everything is working as expected.

Regards
Frank

[TN-Notebooks]

Hello Frank,

I also experience this behavior with programmed CFM.
The process is exactly as described above.
I read them out, save UFM and CFM and then go to verify and the same error occurs - even with programmed ones without security.
Am I doing something wrong ? 

then my colleague in the USA would make exactly the same mistake - I had not described to him beforehand what and how I do it so that he goes through all the steps by himself
And he has the same error messages as I do, completely independently.

regards Thomas

[FvM]

Cloning programmed MAX II works well for me, don't know what's the problem. Did you try with a newly compiled configuration to avoid problems with copied source?

[TN-Notebooks]

Hello
I only use the programmer . That is why I have documented the complete path I am taking above.

Am I doing something wrong ? is there something missing that I need to do ?

how do you do it in detail?

I found a Youtube video that shows that it should work - just like you say

https://www.youtube.com/watch?v=cw7H8Pn4UK0

I have no original POF files.
I can only read from working chips and then have to write new chips to repair defective devices.

The first error I made would be confirmed by the fact that I carried out the tests with an erased chip.
Here I was probably wrong in thinking that, similar to an EEprom (all FF), data of a CFM can also be read out and compared in the erased state.

I don't yet know why I get an error with a programmed chip on the functioning donor board.

If you set the security bit when programming, is it actually displayed during the examine that the content is protected?

if this would not be displayed then the chips could be protected - although the manufacturer has not yet protected any of the other chips in any way and the security bit is not displayed or the field is never hidden in any examine.

I have to create a own simple POF File for Testing 

[FvM]

Hi,
most likely reason for observed behavior is that you are reading back protected devices. You get no specific info during examine. Only indication is that CFM part of read-back file can't be verified against device. Also .pof content looks similar to read-back of erased device, data after 0xa0 is all 0x00.

Regards
Frank

[TN-Notebooks]

Hello
and first of all thank you for your help and the information.
Based on this information I have tested with a new approach.

I can confirm the following:
1. a blank check is successfully displayed for an empty UFM/CFM
2. a Verify is successfully displayed for an empty UFM without security bit
3. a Verify error is displayed for an empty CFM without a security bit = normal

4. a blank check error is displayed for a loaded CFM without a security bit
5. a Verify successful is displayed for a loaded CFM without a security bit

6. a blank check error is displayed for a loaded CFM with security bit
7. a Verify error is displayed for a loaded CFM with security bit

Conclusion ----- there is no display or information in Quartus  that a security bit is set - or that the CFM is protected by a security bit
You can only recognize the set security bit by the fact that the chip is not blank and that the Verify shows an error after being read out.

In my case, this means:
1: The first error I made is confirmed by the fact that I carried out the tests with an erased chip.
Here I was wrong in thinking that, similar to an EEprom (all FF), data of a CFM can also be read out and compared in the erased state.

2. the board to be repaired has the security bit set on the donor boards. Reading out the donor and repairing the defective boards is therefore impossible and they are electronic waste

Here a display in Quartus that a security bit is set would have been very helpful

Clear indications ( security set ) like cheap eprom software can do and display would have saved a lot of time and I would have expected this from a software as advanced as Quartus.

[Fakhrul]

Hi TN-Notebooks,

Thank you for your feedback.

Quartus intentionally does not display the security bit status, as revealing this information could compromise device security. This approach aligns with standard practices for secure devices.

Best regards,

Fakhrul

[Fakhrul]

As we haven't received a response to our previous notification, this thread will be transitioned to community support. We hope all your concerns have been addressed. If you have any new questions, please feel free to open a new thread to receive support from Intel experts. Otherwise, community users will continue to assist you here. Thank you.