Hi,
I've recently been trying to get an LRUN application up and running on the NUCLEO-N657X0-Q board. Similar to the posts in https://community.st.com/t5/stm32cubeprogrammer-mcus/stm32n6570-dk-unable-to-erase-external-flash/td-p/757897, I cannot access the flash for erasure, with errors indicating to verify flash memory protection.
I currently have the BOOT0 jumper on 1-2 (for 0) and BOOT1 on 2-3 (for a logical 1), which should be putting me into the Development boot mode. For external loaders, I have MX25UM51245G_STM32N6570-NUCLEO selected.
I've tried both full chip erase and sector erase, both giving me errors that tell me to verify flash memory protection.
Please advise, I'm not sure what I'm doing wrong. This is my first time attempting to flash the memory.
EDIT: I should've mentioned, I'm using STM32CubeProgrammer 2.20.0. I've tried this on both Windows 11 and Ubuntu 24.04
EDIT #2: I have also attached the verbose log file after I hit "full chip erase" and a single sector
EDIT #3: I've also tried bypassing the chip erase and loading my signed bin file into flash. That's also locked me out, as expected.
1 ACCEPTED SOLUTION
Accepted Solutions
Scrubbing the OTP output, I see some deltas between the output of my NUCLEO board and the "prog-locked by ST" status of table 17 of RM0486:
Per table 17 of RM0486, OTP_HW_WORD4/OTP4 should've been prog-locked by ST, and it shows as not being locked on my board.
I don't think I programmed OTP260-267, but they show as programmed. Regardless, I think those shouldn't effect the flash operation, as they seem to be intended to be used by the application only.
I've checked the voltage on the power rails of the flash chip, as well as the reset. The chip is not being held in reset (it has a 1.8V input), and the power is at a rock-solid 1.8V as well.
Another update -
After coming home from work, I tried getting this to work again. The very first time I plugged in the NUCLEO board and tried erasing a sector, I got this:
Which is a success! however, subsequent attempts to erase the chip lead to the same issue:
Now, I did think to myself, "maybe there's a hardware issue", as I had success once after the board was powered off for 24 hours. I've been able to unplug the board and leave it sitting there (letting capacitors discharge) for 3 or 4 attempts so far and I have the same behavior of it successfully clearing the sector the very first time, followed by not being able to write to the flash any more.
Unless there's something I'm missing, I don't know if I can do anything else about this.
Hi @Imen.D,
I've done the ST-Link upgrade, to version V3J16M8 STM32 Debug+VCP, with no change in behavior.
I believe there's a typo in @RomainR.'s post, as he's calling BOOT0 JP2 and BOOT1 JP1, whereas UM3417 calls them out as BOOT0 JP1 and BOOT1 JP2. regardless, I have tried all four combinations of jumper settings with BOOT0/BOOT1 and I can only connect the debugger when JP2 is set to 2-3 (JP1 is a don't care). I currently have JP1 on 1-2 and JP2 on 2-3.
I do not know how to read or set the RDP level, this is the closest menu I've found to that:
Can you show me how to read it out?
