NRF52840 Cryptocell register setting reading problem

RE: NRF52840 Cryptocell register setting reading problem

Einar Thorsrud — Mon, 16 Dec 2019 09:58:02 GMT

Hi,

Yes, the documentation for CrytoCell is a bit lacking. This has been reported, so hopefully, it will improve in the future.

I have a few more details to share.

CryptoCell must alway be enabled before writing to any of the other registers. This is not explicitly stated in the PS.
The simple delay approach I used to show that there is a timing dependency is not the best (it might give you a race condition of timing changed due to temperature or something else). Instead, you could try to read back the registers until it has the expected value. (E.g. use "while (NRF_CC_HOST_RGF->HOST_IOT_LCS != 0x102) {}" after writing to HOST_IOT_LCS).

RE: NRF52840 Cryptocell register setting reading problem

Barry — Fri, 13 Dec 2019 14:33:29 GMT

Thanks. This did work. I appreciate the help. Although obviously you guys need more documentation around the cryptocell.

RE: NRF52840 Cryptocell register setting reading problem

Einar Thorsrud — Fri, 13 Dec 2019 14:09:39 GMT

Hi,

I am not sure about the debugger issues here, nor am I able to find a link between ACL and this. But, there seems to be a requirement here which may be related to what you see.

Testing your code from the original question the HOST_IOT_LCS register will not be set, even if waiting a long time to read it out (it will be 0x00000002). But, adding a delay between writing to ENABLE and HOST_IOT_LCS and before reading it back this works as expected, and HOST_IOT_LCS is read back as 0x00000102.

    /** Enable crypto cell to configure it **/
    NRF_CRYPTOCELL->ENABLE = CRYPTOCELL_ENABLE_ENABLE_Enabled << CRYPTOCELL_ENABLE_ENABLE_Pos;

    nrf_delay_us(1);

    /** Config cryptocell resgister so Device root key can only be set once per reset*/
    NRF_CC_HOST_RGF->HOST_IOT_LCS = CC_HOST_RGF_HOST_IOT_LCS_LCS_Secure << CC_HOST_RGF_HOST_IOT_LCS_LCS_Pos;

    nrf_delay_us(1);

    NRF_LOG_INFO("HOST_IOT_LCS: 0x%08x", NRF_CC_HOST_RGF->HOST_IOT_LCS);

RE: NRF52840 Cryptocell register setting reading problem

Einar Thorsrud — Thu, 12 Dec 2019 17:17:25 GMT

Hi,

Yes, you are right. The documentation is unclear on this.

And about the original question, it seems you are right on that point tas well. The LCS_IS_VALID is a read-only field, but if you write to it, this will make it 1 regardless of what you write. It is intended to show if LCS is set, which is the only field in HOST_IOT_LCS that should be written to.

So in short, any writing to any part of the HOST_IOT_LCS register sets the LCS_IS_VALID field to 1.

RE: NRF52840 Cryptocell register setting reading problem

Barry — Thu, 12 Dec 2019 17:12:40 GMT

Sorry about so many posts, but I think I have another thing that is contributing to the issue. This code is executing in a bootloader whose partition is from 0 to 0x22000. Another protection I implement in the bootloader is to use ACL[0] to protect the bootloader from writes. I use this code

NRF_ACL->ACL[0].ADDR = 0;
NRF_ACL->ACL[0].PERM = ACL_ACL_PERM_WRITE_Disable << ACL_ACL_PERM_WRITE_Pos; // 0x2
NRF_ACL->ACL[0].SIZE = DT_FLASH_AREA_MCUBOOT_SIZE; // this is 0x22000

When I do this before I write the LCS register, I get the behavior I described in my original post. If I don't write to this ACL i get he behavior from my second post.

I don't see how this ACL code affects the writing to the NRF_CRYPTOCELL, or NRF_CC_HOST_RGF

I also notice that if I do the ACL setup before I write the LCS resgister, and I have more than 5 break points set anywhere in the code. Then I try to step past a line in the disassembly that stores a value to either the RF_CRYPTOCELL->ENABLE register or the NRF_CC_HOST_RGF->HOST_IOT_LCS register, SES takes a long time and then SES spits out a message saying something like

"Timeout while erasing sectors, RAMCode did not respond in time. (PC = 0x00000000, CPSR = 0x00000000, LR = 0x01000005)!
Failed to erase sectors.
Programming failed @ address 0x00001A50 (block verification error)"

Sometimes execution stays at the line and does not execute it, sometimes execution goes past it

If I have no debug points the code runs fine.

These are software breakpoints.

If I remove the ACL protection I can use as many breakpoints as I want and there is no timeout problems.

RE: NRF52840 Cryptocell register setting reading problem

Barry — Thu, 12 Dec 2019 15:03:11 GMT

Also the documentation doesn't really mention this (I don't think) but to be clear, if I want to write to or read from CC_HOST_RGF the cryptocell must be enabled correct. It seems that way but I only figured that out by trial and error.

RE: NRF52840 Cryptocell register setting reading problem

Barry — Thu, 12 Dec 2019 14:58:12 GMT

I think maybe the issue is fixed. But I'm not sure. The behavior seems to depend how I debug.

First I changed one thing. I was doing this register setting before the flash device was initialized. So I changed it to happen after (not really related to this register setting but for something else I am doing in the same function).

Now when I set the register, it still goes fine LCS_IS_VALID is 1 and LCS is 2 (I see that after I set the register but before I disable). Then when I enable the cryptocell again if I step my debugger through the lines (shown in my original post) where I set the register I see LCS_IS_VALID is 1 and LCS is 2 in the register. But if I don't step my debugger though those lines and later I enable the cryptocell and look at the value of the register in the debuger LCS_IS_VALID is 1 and LCS is 0.

So this is probably just a debugger issue at this point ( I am using nordic connect SES with a J-trace pro). But I'm not sure. I guess the only way to tell for sure will be to encrypt something with the root key then try to change the root key, and encrypt again, and see if the result is the same.

RE: NRF52840 Cryptocell register setting reading problem

Einar Thorsrud — Thu, 12 Dec 2019 14:56:08 GMT

Hello,

There may be a problem with the LCS_IS_VALID register and/or always-on power domain. We need to look a bit more into this, but I will update you as soon as possible (hopefully tomorrow).