TN-Notebooks
Occasional ContributorJoined 5 years ago
User Profile
Occasional Contributor
User Widgets
Contributions
Re: MAX V 5M*** and MAX II -- Examine - Verify Failure
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.Re: MAX V 5M*** and MAX II -- Examine - Verify Failure
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 TestingRe: MAX V 5M*** and MAX II -- Examine - Verify Failure
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 ThomasRe: MAX V 5M*** and MAX II -- Examine - Verify Failure
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 CFMMAX V 5M*** and MAX II -- Examine - Verify Failure
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 verifiedRe: Max V 5M80ZE64C5N examine / Verify Failure still unsolved
Hallo to check the behavior i bought a brand new DK-DEV-5M570ZN Development Kit connection all fine. Erase performed success Blank Check success now examine the erased blank Chip - save the File and now verify of the examined erased/blank chip ........ ok for UFM but Failed for CFM i tried also on several different Synology NAS Systems. affected 10 of 10 ---- ALL as Programmer i use PL-USB-BLTR-RCN on Cable 2006 Altera P06-18025R-00 RoHSRe: Max V 5M80ZE64C5N examine / Verify Failure still unsolved
Hallo, the Versions 18.x up to Version 22.x (21.1 included ) is not useable because it have a other Bug If you Examine you can not save the File and the Software closes by itself . see https://community.intel.com/t5/Intel-Quartus-Prime-Software/saving-the-examined-data-of-Max-V-failed-in-the-Intel-Quartus/m-p/1528737#M80146 This Bug is solved in the Version 23 But the Standalone Programmer should support the MAX V also in Version 23.x ??
