[Verification of RAMCode failed]

RE: [Verification of RAMCode failed]

Håkon Alseth — Wed, 04 Mar 2026 11:03:52 GMT

Hi,

[quote user="Kjs0"]The same PAN1770 module works normally on the vendor’s evaluation board[/quote]

Does this mean that you have done a swap-test, ie. took a module from a bad board, and mounted in on a known good board, and the failure does not follow the module?

Meaning that the failure follows the PCB, not the nRF?

If yes, could you share your schematic?

Do you have a 32k source present, and do you have DCDC inductors present?

Kind regards,

Håkon

RE: [Verification of RAMCode failed]

Kjs0 — Tue, 03 Mar 2026 12:05:07 GMT

I’ve tried reflashing/resetting many times using nrfjprog --recover -f NRF52.
The same PAN1770 module works normally on the vendor’s evaluation board, but on our custom boards (also using PAN1770) all of them show the same issue. We believe we have done sufficient hardware validation.
Yesterday, one of our hardware engineers managed to get one board to successfully enter a debuggable/programmed state by trying various terminal commands, but unfortunately the exact steps were not recorded. We haven’t been able to reproduce it since, even after trying different combinations. That’s why I suspect there may be a specific sequence of commands or a tool-side setting that makes the difference.

Current observation / difference between a “good” board and a “bad” board:
When I use the nRF Connect for Desktop Programmer app and download the exact same HEX file,

On the “good” board, the Programmer app correctly recognizes and programs the image into separate regions such as Engine (SoftDevice), Application, and MBR or Application (three distinct sections).
On the “bad” boards, the same HEX seems to be treated as Application only and the memory map/regions do not get separated the same way, and the download/verify keeps failing.

So it looks like the failing boards may not be handled with the same memory layout/region interpretation (SoftDevice/MBR/Application), which might be why programming and verification keeps failing.

RE: [Verification of RAMCode failed]

Håkon Alseth — Mon, 02 Mar 2026 14:00:18 GMT

Hi,

Q1: Can you please try to issue "nrfjprog --recover" first, then re-flash?

Q2: How many of your devices behave like this?

Q3: Was this device previously working, and or has it always been non-working?

[quote user=""]Why do the written and read data values differ (e.g., 0x3A vs 0x32)?[/quote]

This is a verification error, ie. that the written vs. readback content differs.

It is a similar scenario for the RAMCode error you are seeing.

Kind regards,

Håkon