Are there any limitations on the GPIOs I assign to peripherals on a custom board I am making for the nRF9151? Are there particular GPIOs that would be 'better' assigned for specific protocol ports (i.e. I2C, SPI, UART)

I am currently working on creating a custom PCB which features an nRF9151 module. I am currently working on pin assignment for our peripherals. Given Zephyr uses a device tree, it appears that any GPIOs on the nRF9151 can be assigned to any particular peripheral. I have worked with ESP32 in the past, and I know some of the 'GPIOs' they list, are actually reserved for specific things like communicating with an external flash chip etc. I would appreciate confirmation from one of your engineers that we may use any of the available GPIOs, other than those obviously labeled for things such as SWD and Trace, for our peripheral connection. This would make our PCB design much easier, as we could design our firmware and device tree around whichever GPIOs we  have selected to make routing traces simpler on the PCB. 

For a summary we will require the following peripherals and associated protocols:

  • 2x UART ports
  • 1x I2C port
  • 2x SPI port  (one for an external flash chip)
  • 8 GPIOs , 2 with hardware interrupts. 
  • Any external debugger pins (SWD and trace pins needed

I would like confirmation that

1. We can use all of these concurrently on a single nRF9151 chip.  (There seems to be more than enough GPIOs, its just a matter of their abilities) 

2. We are free to assign any of these GPIOs to any of the listed protocols / ports / peripherals so that we can be confident moving forward with our pin assignment and traces on the PCB.

For refernce I have completed the nRF Connect SDK fundamentals course, but have not yet started the Intermediate course. That being said the answer to this question would allow our hardware engineers to continue their work while I move onto completing these courses.

Thank you!

Parents Reply Children
  • Thank you for sharing those resources ! 

    What do you mean by 'at once' ? It seems I will have threads responsible for interacting with each peripheral, although given the nRF9151 only has one application core there will only ever be one thread active at a time. 



    To be more specific these are the responsibilities of the peripherals:

    • UART - For viewing debug print logs during firmware development and for testing. 
    • UART - For interacting with an RS232 transceiver to talk to another device.
    • I2C / TWI (master) - 
      • Device 1 - BME280 
      • Device 2 - ISL28022 
    • SPI (master) -
      • Device 1 - For interacting with an external ethernet controller (such as the Wiznet W5500) and communicating data to a server in the event that cellular network is not available.   
      • Device 2 - For interacting with an external flash chip. We plan on implementing FOTA updates and potentially using this for NVS of data if network connection is not available from either Cellular or Ethernet interfaces. 
    • SWD, Trace logging , and RTT - For flashing and debugging our device using an external debugger

    Does SWD / Trace pins / RTT provide me the ability to view LOG prints (as If I were to use printk or the logging library)? If this is the case then I should not need a second UART port for this purpose. I noticed RTT or SWD are not included in that memory map list. I have used JTAG with ESP32 before, although I not yet explored SWD and ETM or ITM tracing. 

    I would like to have all of these configured in a single firmware image. Our device is being designed such that it is installed on a site, and ideally left untouched for as long as possible. 

    Please let me know your thoughts on this, and whether or not there are some other peripherals or things with overlapping address space I have not considered that may be an issue moving forward.

    Apologies for the beginner level questions, I greatly appreciate your engineers support. I am trying to learn the architecture and SDK while my hardware team works in parallel, but they need answers ASAP to continue with progress. 

    Thank you very much for your time. 

Related