nRF5340 some question

[CheMax]

Hello, We were interested in a new SoC nRF5340, but I would like to determine some points in advance:

1. peripheral blocks remained the same as in nrf52840. Or were changes / new functionality added?
2. can you clarify in more detail what is peripheral RAM used for? If all memory is available as a single region, then why is this separation introduced (256 kB CPU single-cycle RAM / 256 kB of peripheral RAM)?
3. Has the SDK structure changed (nRF_Connect_SDK)?  I realized this is another SDK for other purposes. A little confusing the name, to be honest. I will change the question: when is it approximately worth waiting for support for a new chip in the nRF5_SDK_x.x.x?
4. Is freeRTOS (or segger embos) support expected?
5. a curiosity question: in the same case size (qfn 7x7), you have more filling (2 cores, more memory) and less current consumption in receive / transmit mode by about 1.5 times. Have you switched to another process technology?

Thanks,

Maxim

[ovrebekk]

Hi 

1. The peripherals have more in common with the peripheral architecture in the nRF9160, but on the register level they are more or less identical to the nRF52 implementation. 

The main difference between the nRF52840 and the nRF5340/nRF9160 is that the UARTE interfaces are now sharing peripheral index with the TWIM/TWIS/SPIM/SPIS interfaces, which means that using a UARTE interface leaves you with one less TWIM/TWIS/SPIM/SPIS interface. 

2. Apparently the designers were unable to get the entire RAM to run single cycle at the full 128MHz frequency, and had split the RAM in half in order to ensure consistent timing between the CPU and the RAM. 

The reason the slower RAM block is referred to as peripheral RAM is because the peripherals run at a slower clock internally (16MHz), and see no timing difference regardless of which block is used. 

3. We are not planning to add support for the nRF5340 in the current nRF5 SDK. Instead all future product will be supported on NCS only, as we don't have the resources to support both platforms. 

Part of the reason for the move to NCS/Zephyr was that this platform scales much better across a wider range of SoC devices, with different number of cores etc. 

4. I don't believe so, since NCS uses the Zephyr RTOS at it's core. I will double check to be sure. 

5. I will have to check what I can share on the process technology, but in general keep in mind that the nRF52840 die is only about 3.6mm squared (the CSP packet is essentially the size of the die), so there is some room in the QFN 7x7mm package for a larger chip. 

Best regards
Torbjørn 

[CheMax]

Hi, thanks for your answers.

1. critical, but not deadly, I think. Thus, it turns out that the maximum number of independent interfaces (SPI / TWI / UARTE) is 3 for application core and 1 for network core? 

2. Ok, i undestand

3. Does this mean that I should use nRF_Connect_SDK for nRF52840? 

4. Ok, a little sad from such a choice, but maybe this is the right decision.

5. the question was more likely connected with the desire to predict the possible sizes of finished modules using this chip.

[ovrebekk]

Hi

1. That is correct. The app core has a maximum of 3 interfaces, out of which one can only be SPI master. The network core has a maximum of one. 

3. You can, but it is not officially supported at the moment.
This means we don't test NCS for the nRF52840 the same way we do for the nRF5340, and the support we provide is limited compared to using the nRF52840 on the nRF5 SDK. 

4. We like to work with open consortiums, rather than standards maintained by a single company (such as freeRTOS). Zephyr has a strong backing from the open source community, and is optimized for the kind of applications we are targeting, which is part of the reason for going with it. 

That said I do realize it's a bit of a learning curve if you're used to freeRTOS...

5. Since there is no CSP option for the nRF5340 you should expect modules to be larger than those using the nRF52840 CSP package, but if the modules use the QFN there should be no difference. 

Best regards
Torbjørn