Clock source and GPIO26

RE: Clock source and GPIO26

assafi — Tue, 05 Jul 2016 09:17:30 GMT

What I find more interesting is why other TWI slaves works ok while only this one (connected to GPIO26) cause reset. currently I cant debug the board (only program it and debug using scope), so the breakpoint testing will have to wait...

RE: Clock source and GPIO26

RK — Tue, 05 Jul 2016 06:14:25 GMT

That's ok - if you don't have a crystal mounted those pads are totally available. You've changed the clock source (if you hadn't then the LF clock wouldn't start and the softdevice enable would fail).

Test without the softdevice, but start the RC LF clock at the start of the code and wait for it to start, see what happens then. Because that's what the softdevice is doing.

The chip only resets if you pull the reset line or you get to a piece of code which is resetting it, so again check the error handlers for something returning an error.

RE: Clock source and GPIO26

assafi — Tue, 05 Jul 2016 06:03:50 GMT

My evidence are these posts which seems to have exactly the same problem: Pin P0.26 and P0.27 Unavailable with SoftDevice

SPI slave not working on pins 26,27

Another evidence is that the program running fine without the softdevice.

As i was saying, the error is not when the sofdevice is enabled. The MCU reset itself after 2 writes to the TWI bus.

RE: Clock source and GPIO26

RK — Tue, 05 Jul 2016 00:04:37 GMT

"I understand that this problem is related to the softdevice clock."

What evidence do you have that it has anything to do with the softdevice clock? I can't see any reason it would have anything to do with the softdevice clock. SPI and TWI don't even use the LF clock. More likely you have a call which is returning an error when the softdevice is enabled and APP_ERROR_CHECK() is sending you to the error handler and resetting the device.

Put breakpoints in all the error handlers, look at the reset reason register when you start up, look for a simple answer.