Unable to access the nRF54L15-DK after all-erase operation

Hi team,
After executing RRAMC.ERASE.ERASEALL with an external debugger, I was unable to access the CPU (board) after reset. To resolve this issue, I connected the nRF-programmer and conducted an erase operation. Following this, the board appeared to function properly.

In relation to this matter, I seek clarification on the following points:
1) It appears that erasing the initial 2KB of RRAM results in a loss of access to the controller. What is the reason for this occurrence, as it is not mentioned in the data sheet?
2) After the nRF-programmer's erase operation, the first 2KB of RRAM contains certain data. Are these values related to configuration registers? In other words, how do these values facilitate the connection to the CPU, and where do they originate from after the erase operation?
3) What steps should I take to regain access to the board following a successful erase all operation (RRAMC.ERASE.ERASEALL) and reset?

Warm regards,
KP

Parents
  • Hi,

    The chip will by default have access port protection (read back protection) enabled by design.

    So it's only an eraseall operation that can clear the access port protection, when eraseall is executed the access port protection is disabled until next reset.

    It's possible to disable access port protection by programming the chip with firmware that disable it from the inside (e.g. write appropriate values to the UICR and registers in RAM). This is for instance what happens when you program the chip during developing a project or if you execute a recover operation. The recover operation will program a small program in start of code space that disable access port protection.

    Kenneth

Reply
  • Hi,

    The chip will by default have access port protection (read back protection) enabled by design.

    So it's only an eraseall operation that can clear the access port protection, when eraseall is executed the access port protection is disabled until next reset.

    It's possible to disable access port protection by programming the chip with firmware that disable it from the inside (e.g. write appropriate values to the UICR and registers in RAM). This is for instance what happens when you program the chip during developing a project or if you execute a recover operation. The recover operation will program a small program in start of code space that disable access port protection.

    Kenneth

Children
No Data
Related