Our nRF52840 is communicating with a peripheral chip (let's call it FOO) through an SPI interface. The FOO chip can be configured to use either TWI or SPI on the same pins (well TWI uses a subset of the SPI pins), the default mode after FOO reset is TWI and a register TWI_DISABLE in FOO has to be configured to ensure that TWI does not risk to spoil SPI by accident.
We need SPI, because the TWI does not have sufficient throughput to use all of the features of the FOO chip.
When the FOO chip starts up, the TWI_DISABLE is not set, so FOO is in a sort of blind detection mode in which it will accept both SPI and TWI at the same time. In this blind mode, the TWI cannot be disturbed by the SPI, because the SPI needs chip select (CS) pin active, and the CS pin default setting is inactive when in TWI mode. However, the converse statement is not true : theoretically it is possible that bad luck causes that you accidentally have TWI acting while in SPI and make the SPI link fail.
It is possible after startup of FOO to make a loop so that, while communicating in SPI, you write the TWI_DISABLE register and check it by reading it afterwards until TWI_DISABLE is really set, and then you are OK. We checked this solution and it is working fine to do so and seems to be the standard approach.
However that sounds like a dirty solution that we cannot guarantee will always in all circumstances and over millions of items work. We would like to make it really bulletproof and another solution is to start to communicating with FOO over TWI, write the TWI disable register of FOO so that the TWI is disabled in FOO, and then we are OK too for using SPI safely.
We checked this solution too with some quick and dirty test FW and it works fine. However it is not possible to make it easily with the Nordic SDK 15 because the SDK ensures at compile time that you cannot use the same HW peripheral in TWI and in SPI. Say for instance that I want to use SPI0 to communicate with FOO, then I cannot enable TWI0 too, even though there would not be any conflict because the FW would use TWI0 only for a short time at the beginning just to set TWI_DISABLE FOO register and then be uninit'ed.
It is not possible for us to use TWI1 instead of TWI0 because all the HW ressources of nRF52840 are taken in our application, so if we go to the bulletproof solution we really need to reconfigure dynamically (at runtime, not at compile time) the same nRF52840 peripheral. The nRF52840 HW allows this, but this is a limitation of the SDK that makes it impossible. This limitation is really quite usefully and a very good idea for most of the cases because it prevents people from having HW conflicts in their design, however, in our very specific corner case it is preventing us to make it.
Your support is most welcome…
