Clock source and GPIO26

[assafi]

Hi,

Im using a custom board running a program based on 'ble_app_hids_mouse (pca10028)' project, softdevice S130.

Since there is no 32.768 kHz crystal on my board, the sofdevice clock source is set to

NRF_CLOCK_LF_SRC_RC

with:

rc_ctiv = 16

rc_temp_ctiv = 2

The program running okay and there are no problems. there are SPI and TWI slaves connected to some GPIO's. The problems starts when a TWI slave is connected to GPIO26 and GPIO24. When I try to use those pins, it cause the MCU to reset over and over. When i run the same program without softdevice, everything works fine.

I understand that this problem is related to the softdevice clock. How can I make it work?

Thanks

[RK]

"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.

[assafi]

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.

[RK]

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.

[assafi]

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...