nRF52 FICR registers

[chris]

Reading from the FICR seems to produce some results other than what I would expect. For example, reading from offset 0x10C seems to return the flash size (instead of 0x110).

J-Link>mem 0x1000010c 4 1000010C = 12 05 00 00

Reading from 0x110 returns 0xFFFFFFFF

INFO.PACKAGE and INFO.VARIANT also seem to return 0xFFFFFFFF. Is this just a 'feature' of the A0 silicon?

[Susheel Nuguru]

Because these registers are written by production tool, seems like there is a fault in writing to these info registers at time of production. I have created an internal ticket for this. But I am not sure what could be done to already shipped kits. We will atleast make sure that this is fixed soon and the current chips going out.

Do you use this registers in your application? It does not stop you in your development right

[chris]

Yeah I figured maybe these were OTP bits. A lot of time with first article silicon, the ATE process isn't quite 100%, so no big deal. It will in on way impede me getting done what I need to get done. Just letting you guys know so you can fix it before the next wafer lot (or packaging, depending on which step you do final characterization and programming). Thanks

[Susheel Nuguru]

We really appreciate you for coming here and letting us know about it. Makes this devzone more effective. +1 for you :) Can you please accept this answer so that I can close this case

[RK]

I came across this today as well. However it seems that not-only is the value for FLASH size in the place where the value for RAM size should be, it's also the wrong number. The value there is (as chris notes) 0x00000512, which is 512 in binary coded decimal, the manual however says it should be 0x00000200, as in 512 in binary.

So is it just the flash size is in the wrong place but is correctly '512' as a binary coded decimal, and the manual is wrong, or is it not only in the wrong place, but is also the wrong number, and the manual is correct?

[Susheel Nuguru]

Hi RK, The values mentioned in the manual are decimal, that is 512 = 0X200. I was told that these registers were not supposed to be exposed. This will be fixed in the next version of the manual. Those registers became obsolete and not supported and the production line did not get updated with this info, not as scary as it sounds (and hopefully no questions arise about what else is obsolete lying in there) Please do not use these registers in any context, and it does not matter for now if the manual is wrong about the addresses and/or value. It has been informed to right personnel and it will be handled, thanks for pointing us to it.

[RK]

ah ok - I was trying to find a way to work out at runtime how much RAM was on the chip,I shall give up and hardcode it to 64k until a version comes out one day with a different amount which will probably give you a way to figure it out.

Thanks