Cryptocell and usb

[AintMina]

I was building the "console" sample code found in zephyr for my custom nrf52840 board and I managed to get it to work. But as soon as cryptocell gets enabled, it doesn't work anymore.

Q1:  Why doesn't the devicetree find "nordic,cryptocell"? I get a warning like this: Unknown node type "nordic,cryptocell"

- This also applies to nrf52840 Dongle and DK.

Q2: Cryptocell is enabled by default in nrf52840 devicetree which gets applied to all the boards (like nrf52840dongle and nrf52840dk and my custom board which uses nrf52840dongle as template). But this breaks the usb communication with the "console" sample on my custom board (It does build though).

- I can't test it with other boards since I only have nrf52dk and it doesn't support usb.

- I'm flashing it through mcuboot so I don't have access to debugger and I'm scared to use the nrf52dk as debugger since it already has bricked 3/5 devices.

Q3: The acl node has also a warning: Address range collides with flash-controller@4001e000 (both start at 0x4001e000)

- But it still works with it enabled.

I'm running Manjaro kde with linux66 kernel, v2.6.1 toolchain with v2.6.1 SDK installed through vscode extension.

This is the configuration which works:

And prj.conf:

CONFIG_USB_DEVICE_STACK=y
CONFIG_USB_DEVICE_PRODUCT="Testing"
CONFIG_USB_DEVICE_PID=0x0851
CONFIG_USB_DEVICE_VID=0x884E
CONFIG_USB_DEVICE_INITIALIZE_AT_BOOT=n

CONFIG_SERIAL=y
CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=y
CONFIG_UART_LINE_CTRL=y

 

And board defconfig:

CONFIG_SOC_SERIES_NRF52X=y
CONFIG_SOC_NRF52840_QIAA=y
CONFIG_BOARD_NRF52840_CUSTOM=y

# ??????
CONFIG_BOARD_ENABLE_DCDC=n

# 32K clock
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION=y

# Enable MPU
CONFIG_ARM_MPU=y

# enable GPIO
CONFIG_GPIO=y

# Enable Zephyr application to be booted by MCUboot
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_DISABLE_FLASH_PATCH=y

[Einar Thorsrud]

Hi,

AintMina said:

The problem is that in vscode the "flash", "erase and flash" and "debug" all use "merged.hex" and not the APP. Meaning everytime I flash my app with the debugger I replace my working bootloader with the non working one. This is a terrible way of doing things if bootloader and app are developed by different people or departments. This means I HAVE to have the bootloader on my computer when I want to debug an app for it.

That is a good point. The reason we do it like this is that it makes the most common use case working out of the box. Whenever you try to flash or debug, you will get all images in case of multi image projects. But this is not always wat you want. An alternative could be to get the hex file you want to use, and point to that using CONFIG_MCUBOOT_BUILD_STRATEGY_USE_HEX_FILE. See here for more details on that.

AintMina said:

the problem is that cryptocell doesn't work without debugger attached. This was the same problem which "deleted" my bootloader since the APP also enabled cryptocell in the bootloader and overwrote it and thus bootloader didn't work anymore.

I see. This is what we must focus on. However, I have not been able to reproduce this which is why I have been asking for more information.

AintMina said:

And why would I need DK to run the sample codes? I still havent been able to start writing the actual FW to this, because theres still something wrong with the config and that's what Im trying to figure out.

There are a few good reasons for having a DK. First of all, it is a known good piece of hardware, and as such a good platform for prototying and debugging specific issues. It is also a platform we in Nordic tech support has access to, so if you were able to reproduce the issue on that, you could let us know how we can reproduce on our end. It can also be used to debug your custom board (which you described early on that you did not want to do or were not able to do).

AintMina said:

So, why is cryptocell only working with debugger?

Without debugger, the cryptocell app doesnt even reach main.

Im running the board in normal mode and DCDC is NOT enabled.

That what we need to figure out. Can you share your full set of board files in a zip so that I get the full picure and have better hops of being able to reproduce the issue? (I want to start with simply building for your board and running that on my DK as that seems like the best option at this point).

[AintMina]

Don't mind the mess, it's a work in progress still.

6747.boards.zip

[Einar Thorsrud]

Hi,

I built the console sample (zephyr/samples/subsys/usb/console/) using your unmodified board files (which include cryptocell in the device tree), and the sample works as expected when I test on a DK also when I am not debugging (I even power-cycled the device). I get the expected output in the CDC terminal.

Do you need to do anything else to trigger the issue? As mentionned before I am not able to see a link between USB and CryptoCell so honestly I am not very suprised about this result. Could it be that you have also made other changes at the same time, and that the problem was something else?

[AintMina]

I though we already established this that it's not USB and CryptoCell, it's just CryptoCell.

There is no need to trigger anything and no, CC(CryptoCell) is the only change.

Hmm...

Are there some HW requirements for CC?

Does it require external 32k clock?

Did you use sdk-zephyr or zephyr? the board files do differ between these. I used sdk-zephyr since thats what vscode automatically uses.

Is there some specific config I need in the mcuboot to upload CC software? though it did also break the bootloader when CC was enabled...

[Einar Thorsrud]

Hi,

I thought the problem was running the usb console sample with CryptoCell defined in your board files? I tested that with nRF Connect SDK v2.6.1 as that is what you descibed. (So that is using the saple from sdk-zephyr in that nRF Connect SDK release).

AintMina said:

Is there some specific config I need in the mcuboot to upload CC software? though it did also break the bootloader when CC was enabled...

No. But as the bootloader normally does crypto operations (validating images on activation and on boot), there may be a difference depending on if CryptoCell is enabled or not if you configure the bootloder to use cryptocell fro crypto operations. Is the issue here in the bootloader? If so we need to look into that. And if so, can we start with if you are using MCUboot, NSIB, both, or some custom bootloader? And also if using the bootloaders we provide in the SDK, which changes have you made and can you share the configuration etc?