nRF5340 peripheral selection w/Engineering A silicon - comments please

[navigator]

Hi everyone,

Currently I am routing hardware for an upcoming project using the nRF5340 and it's time for a sanity check.

The goal is that the HW works well enough w/Engineering A samples for initial development.
I reviewed the errata for Engineering A samples (included on nRF5340-PDK reference board).

I am interested the concurrent resource availability and functionality of the following nRF5340 peripherals.
Any comments are welcome regarding issues that I might encounter.

I am planning to run both cores at 64 MHz.

UARTE0 and UARTE1 both running at ~460 kbaud w/DMA
QSPI running at 64MHz w/DMA
SPIM0 running at 4MHz, no DMA
SPIM4 running at 8MHz w/DMA
TWIM0 (I2C) running at 1000 kHz, no DMA
TWIM1 (I2C) running at 390 kHz, no DMA

Any problems I should know about in Nordic Connect SDK 1.2.0 targeting these peripherals?

Thanks for your help!

[navigator]

Yeah, I'm starting to see this is not going to work at all.
  
I get to pick one: SPIM0 or TWIM0 or UARTE0
I get to pick one: SPIM1 or TWIM1 or UARTE1
I get to pick one: SPIM4 or TRACEDATA
I get to pick one: SPIM2 or TWIM2 or UARTE2  (but none of these work in Engineering A silicon)
I get to pick one: SPIM3 or TWIM3 or UARTE3  (but none of these work in Engineering A silicon)
QSPI comes without conflict.

So I am going to need to cut back.   I knew it was looking too easy.   Can I run all three SPI slaves with same QSPI peripheral using different CSN lines....when only one slave supports QSPI, the others are straight SPI ?   Does the QSPI peripheral allow me to I mix and match using some config magic, or does it only service QSPI slaves?

Thanks!

[Einar Thorsrud]

Hi,

The QSPI peripheral can only be used for QSPI.

Regarding the general issue of not having enough peripherals to use concurrently, I would like to mention that unless you need all enabled simultaneously, you could aways reconfigure the peripheral. For instance, you could use both SPIM0 and TWIM0 in the same product, just that you would have to disable SPIM0 in order to enable TWIM0, and so on.

[navigator]

Thanks Einar, I understand.   Could you be so kind as to point me to a code snippet of the best practice technique to disable/reenable a peripheral as you suggest?   

[Einar Thorsrud]

Hi,

The Device Tree approach used in Zephyr does not work with having the same pins for several peripherals, so you need to use the nrfx drivers directly. Then, you basically follow this approach:

1. Initialize the peripheral when you need it.
2. Use it
3. Uninitialized peripheral when done.
4. Now you can do the same with the other peripheral of the same ID, since the first peripheral is no longer in use. And so on...

Taking SPIM as an example, this means that for step 1 you initialize it with nrfx_spim_init(), use it as described in the API doc and uninitialized it with nrfx_spim_uninit().

You can refer to nRF91 nrfx example to see an example of how to use nrfx drivers directly (there is no example specifically for nRF5340, but the principles are the same).

[navigator]

Thanks Einar for pointing me in the right direction

Regarding my original plan..

I will use SPI sequentially instead of concurrently, with 3 slave CSNs  using SPIM4 w/DMA.

I will use 4 pins for I2C, on 2 buses -- separating high speed from low speed devices.  Since I have only one peripheral available, I will use TWIM1 and need to init / un-init each time I want to switch between the two buses.   I do it this way so when the next rev of silicon comes (and errata 1000kHz gets fixed), I don't have to change my layout, just drop in the new chip, and change the SW to use the new dedicated TWIM2.  

Lastly I will use UARTE0, and get rid of the concurrency, but talk to two devices.  I will alternate between talking to the devices on different pins using init/un-init, then later when the new silicon arrives, I can use dedicated UARTE3 and keep my layout.  It will need a little handshaking to turn off the remote transmit when there is nobody home to receive....

Thanks for help!