This one is weird. On a new board with a Rev C '840, when trying to reset the processor using 'nrfjprog --program nuttx.hex --sectorerase --erase', a Decawave DW1000 connected to the '840 via SPI can't synchronize it's clock. If I power cycle the board, then everything including the DW1000 comes up without a problem. In both cases, we drive the DW1000's reset line low to reset its state.
The same design on an earlier Rev B '840 works either way I 'reset' it.
I'm at a loss to explain how a JTAG/SWD reset of the '840 would impact the ability of the DW1000 to come out of reset and synchronize its clock. I haven't a clue as to whether this is a Nordic, Decawave, Segger or my issue. I'm open to ideas.
When programming using nrfjprog, it leaves the nRF in a halted state unless you do a "nrfjprog --run" or a "nrfjprog --reset" afterwards. Could this be the issue?
Sorry, I typed the nrfjprog command incorrectly into the message above. The '--erase' option should have been '--reset' so the whole command I flash the device with is:
nrfjprog --program nuttx.hex --sectorerase --reset
and just plain
will also cause the '840 to wait forever for the DW1000 to synchronize its clock. Both GDB and the output of our code confirm that the '840 is running, reading the status bit from the DW1000, and looping over and over.
There's some kind of weird coupling between the '840 being reset by the J-Link and the DW1000 not coming out of reset correctly.
Unfortunately, I do not have any experience with the DW1000 IC, but this sounds like an initialization issue. Reprogramming and resetting the nRF will not automatically reset the DW1000, unless you actively do so as a part of the nRF startup routine. Could the DW1000 be in a state where it is awaiting specific commands from the nRF?
The DW1000 reset sequence is to pull the RSTn line low for 500us, then wait for the STATUS.CPLOCK bit to be set to 1. It's that waiting for the bit to be set to 1 is where we have a 75% chance of hanging forever.
The same code doing the same reset procedure works 100% of the time on a Rev. B '840 board and the '832 in Decawave's DWM1001 module.
The fact that the DW1000 does successfully reset ~25% of the time makes me believe that something on the Rev C board is marginal. The question is what is marginal? A chip? A pullup? A route? A placed component? ...
Back to looking at the Gerbers.
How do you handle the DW1000 RSTn pin? The DW1000 datasheet has its own chapter on handling this signal, so it seems that bad behavior can occur if it's sourced externally. The nRF GPIO controlling this signal should be configured with PIN_CNF[n], field DRIVE = S0D1 (or H0D1) to avoid this scenario.