Cryptocell and usb

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
Parents
  • Hi, 

    I would appreciate additional information and some clarifications.

    Do you use a custom board with nrf52840?

    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.

    Which console sample did you use? Is it maybe console over USB?
    How did you enable CryptoCell?
    What happens when it does not work anymore, is there any error?

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

    Did you get this warning on your custom board? Have you tried on nrf52840-dk?
    "nordic,cryptocell" unknown type is probably related to some devicetree error. Can you show where and how you added "nordic,cryptocell" configuration?

    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).

    Can you provide information in which way is USB communication broken, what exactly happens?
    Is USB communication functional on nrf52840-dk board?

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

    This also indicates devicetree configuration issue.

    But it still works with it enabled.

    Can you rephrase this - what works when what is enabled? Can you show what is enabled and what happens when it works?

    What is shown in provided screenshot?

    Best regards,
    Dejan

  • Hi,

    Do you use a custom board with nrf52840?

    Yes, my custom board has nrf52840.

    Which console sample did you use? Is it maybe console over USB?

    It was the USB subsys sample called "console"

    How did you enable CryptoCell?

    CryptoCell is enabled by default here.

    What happens when it does not work anymore, is there any error?

    It does build without any errors, but the usb does not get initialized or recognized by my PC. It's hard to say what happens there without debugger.

    Did you get this warning on your custom board? Have you tried on nrf52840-dk?
    "nordic,cryptocell" unknown type is probably related to some devicetree error. Can you show where and how you added "nordic,cryptocell" configuration?

    This warning is also shown in the nrf52840.dsti. Nrf52840-dk includes the same file. "nordic,cryptocell" is configured there and I only disabled it in my board files to make the usb code work.

    Can you provide information in which way is USB communication broken, what exactly happens?
    Is USB communication functional on nrf52840-dk board?

    The only way I know it's broken is that it no longer gets recognized as a usb serial device and it is not found with NRF Connect or any other serial terminal software. I do not have access to nrf52840-dk board.

    This also indicates devicetree configuration issue.

    This I already knew. The question was why? Both of the nodes have the default configuration that come with the SDK.

    Can you rephrase this - what works when what is enabled? Can you show what is enabled and what happens when it works?

    This sample code and other codes still work when acl is enabled regarding the warning.

    What is shown in provided screenshot?

    The device configuration part of the devicetree.

    BR

  • 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...

  • 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?

  • I thought the problem was running the usb console sample with CryptoCell defined in your board files?

    No, the problem is that CC breaks ANY sample code. I remembered that I tested the bluetooth function to work WITH debugger not without.

    And if so, can we start with if you are using MCUboot, NSIB, both, or some custom bootloader?

    Im using MCUboot from the SDK with this config and CC disabled:

    CONFIG_PM=n
    
    CONFIG_MAIN_STACK_SIZE=10240
    CONFIG_MBEDTLS_CFG_FILE="mcuboot-mbedtls-cfg.h"
    
    CONFIG_BOOT_SWAP_SAVE_ENCTLV=n
    CONFIG_BOOT_ENCRYPT_IMAGE=n
    
    CONFIG_BOOT_UPGRADE_ONLY=n
    CONFIG_BOOT_BOOTSTRAP=n
    
    ### mbedTLS has its own heap
    # CONFIG_HEAP_MEM_POOL_SIZE is not set
    
    ### We never want Zephyr's copy of tinycrypt.  If tinycrypt is needed,
    ### MCUboot has its own copy in tree.
    # CONFIG_TINYCRYPT is not set
    # CONFIG_TINYCRYPT_ECC_DSA is not set
    # CONFIG_TINYCRYPT_SHA256 is not set
    
    CONFIG_FLASH=y
    CONFIG_FPROTECT=y
    
    ### Various Zephyr boards enable features that we don't want.
    # CONFIG_BT is not set
    # CONFIG_BT_CTLR is not set
    # CONFIG_I2C is not set
    
    CONFIG_LOG=y
    CONFIG_LOG_MODE_MINIMAL=y # former CONFIG_MODE_MINIMAL
    ### Ensure Zephyr logging changes don't use more resources
    CONFIG_LOG_DEFAULT_LEVEL=0
    ### Use info log level by default
    CONFIG_MCUBOOT_LOG_LEVEL_INF=y
    ### Decrease footprint by ~4 KB in comparison to CBPRINTF_COMPLETE=y
    CONFIG_CBPRINTF_NANO=y
    ### Use the minimal C library to reduce flash usage
    CONFIG_MINIMAL_LIBC=y
    CONFIG_NRF_RTC_TIMER_USER_CHAN_COUNT=0
    
    
    
    # IS BOOTLOADER?
    CONFIG_IS_BOOTLOADER=y
    CONFIG_BOOTLOADER_SRAM_SIZE=256
    CONFIG_MCUBOOT_INDICATION_LED=y
    
    # Required by USB
    CONFIG_MULTITHREADING=y
    
    # USB
    CONFIG_USB_DEVICE_STACK=y
    CONFIG_USB_DFU_CLASS=y
    CONFIG_USB_DEVICE_REMOTE_WAKEUP=n
    
    #### MAY FUCK UP YOUR DAY 
    #CONFIG_USB_DFU_REBOOT=y
    
    CONFIG_USB_DEVICE_PRODUCT="MCUBOOT"
    CONFIG_USB_DEVICE_VID=0x1915
    CONFIG_USB_DEVICE_PID=0x520F
    
    CONFIG_BOOT_USB_DFU_GPIO=y
    CONFIG_BOOT_SERIAL_PIN_RESET=y
    
    
    # Serial
    CONFIG_CONSOLE=n
    CONFIG_SERIAL=y
    CONFIG_UART_INTERRUPT_DRIVEN=y
    CONFIG_UART_LINE_CTRL=y
    
    # MCUBoot serial
    CONFIG_GPIO=y
    CONFIG_MCUBOOT_SERIAL=y
    CONFIG_BOOT_SERIAL_CDC_ACM=y
    CONFIG_NORDIC_QSPI_NOR=n

    Also to add here, the same code works with CC disabled and uploaded through MCUboot.

  • Hi,

    I see. I misunderstood this to be about USB and CryptoCell (I did not see any samples failing with your your board files, withou or without CryptoCell or debugging or not). But this is related to your MCUBoot configuration it seems? To test that, I took the zephy blinkyt sample from nRF Connect SDK 2.6.1 and did the following changes:

    Added to prj.conf:

    CONFIG_BOOTLOADER_MCUBOOT=y

    made a child_image/mcuboot.conf where I copy-pasted all configs from your last post. And as I am testing on the nRF52840 DK I modified nrf52840_qalmari.dts so that led0 is gpio P0.14 as that is a LED on the DK.

    So this is your board files (with the led0 pin changed) and your mcuboot configuration. However, the applciation is startd and works as expected. So I am unfortunately still not able to reproduce the issue.

    Can you explain more, and perhaps attach the application (all files including config files, CMakeLists.txt etc) that you are using?

  • Would you be able to test it without 32k clock CONNECTED to mcu?

    The nrf52dk doesnt have full CC and the only difference I can figure out is that you DK board has external 32k clock connected.

    Also I did figure out that the app breaks before EARLY, PRE_KERNEL_1 and PRE_KERNEL_2. I used LEDs as debug in those states.

    I also tried to enable usb logging in APPLICATION state and it worked, but when I enabled it in PRE or POST kernel, then my PRE kernel LED debug flashed really fast. So confirming that the app with CC enabled does not even reach kernel.

    Do you have any ideas if this could be a schematic problem?

Reply
  • Would you be able to test it without 32k clock CONNECTED to mcu?

    The nrf52dk doesnt have full CC and the only difference I can figure out is that you DK board has external 32k clock connected.

    Also I did figure out that the app breaks before EARLY, PRE_KERNEL_1 and PRE_KERNEL_2. I used LEDs as debug in those states.

    I also tried to enable usb logging in APPLICATION state and it worked, but when I enabled it in PRE or POST kernel, then my PRE kernel LED debug flashed really fast. So confirming that the app with CC enabled does not even reach kernel.

    Do you have any ideas if this could be a schematic problem?

Children
  • Hi,

    I double checked when I build with your board files, and both the bootloader and application are configured to use the LFRC (boards without crystals is also very common and as long as the LFRC is configured that should not cause problems).

    Regardign this being a HW issue I don't see anythign indicating it, but on the other hand it is difficult to understand this issue, so it could be worth while taking a look if you can shere your schematics (and perhaps also the layout).

Related