nrf52832-QFAB Flash/RAM sizes

[jlj]

I'm using the nrf52832-QFAB variant (32K RAM 256K Flash)

The part is marked as NRF52832 QFABB0 1630AC

Surprisingly, this part is happily running my application and bootloader that is built for the larger variant (QFAA with 64K RAM 512K Flash).

When I read the FICR registers I get the following:

• FICR.INFO.VARIANT = 0x41424230 (="ABB0")
• FICR.INFO.RAM = 0x00000040 (= 64 kByte RAM variant)
• FICR.INFO.FLASH = 0x00000100 (= 256 kByte FLASH variant)
• FICR.CODEPAGESIZE = 0x00001000
• FICR.CODESIZE = 0x00000080
• CODEPAGESIZE * CODESIZE = 0x80000 = 512kByte

This information doesn't make the situation much clearer :)

Why does the QFAB part have the larger RAM and FLASH?

Why do the FICR registers have contradicting values?

We may end up having both QFAA and QFAB variants in our production lines (for different products). I would like to be able to check in firmware that the correct parts are in place.

Which of the FICR registers can I rely on in code to check capabilities?

[awneil]

I think if you have registers which indicate the capabilities of the chip, they should indicate correctly the capabilities of the chip and developers should be able to rely on them.

Absolutely!

[Dave]

I agree with RK and awneil. As a developer I need a software means to query the part and know what I am using. I wasted half a day to debug some fds/fstorage code only to determine that the CODESIZE value being returned was bogus, 128 for 512KB part when I am using a 256KB part and it should have been 64 instead. That is a bug that should be addressed and fixed by NS.

[jlj]

I don't use undocumented features or go beyond specs in my commercial designs, for the very reasons you've mentioned. My main concern here is knowing what to trust when the FICR registers have incorrect or conflicting information. Unfortunately this is one of those cases where the silicon does not match the datasheet. We may end up having both variants used in the same production environment and I'd like to be able check in code that the right part is loaded.

[RK]

At the least if this is the case there should be a PAN about it documenting that the FICR registers describing the FLASH/RAM of the chip are not reliable and cannot be used, with a documented workaround using the VARIANT, and that PAN should persist until the anomaly is fixed.

[Roger Clark]

Interesting point about the

FICR.INFO.RAM reporting incorrectly. I suppose this should be treated as a bug in the silicon ? I know that the first release of nRF52 has a lot of errata, perhaps this was one of those

It sounds like you have to just use the FICR.INFO.VARIANT rather than the FICR.INFO.RAM