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

[clockis]

Greetings,

We are using the NCS for the development of a new product with a custom board based on the nRF52840 MCU.

First, we would like to use the Serial DFU feature to update the firmware over UART. I have found and will be implementing this guide for that. Please confirm that this is indeed correct.

Second we want to also use the same lines(RX/TX) as GPIOs (inputs) and read their status. What way would you suggest going about this? I have found this suggestion usefull (connecting the TX/RX lines to two other available GPIO pins to also read the level of the TX/RX lines) as we will not be using the UART interface and reading the same lines simultaneously.

What are your thoughts and suggestions on implementing this? Will connecting two other GPIO pins on the RX/TX lines cause issues to the UART even if we do not read the pins while the UART interface is in use?

Thank you very much and I look forward to hearing from you!

Best regards,

Stavros

[Hung Bui]

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. 

[clockis]

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

[Hung Bui]

Hi Stavros, 

clockis said:

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

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

[clockis]

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

[Hung Bui]

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

[clockis]

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