cgnd_chris

@aldras thanks so much for posting this!

I ran into a similar issue this weekend and just found this post after pulling my hair out the last 2 days trying to troubleshoot… (we’ve got a CAN controller hooked up to the SPI3 peripheral on the SparkFun Thing Plus - nRF9160 and after upgrading from v2.3.0 to v2.4.1 the CAN interface stopped working).

I ended up using @jaredwolff suggestion to add a board-specific overlay in the child_image/mcuboot/boards directory that just deletes the w25q32jv node from the devicetree for this board (we’re not currently using it):

/delete-node/ &w25q32jv;

jaredwolff FYI, I already tried adding an RC filter (100nF/1kΩ) to the nRESET on the nRF91 (basically the same thing they have in the datasheet C10/R2). I didn’t notice any change in behavior with the RC added, but let me know if you see something different.

jaredwolff Thanks for double checking this. Do you happen to have the nRF91 dev kit? Do you see the same behavior on that board as well? I’m just curious if this is expected behavior for this chip, or due to something on the board itself. (I only have one of the Thing Plus boards, so I can’t check this out myself)

I’m seeing some surprising behavior on the SparkFun Think Plus nRF9160 board and I’m wondering if it’s a bug or expected behavior.

If I hold the RESET button (causing the nRF9160 nRESET pin to be held at low at 0V), and plug in the USB cable, the board boots up and starts running the firmware. However, if I release the reset button and then press it again, the firmware stops running, and the board reboots when I release the reset button again.

It appears that the firmware will boot when power is initially applied to the board, irrespective of the state of the RESET pin. Is this expected behavior?