I'm testing with the new rev of the nRF52832 (build code QFAAGB on the package), and I'm not able to observe behavior that makes sense to me per the updated product spec.
My basic test has been to do an application-only load of my project that uses the SoftDevice. If it boots (as observed via UART output), then the SoftDevice was not erased, and Access Port Protection was not enabled. If it does not boot, the SoftDevice was erased, so Access Port Protection was enabled. I'm doing the loading via Keil uVision.
What I'm seeing is that my old code behaves identically. All this did was that if we were in Production build configuration, we write UICR_APPROTECT_PALL_Enabled to NRF_UICR->APPROTECT, and in Debug configuration, we do nothing to UICR. This code appears to function identically on the new hardware: If I load a Debug application, another application load works fine, but if I load a Production application, the chip is erased when I load another application. On the new hardware, I would have expected the boot to fail in both configurations.
The "old code" uses MDK 8.15 and does not touch the new DISABLE and FORCEPROTECT registers.
Is there another way that I can verify that there is some new behavior related to APPROTECT? Hopefully, there is something easier than trying to reproduce the original attack.
