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?

[FormerMember]

Do you mean nRF51822 instead of nRF52832?

[jlj]

No, I'm only referring to the nRF52 devices (nRF52832-QFAB and nRF52832-QFAA)

[FormerMember]

The nRF52832-QFAB device is specified in the Product Specification to 256kB Flash and 32kB RAM. Utilizing any Nordic device outside of the specifications for the given part can give unpredictable behavior, and Nordic is in no way liable for the functionality nor specification at this point, and it is as such not something we encourage anyone to do. If you want additional details on the risks associated with using a Nordic device outside of the specification, please get in touch with a local sales representative.

To check the capabilities you should check the FICR.INFO.VARIANT register.

[Roger Clark]

Devices with more RAM or more flash than the spec is not uncommon in the microcontroller world.

But if you are building for a commercial product, you should not assume that a one off instance of a specific device performing beyond its spec will be replicated by all other devices of the same type.

[RK]

That's a pretty sad answer really. The whole point of having RAM, FLASH and CODEPAGE entries in the FICR is exactly so you can work out the capabilities of the chip without having to map variant codes, codes which change as time goes by, with different production runs etc, to capabilities. All of the Nordic code I've seen in the past which deals with memory capabilities all uses CODEPAGESIZE etc to work out what's there, I don't think I've ever seen a piece which uses VARIANT and tries to map it. In fact a quick grep of the most recent SDK shows no use of VARIANT.

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.