Can the UART RX/TX pins be also read as GPIO input pins

RE: Can the UART RX/TX pins be also read as GPIO input pins

clockis — Thu, 01 Dec 2022 13:03:38 GMT

Hi Hung,

Thank you very much for your assistance!

I am closing this ticket as per your suggestion and will be opening another specificaly focused on the issues that I am experiencing!

Thank you for your time!

RE: Can the UART RX/TX pins be also read as GPIO input pins

Hung Bui — Tue, 29 Nov 2022 12:03:25 GMT

Hi Stavros,
Sorry for the late response. I was on vacation.

I think you would need to create a new ticket as it's drifting away from the original question. Also I don't have much experience with the encrypting of image.

As I mentioned, we don't support encrypting image out of the box. So you would need to follow the documentation from MCUBoot and imgtool.
Vidar would have some more experience on this. I think creating a new ticket would be the best.

RE: Can the UART RX/TX pins be also read as GPIO input pins

clockis — Thu, 24 Nov 2022 15:42:21 GMT

Hi Hung,

Two followup questions to my first question:

1. Could you elaborate on the method of manually encrypting using the imgtool or provide some relevant documentation as I could not find a way that worked by following the documentation and previous tickets on the subject:

developer.nordicsemi.com/.../encrypted_images.html

devzone.nordicsemi.com/.../mcuboot-with-serial-uart-and-image-encryption

https://devzone.nordicsemi.com/f/nordic-q-a/91331/nrf52840-ncs-mcuboot-cc310-enabled-image-encryption/383355

2. Is there encryption of the binary file used for updates available/possible for the nRF Secure Immutable Bootloader?

Thank you!

Best regards,

Stavros

RE: Can the UART RX/TX pins be also read as GPIO input pins

Hung Bui — Thu, 24 Nov 2022 09:59:45 GMT

Hi Stavros,

1. No it's not enabled by default. So the binary file are original and can be reverse engineer. It's possible to enable encryption with MCUBoot, but we haven't tested it and it's not integrated in the build system. So you would need to manually encrypt the image using imgtool.

2. You can just create one your self. Just make the child_image folder and then put a mcuboot.conf there.
You can also add extra CMake arguments like this:

3. No. But it should be possible to make your own protocol. SMP is not obligated. You just need to find a way to store the image in the correct slot and then boot to MCUboot to finish the swap.

RE: Can the UART RX/TX pins be also read as GPIO input pins

clockis — Wed, 23 Nov 2022 18:01:15 GMT

Hi Hung,

Thank you very much for your responses they were very helpful and I have the Bootloader & DFU process working for both Serial DFU and OTA using BLE!

I have some followup questions because the documentation is kind of fragmented and convoluted not really citing a specific way of implementing the DFU process (some use SMP Server and others use DFU-Util).

I have used the SMP Server method with a custom private key succesfully and my questions are:

Are the FW images generated when building the application (with the SMP Server & MCUBoot

CONFIG_BOOTLOADER_MCUBOOT) such as app_update.bin & dfu_application.zip encrypted or protected from reverse engineering ( can someone get the source code by using these ) or do I have to enable encryption for the MCUBoot to achieve this? If so how is this done?
I have seen some tickets that use permanent configuration files for the MCUBoot without editing the MCUBoot source files by using a conf file in the child_image directory, but in my project there is no child_image directory thus I cant use a permanent conf file for MCUBoot because I want to add some conf options. How do I make it generate the child_image or alternatively how do I pass permanent configuration options to a child image such as MCUBoot using the VS Code (I have read all the guides and documentation on this and know it can be done by adding arguments to the the west build command but I dont want to do this everytime I want to build my application) Is there a way to specify them in VS Code so that when I press build in the nRF Connect Extension the build command includes those arguments
Is there a better way to have a bootloader and perform DFU (serial & OTA) using something else other than the SMP Server and MCUMgr?

Thank you very much for your time!

Best regards,

Stavros

RE: Can the UART RX/TX pins be also read as GPIO input pins

Hung Bui — Thu, 17 Nov 2022 15:51:23 GMT

Hi Stavros,

Do you have the custom_board.defconfig ?

I believe it's the root cause. I created my own board and got the same issue as you.
But if I copied the .defconfig of the DK board it worked for me.
It should look like this:

# Copyright (c) 2022 Nordic Semiconductor ASA
# SPDX-License-Identifier: Apache-2.0

CONFIG_SOC_SERIES_NRF52X=y
CONFIG_SOC_NRF52840_QIAA=y
CONFIG_BOARD_MYBOARD2=y

# Enable MPU
CONFIG_ARM_MPU=y

# Enable hardware stack protection
CONFIG_HW_STACK_PROTECTION=y

# Enable RTT
CONFIG_USE_SEGGER_RTT=y

# enable GPIO
CONFIG_GPIO=y

# enable uart driver
CONFIG_SERIAL=y

# enable console
CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=y

# additional board options
CONFIG_GPIO_AS_PINRESET=y

CONFIG_PINCTRL=y

