@Dan I appreciate your support in this. But of course, your insight is similarly limited like mine…
In the mean time I did not find the smoking gun, but at least some sort of smoke. The data sheet of the DW1000 suggests that in SPI mode 0 data on MOSI is sampled with the rising clock edge and output on MISO with the falling clock edge (table 17 on page 25). Figure 22 on page 23 suggests that with mode 0 (SPIPOL=0 & SPIPHA=0) both data sampling and output is done with the rising edge. This is conflicting with table 17. But anyway, my oscilloscope is telling me clearly that data provided on MISO is changed with the rising clock edge and not with the falling edge.
Initially I set up the SPI system of the Kinetis uC to be compatible with figure 22. As long as the PMSC register is not written in _dwt_enableclocks() everything seems fine. That is, although the DW1000 is changing MISO at the rising edge, the timing is still ok for the Kinetis uC. But writing the PMSC register is changing the situation. In particular, a 0x01 is written into PMSC[0], which means that the system clock is set to a “19.2MHz XTI clock”. Apparently this is changing SPI timings and thing are going [mostly] nuts from this moment on. My guess is that they are ok again when the system clock setting in PMSC[0] is set back to its normal value.
Right now I’m trying to get a working setup by playing around with SPIPOL and SPIPHA as well as SPI settings in the Kinetis uC. I’ll come back with a solution, hopefully…
In the mean time I did also find that thread in the forum:
Things are a bit different here, but also similar. The sporadic errors reported there might also be a result of some SPI issues during device initialization. Unfortunately, the thread does not discuss the matter to the end. @jbmillard maybe you can let us know what was your final solution here?
Thanks and regards,
Mario