1e - Error Secure Flash Function Is Not Supported On This File

[Lynn Hepler]

Hi!
Sorry if my English is not the best, I am using Google Translate.

I have an MSI CX41. That I previously made modified BIOS to unlock all options, they worked perfectly. The detail is that all these modified BIOS were made with a previous version (402 according to the MSI page) which was Legacy BIOS

I was curious to install Stock UEFI BIOS (50J) and was able to upgrade from Legacy to UEFI amazingly, but with the 50J I cannot upgrade the modified BIOS based on it. It always throws the error "18 - Error: Secure Flash Rom Verify Fail". (Image attached to publication)

It should be noted that if I try to flash the Stock 50J BIOS if I can do it without problems, likewise the Stock 60H BIOS of the MSI CR41 (Same computer, but without dedicated GPU) I can flash it without problems. But when trying to flash some modification of the 50J or 60H they all throw the same error.

Also, I cannot downgrade to 402 as I get the error: "1e - Error: Secure Flash feature does not support this file."

All this I am doing from AFUWIN with the option "Program all the blocks" and "Do not check Rom ID". (Image attached to Post) I have not tried AFUDOS or AFUEFI because I do not know how to use them, I have tried it before but I do not get any results.

Any solution to this? Thanks in advance

1e - error secure flash function is not supported on this file

Download File ————— https://8budimonsi.blogspot.com/?tgs=2zU7wi

I did the modifications of the biosreg.bin in the AMIBCP, I did the command in the FPT and it flashed without problems. I already have the unlocked options I wanted. Thank you!

Now I want to do something else, but I will do another post so as not to saturate this one.

I hope this message finds you well. I'm currently working on a project based on the STM32U575ZIT6 microcontroller and have successfully read and written to the flash memory with TrustZone disabled. Now, I am looking to enable TrustZone and perform read and write operations within the secure flash memory zone.

I was wondering if anyone could provide guidance or share information on how to read and write on the secure flash memory on the STM32U575ZIT6 and if there's a way to determine the address range of the secure flash memory. Any insights or advice on this matter would be greatly appreciated.

Thank you for your detailed explanation and guidance. I appreciate your assistance in addressing the concerns related to the flash base address and the use of TrustZone. The information you provided, including the reference to the mapping in the reference manual and the example in the CubeFW, is valuable and will be helpful in resolving the issue.

I tried to use the Flash API on a TMX320F28377D DSP. Fapi_getBankSectors returns all the information about the flash of the device. When I try to erase Flash E, I call Fapi_setActiveFlashBank with bank0 as the argument and I get Fapi_Error_OtpChecksumMismatch. I never used the OTP so I don't understand why I get that. Are there registers or memory regions I can look at to know a bit more details about why I get this error?

Yes Flash wait states are correctly configured but, I know I had a problem with this yesterday in my code. For an unknown reason, the predefined symbol _FLASH wasn't interpreted correctly in the code so InitFlashBank0 wasn't called and I executed my code anyway and used the Flash API probably. Could that have caused this?

I am attempting to use UniFlash to configure the DCSM for the first time and I must being doing something wrong because after turning on the security I cannot reprogram or connect to the target even with the password values loaded. My error is probably something simple but before I brick another board I wanted to get feedback on my usage of the tool to minimize the number of boards I go through.

My goal is to turn on the DCSM in CPU1 with all flash sections and ram secured under zone 1. I am using the first zone block so I am leaving the link pointers all Fs. I am not attempting the exe only protection at this time and don't need the secure CRC generation feature. I am leaving the boot options/pins at defaults/boot to flash.

My understanding is that once the DCSM zone security is turned on you can still use UniFlash to re-program the part if you have the correct password values loaded and execute the password match flow properly (which I am assuming UniFlash can do if the proper password values are loaded and clicking the Unlock button).

Create a .hex file from my .out file using hex2000. The created hex file does not have any OTP configuration linked in. I am looking to eventually do that following the Blinky with DCSM example project but first I wanted to figure out a basic method using UniFlash. I don't think this matters but my hex2000 command line is: hex2000.exe -romwidth=16 -memwidth=16 -i "%REL_PATH%Release\Production.out" -o "%REL_PATH%ProgrammingFiles\Production.hex"

