• State Not Answered
  • Replies 8 replies
  • Subscribers 64 subscribers
  • Views 1118 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 278584
Options

Need P0.14 as input on nrf9160

NordicSwissTom

Hi, my app (nrf9160 ns, on DK 1.0 rev.; ncs 1.6.0 ) needs the port pin P0.14 as digital INput (wired on the arduino header, for a shield!!).
But something is blocking it from following the applied HI:1 level, it always stays LO:0!
Read both in SW as well with a multimeter (my INput setting includes pullup active).

NOTE: of course I programmed the board controller 52840 to route P0.14/P0.15 (to arduino), per overlay
   &vcom2_pins_routing { status = "okay"; };

NOTE: I know my code works, because with the other pin P0.15 the INput works as expected.
I'm using the nrfx-layer GPIO api.

NOTE: when hard-wiring the P0.14 to VDD, I read HI:1 in app; but this is bad overdriving an output, thus no real option and drives massive current.

Now, the DK-UG manual indicates there is an uart (the DTS says uart1?) using this pin P0.14 as RTS (output!?), while P0.15 is the CTS input.
Therefore, I guess my other tests did work with P0.15 as input - BUT P0.14 is stolen fixed as output, set=LO:0.

So I also tried at SPM :
to add an spm.conf with
CONFIG_SPM_NRF_UARTE2_NS=y
CONFIG_SPM_NRF_UARTE1_NS=y
plus cmake line: set(spm_CONF_FILE prj.conf ${CMAKE_CURRENT_SOURCE_DIR}/spm.conf )

as well added spm.overlay with
&uart1 {
status = "disabled";
};
&uart2 {
status = "disabled";
};
plus cmake line: set(spm_DTC_OVERLAY_FILE "${CMAKE_CURRENT_SOURCE_DIR}/spm.overlay" )

Resulting all the generated files
... \spm\zephyr\nrf9160dk_nrf9160.dts.pre.tmp
... \spm\zephyr\zephyr.dts
do reflect status = "disabled" (for all uarts).

All I get then is a spurious error at start (stack: z_arm_exc_spurious).

Another point, some tests before showed:
  NRF_UARTE2 Secure SKIP
on the boot (VCOM) log. What is owning uarte2? relates to P0.14?

Thanks

Parents
  • 0

    Hi,

     

    As you have figured out, the default pins for the UART are directly connected to the debugger IC by default.

    In order to disable this routing, you have to clear P1.12 on the nRF52840 side:

    https://infocenter.nordicsemi.com/topic/ug_nrf91_dk/UG/nrf91_DK/board_controller.html

     

    You should add this to the nrf9160dk_nrf52840 project to disable it:

       &vcom2_pins_routing {
           status = "disabled";
   };

     

    Kind regards,

    Håkon

  • 0 in reply to Håkon Alseth

    Hi, thanks - but as I wrote I tried that long ago,
    the routing (of course) has no effect on the physical nrf9160 pin functionality!

    I also found when using an spm.conf with lines:
      CONFIG_NRFX_UARTE2=n
      CONFIG_SPM_NRF_UARTE2_NS=y
    it did disable uarte2 in the generated spm source files, but with no effect on pin ownership or in/out setting.
    And the boot log still tells secured UARTE2:
      Peripheral -Domain -Status:
      00 NRF_P0 Non-Secure OK
      01 NRF_CLOCK Non-Secure OK
      05 NRF_UARTE1 Non-Secure OK
      06 NRF_UARTE2 Secure SKIP


    My conclusion so far:
    the 4 pins of VCOM2 (aka APP2, or schematics 1.0 group nRF91_UART_2)
    are stolen by the Modem-Trace functionality inside the proprietary modem firmware (using 1.3.0).
    I also tried
    AT%XMODEMTRACE=0
    to ensure the trace is OFF, no luck.

    Therefore: the DK headers are simply NOT arduino compatible, P0.00, P0.01, P0.14, P0.15
    can never be used and even worse have fixed voltage levels.
    So we can't use standard shields without risk of damage.
    This should be documented in big letters in the DK-UG.

Reply
  • 0 in reply to Håkon Alseth

    Hi, thanks - but as I wrote I tried that long ago,
    the routing (of course) has no effect on the physical nrf9160 pin functionality!

    I also found when using an spm.conf with lines:
      CONFIG_NRFX_UARTE2=n
      CONFIG_SPM_NRF_UARTE2_NS=y
    it did disable uarte2 in the generated spm source files, but with no effect on pin ownership or in/out setting.
    And the boot log still tells secured UARTE2:
      Peripheral -Domain -Status:
      00 NRF_P0 Non-Secure OK
      01 NRF_CLOCK Non-Secure OK
      05 NRF_UARTE1 Non-Secure OK
      06 NRF_UARTE2 Secure SKIP


    My conclusion so far:
    the 4 pins of VCOM2 (aka APP2, or schematics 1.0 group nRF91_UART_2)
    are stolen by the Modem-Trace functionality inside the proprietary modem firmware (using 1.3.0).
    I also tried
    AT%XMODEMTRACE=0
    to ensure the trace is OFF, no luck.

    Therefore: the DK headers are simply NOT arduino compatible, P0.00, P0.01, P0.14, P0.15
    can never be used and even worse have fixed voltage levels.
    So we can't use standard shields without risk of damage.
    This should be documented in big letters in the DK-UG.

Children
Related