I would assume if you dont want to add the config in the board file, you can also add them in the proj.conf.

RE: Can the UART RX/TX pins be also read as GPIO input pins

clockis — Thu, 17 Nov 2022 14:22:33 GMT

Hi Hung,

I have sent the hello_world project and included the board file (with dummy names) inside the project folder. Thank you very much!

devzone.nordicsemi.com/.../serial_5F00_dfu_5F00_hello_5F00_world.rar

RE: Can the UART RX/TX pins be also read as GPIO input pins

Hung Bui — Thu, 17 Nov 2022 14:10:07 GMT

Hi Stavros,
Could you send us your board files and maybe your hello world project so we can test here.

You may think of making a dummy board files to test and send us that if you don' want to send your actual board files.

RE: Can the UART RX/TX pins be also read as GPIO input pins

clockis — Thu, 17 Nov 2022 13:56:07 GMT

Hi Hung,

Thank you very much for the fast response

[quote userid="2121" url="~/f/nordic-q-a/93551/can-the-uart-rx-tx-pins-be-also-read-as-gpio-input-pins/396191"]This meant sparkfun_sara_r4 board configuration has select UART_INTERRUPT_DRIVEN =n but UART_MCUMGR (MCUBOOT SMP)is selecting that symbol as y. I'm not very familiar with the sparkfun shield, but you may want to figure out how to change it to select UART_INTERRUPT_DRIVEN =y[/quote]

I am not using the sparkfun_sara_r4 , in my configuration I have selected our custom board and have succesfully build and flashed our custom application multiple times and something like this has nver been an issue.

Is there some configuration option that selects this board or that implicitly affects these configuration options?

All I did after loading the hello_world sample and flashing it (tested it successfully) on the nRF52840DK is I added a second build configuration using the nRF Connect Extension for VS Code as shown below:

Is there some other configuration,file or something else I should be paying attention to?

I have also tryied adding and removing the same items as the nRF52840DK .dts file in the 'chosen' section of the .dts file of our custom board as well as the same uart and button/led nodes and labels with no success either.

chosen {
		zephyr,console = &uart0;
		zephyr,shell-uart = &uart0;
		zephyr,uart-mcumgr = &uart0;
		zephyr,bt-mon-uart = &uart0;
		zephyr,bt-c2h-uart = &uart0;
		zephyr,sram = &sram0;
		zephyr,flash = &flash0;
		zephyr,code-partition = &slot0_partition;
	};

I have also tryied to set UART_INTERRUPT_DRIVEN to 'y' with no success. I just get errors about other dependecies that are necessary for the SMPSVR to work (as shown in the guide).

Am I missing something?

[quote userid="2121" url="~/f/nordic-q-a/93551/can-the-uart-rx-tx-pins-be-also-read-as-gpio-input-pins/396191"]As far as I know it should work together with the application UART. But I assume you don't plan to connect more than one UART peers to the nRF52 at the same time ? [/quote]

Thank you for the feedback on this its very helpful! No I do not plan on connecting more than one UART at a time.

Any feedback on the issues mentioned above would be very helpful!

Thank you!

Regards,

Stavros

RE: Can the UART RX/TX pins be also read as GPIO input pins

Hung Bui — Thu, 17 Nov 2022 12:12:48 GMT

Hi Stavros,
As mentioned in the log:

warning: UART_INTERRUPT_DRIVEN ...is currently being y-selected by the following symbols:
- UART_MCUMGR (defined at drivers/console/Kconfig:190), with value y, direct dependencies CONSOLE (value: y), and select condition CONSOLE (value: y)

This meant sparkfun_sara_r4 board configuration has select UART_INTERRUPT_DRIVEN =n but UART_MCUMGR (MCUBOOT SMP)is selecting that symbol as y. I'm not very familiar with the sparkfun shield, but you may want to figure out how to change it to select UART_INTERRUPT_DRIVEN =y.

[quote user="clockis"]Also a followup question regarding this approach of DFU process using SMPSVR. Will I be able to use the same UART that the DFU process uses for regular communication and data exchange with other ICs,MCUs etc.??[/quote]

As far as I know it should work together with the application UART. But I assume you don't plan to connect more than one UART peers to the nRF52 at the same time ?

RE: Can the UART RX/TX pins be also read as GPIO input pins

clockis — Wed, 16 Nov 2022 16:11:41 GMT

Hi Hung,

Thank you very much for your imediate response!

I am trying to add the serial dfu functionality described in this guide to an application based on the hello_world sample(with no modifications) on our custom board(before tryng it with our actual custom application).

I have succesfully completed the procedure on a nRF52840-DK but when I specify our custom board as the target(by switching just the build configuration, for the same source files and prj.config files) instead of the DK I get the following error when I try to pristine build:

