This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Shell on NRF9160

Is anyone else having issues with the Zephyr shell on the NRF9160 DK? We weren't able to get it working on our code, so we went back to the coap_client applications in the nrf/samples directory, and added the following lines to the end of the prj.conf file:

# Shell
CONFIG_SHELL=y
CONFIG_SHELL_BACKEND_SERIAL=y
The result is that the prompt is output on the serial port (the same one that is logging) but it doesn't respond to any input.
The same config lines work fine on an NRF52840-based application.
Any help would be appreciated.
Cheers!
Parents
  • I was able to make the shell work with the nRF9160, try executing these steps:

    • Open <..>\ncs\zephyr\samples\subsys\shell\shell_module in cmd
    • Type in "west build -b nrf9160_pca10090ns"
    • Type in west flash
    • Open  a serial terminal (e.g. Termite) and type in "version"
    • See if you get the Zephyr version in response

    Best regards,

    Simon

  • Hi Simon,

    Thanks for looking into this. Yes, I can get the vanilla shell sample from Zephyr working fine on both an nrf52840 and the nrf9160 DK. The issue seems to be the combination of LTE and the shell subsystem. I took the proj.conf lines from the shell sample and added them to each of the proj.conf files in the nrf/samples/nrf9160 directory. Here are the results:

    • at_client: prints prompt, but unresponsive to terminal input.
    • coap_client: prints prompt, but unresponsive to terminal input.
    • gps: looks like it works, but of course the scanning indicator is overwriting it.
    • http_application_update: works fine.
    • lte_ble_gateway: faults, with or without prj.conf changes, but I didn't read the instructions, so probably something I messed up.
    • mqtt_simple: prints prompt, but unresponsive to terminal input.
    • spm: didn't try this one.

    I was wondering if there was a conflict between the LTE modem and the terminal, but the logging seems to work just fine. Also, the http sample works.

    Now that I have working and non-working LTE samples, I can start slicing and dicing to find the issue, but any hints would be appreciated.

    Thanks!

Reply
  • Hi Simon,

    Thanks for looking into this. Yes, I can get the vanilla shell sample from Zephyr working fine on both an nrf52840 and the nrf9160 DK. The issue seems to be the combination of LTE and the shell subsystem. I took the proj.conf lines from the shell sample and added them to each of the proj.conf files in the nrf/samples/nrf9160 directory. Here are the results:

    • at_client: prints prompt, but unresponsive to terminal input.
    • coap_client: prints prompt, but unresponsive to terminal input.
    • gps: looks like it works, but of course the scanning indicator is overwriting it.
    • http_application_update: works fine.
    • lte_ble_gateway: faults, with or without prj.conf changes, but I didn't read the instructions, so probably something I messed up.
    • mqtt_simple: prints prompt, but unresponsive to terminal input.
    • spm: didn't try this one.

    I was wondering if there was a conflict between the LTE modem and the terminal, but the logging seems to work just fine. Also, the http sample works.

    Now that I have working and non-working LTE samples, I can start slicing and dicing to find the issue, but any hints would be appreciated.

    Thanks!

Children
  • OK, a quick update on this one, in case anyone else runs into this issue. It does appear to be a UART conflict, as setting CONFIG_AT_HOST_LIBRARY to "n" allows the shell to function properly. Also, setting CONFIG_AT_HOST_LIBRARY to "y" and CONFIG_AT_HOST_UART_1 to "y" (i.e. rather than the default UART_0) also allows the shell to work, although some errors appear on the console. In both cases, our application works fine, and I don't see any difference in the behavior of the sample apps either. Our app uses a custom link control, and I don't see any difference in the traces, including unsolicited AT responses.

    Seems odd, since AT HOST UART sounds awfully important. Perhaps someone from Nordic can comment on why LTE comms seem to be still working with AT_HOST_LIBRARY disabled.

    Unless anyone sees any issues with disabling that config item, I'm considering this one resolved from my perspective, and we're moving on to other fish that need frying.

    Thanks,
    Chris.

  • krog1 said:
    Seems odd, since AT HOST UART sounds awfully important. Perhaps someone from Nordic can comment on why LTE comms seem to be still working with AT_HOST_LIBRARY disabled.

    The AT host library makes it possible to send AT commands through UART to the modem by using the  LTE Link Monitor. If your application doesn't need this, you can disable it in the prj.conf.

    Best regards,

    Simon

Related