After doing the above sequence I cycle power on the target and the go to the "Settings & Utilities -> C28xx_CPU1" page. Then I scroll down to the CSMPSWD section and click the unlock button. I am assuming this is the button that would execute the password match flow and unsecure the target so I an reprogram the board. When I hit the unlock button I get and error: " [ERROR] C28xx_CPU1: Error connecting to the target: (Error -1156 @ 0x0) Device may be operating in low-power mode. Do you want to bring it out of this mode? Choose 'Yes' to force the device to wake up and retry the operation. Choose 'No' to retry the operation without waking the device. (Emulation package 8.2.0.00004)"

Blow is the UniFlash console output of the above sequence that leads to the error. In the sequence below I programmed the part twice to confirm the image was not programming OTP as I had previously copied over the Blinky with DCSM example files to experiment with.

I have also tried only programming the password values, password lock, grabram, and grabsect values using the UniFlash buttons for each of those fields independently and leaving all other values unprogrammed and got the same result.

For hardware the boot mode select pins (GPIO72 and GPIO84) are pulled high via pull ups (Get/Flash boot mode). The target hardware is a custom control board but the DSP hardware as far as power supplies, JTAG, reset supervior IC, PCB layout, etc... are basically the TI reference design.

My next step is to read up again on the boot pins and boot modes and how the OTP ECC works to see if I am not handling those properly but presently the boot mode setup is all at the default value and I have not changed any ECC settings from defaults.

As a DCSM newbie I have read through the DCSM section in the TRM a few times and searched forum post here. Here are some key points I have learned so far. Please let me know if I am wrong on any of these as it will help me figure out the problem (and future problems). I will also correct or delete any incorrect statements so I don't confuse people.

-You may think if you lock all the memory in one zone that there will be no memory access problems to worry about. This is not the case because shared RAM (GSx) and M0/M1 cannot be secured. Also you can not copy data from secure flash to non secure ram (I think). This means that if you have a ramfuncs section running of GSx RAM or non secured local RAM you will have a problem at run time when you try to copy the ramfuncs from secure flash to unsecure ram. Ramfuncs should be in secure ram if the ramfuncs flash is secure.

-You probably want your stack in unsecure ram so any function call can use the stack. If your stack was in secure ram and a function in unsecured flash was called that function would not be able to access the stack. If you had an array of function pointers in unsecured memory that gets called they would also have a problem if the stack was in secure ram.

-If you turn on the exe only option on the flash where your ramfunc are linked you will need to use the built in SafeCopy function TI provides. If the exe only is turned on you cannot read from that flash section into RAM even if its being done from within the same secure zone which is why the SaveCopy function is provided.

-There are two security zones. The dual zone would allow you to lock your code/IP under one zone and the leave RAM/Flash open for a third party to develop on and then the third party could use the other zone to lock their IP. If you are a single developer and simply want to lock down all memory you really only need to use one zone.

-The DCSM OTP values can only be written once but some values (password , grab RAM/Sect, and exe only settings) have 30 copies in the OTP memory. These would be useful if you want to change to a different set after programming an initial set. Which of the 30 zone blocks is used is picked by the LINKPOINTER. The first zone block will be used by default if link pointer is all Fs. To select the second zone block you would set bit zero in the link pointer to zero. To select the third zone block you would set bit one to zero and so on for the reset of the zone blocks up to block 30 via bit 29.

-Even if you write all Fs to an OTP value the corresponding ECC will be written for that blank value (except link pointer). This means you if you write all 0xFFs you will not be able to go back later and write a non 0xFF value because the ECC will have been previously written and it won't be the same for your new value.

-If you are going to link in OTP configuration to your project follow the example in the Blinky with DCSM example project which you get with the controlSUITE install. The example project is under device_support in the folder structure. The OTP sections are intentionally split up to avoid reserved areas. If you write to those reserved areas it creates an error. Also when you are ready to attempt actual programming of the OTP remember to comment out the type = DSECT option in the 2837xD_dscm_lnk_cpu1.cmd file. type = DSECT is a dummy load option which will prevent the section from being linked in. Finally if you use any zone block other than the default first zone block (pointed to if link pointer is all Fs) you will have to update the origin of DCSM_ZSEL_Z1_Px to the zone you are using, each zone is 0x10 long.

93ddb68554