warning: UART_INTERRUPT_DRIVEN (defined at boards/shields\sparkfun_sara_r4\Kconfig.defconfig:24, boards/shields\wnc_m14a2a\Kconfig.defconfig:17, soc/arm\quicklogic_eos_s3\Kconfig.defconfig:17, drivers/serial/Kconfig:72) has direct dependencies (NETWORKING && SHIELD_SPARKFUN_SARA_R4) || (NETWORKING && SHIELD_WNC_M14A2A) || (SERIAL && SOC_EOS_S3) || (SERIAL_SUPPORT_INTERRUPT && SERIAL) with value n, but is currently being y-selected by the following symbols:
 - UART_MCUMGR (defined at drivers/console/Kconfig:190), with value y, direct dependencies CONSOLE (value: y), and select condition CONSOLE (value: y)

error: Aborting due to Kconfig warnings

CMake Error at C:/ncs/v2.1.0/zephyr/cmake/modules/kconfig.cmake:293 (message):
  command failed with return code: 1
Call Stack (most recent call first):
  C:/ncs/v2.1.0/zephyr/cmake/modules/zephyr_default.cmake:121 (include)
  C:/ncs/v2.1.0/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:66 (include)
  C:/ncs/v2.1.0/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:92 (include_boilerplate)
  CMakeLists.txt:5 (find_package)


-- Configuring incomplete, errors occurred!
FATAL ERROR: command exited with status 1: 'c:\ncs\toolchains\v2.1.0\opt\bin\cmake.EXE' '-DWEST_PYTHON=c:\ncs\toolchains\v2.1.0\opt\bin\python.exe' '-Bc:\ncs\feel_v2_fw\serial_dfu_hello_world\build_1' -GNinja -DBOARD=feel_v2_evb_v1_0_0 -DNCS_TOOLCHAIN_VERSION:STRING=NONE '-DBOARD_ROOT:STRING=c:/ncs;c:/ncs/feel_v2_fw/feel_v2_fw;c:/ncs/feel_v2_fw/feel_v2_fw/src' -DCONF_FILE:STRING=c:/ncs/feel_v2_fw/serial_dfu_hello_world/prj.conf '-Sc:\ncs\feel_v2_fw\serial_dfu_hello_world'

The configuration options that the guide instructed to add worked succesfully when the build configuration selected was the nRF52840DK, so they should be correct.

Am I missing something that should be added other that the configuration mentioned on the guide (maybe in the .dts of our custom board) because everything else is the same and works when I change to the nRD52840DK Build Configuration.

Also a followup question regarding this approach of DFU process using SMPSVR. Will I be able to use the same UART that the DFU process uses for regular communication and data exchange with other ICs,MCUs etc.??

Thank you very much.

Regards

RE: Can the UART RX/TX pins be also read as GPIO input pins

Hung Bui — Wed, 16 Nov 2022 09:25:03 GMT

Hi Stavros,

Could you let me now why you want to build the MCUBoot with no application ?
Our suggested approach is to build the MCUBoot with the application. It's the easiest and most common way of doing it.
Of course you can choose to build and flash only the MCUBoot. You can have a look at the guide here.
To enable serial recovery you would need to define the following configuration for MCUBoot:

CONFIG_MCUBOOT_SERIAL=y

CONFIG_UART_CONSOLE=n

I haven't tried myself but I believe if you want to use USB CDC UART for recovery you would need to define:

CONFIG_BOOT_SERIAL_CDC_ACM=y

RE: Can the UART RX/TX pins be also read as GPIO input pins

clockis — Tue, 15 Nov 2022 11:33:11 GMT

Hi Hung,

I have an additional question regarding the flashing of the bootloader with no application.

Is there a guide or sample that explains the usage and how to flash the MCUBoot without an application in serial recovery mode preferably using USB CDC UART in a custom board?

Thank you.

Regards

RE: Can the UART RX/TX pins be also read as GPIO input pins

Hung Bui — Mon, 07 Nov 2022 15:58:54 GMT

Hi Stavros,

[quote user="clockis"]A followup question, is it possible to have Serial DFU as well as OTA DFU enabled at the same time?[/quote]

No I don't see any problem having both Serial DFU and BLE OTA DFU supported at the same time.

RE: Can the UART RX/TX pins be also read as GPIO input pins

clockis — Fri, 04 Nov 2022 15:43:45 GMT

Hi Hung,

Thank you very much for your immediate response!

This info is very helpful, I wil look into it!

A followup question, is it possible to have Serial DFU as well as OTA DFU enabled at the same time?

Regards

RE: Can the UART RX/TX pins be also read as GPIO input pins

Hung Bui — Fri, 04 Nov 2022 13:38:20 GMT

Hi Stavros,

Regarding your questions:

1. Correct. If you want to implement DFU update in your application you can follow the guide and integrate SMPSVR into your application. Note that MCUBoot also support recovery mode that you can hold a button and enter DFU mode.(CONFIG_MCUBOOT_SERIAL=y) This way you don't need to implement anything in the application.

2. Currently we have the possibility to dynamically configuration a pin with dynamic pinctrl. However, as far as I know it should only be used before the peripheral has been initialized ,as you can read here . I will need to double check with our team to get back to you.
Otherwise you can do what you planning, to connect the pin to two other GPIO pins and then use them as input.