SPI transfer is not working successfully

[shilpa]

Hello,

I am using SDK 15.2.0, nrf52840, s140.

We are using SPI for an analog Front End initialization. SPI initialization works successfully done. But when we read or write to the registers of the IC  using SPI transfer functions, the transfer is not done successfully.

I have connected the SPI clock pin to the RESET pin of BMD 340 (P0.18) in my custom board. Whether this can cause an issue? I am able to program each pin(MOSI, MISO, CLOCK, CHIPSELECT checked by setting the pin using nrf_gpio_pin_set) .

Regards,

Shilpa

[awneil]

shilpa said:

I have connected the SPI clock pin to the RESET pin of BMD 340 (P0.18)

Why do that?

Why not just use any other "normal" GPIO pin - and avoid all doubt?

shilpa said:

Whether this can cause an issue?

You will need to correctly configure your project for this option.

The obvious way to answer the question is to look at the SPI lines with an analyser or oscilloscope - that will show you if they are behaving as required.

Whether or not re-purposing RESET as a GPIO is an issue for the SPI, it means that you lose the function of the external reset.

IMO/IME that is a Really Bad Idea! You are storing up troubles for yourself!

See:  https://devzone.nordicsemi.com/f/nordic-q-a/48137/not-able-to-scan-twi-sensors-when-pins-are-changed/191067#191067

[shilpa]

Hai,

awneil said:

Why not just use any other "normal" GPIO pin - and avoid all doubt?

Actually when we design our custom board, we assigned this pin to the SPI clock without bothering the pin functionality. This was actually a mistake from our part.

Do we have any solution to this?

Can we make any other changes to make this solve?

can we do anything with CONFIG_GPIO_AS_PINRESET .

I read that disabling CONFIG_GPIO_AS_PINRESET could works, but not sure.

If so, how to disable CONFIG_GPIO_AS_PINRESET.

Regards,

Shilpa.

[awneil]

shilpa said:

Do we have any solution to this

If you've done the board design, then you're stuck with it until your next re-spin.

shilpa said:

without bothering the pin functionality. This was actually a mistake from our part

Indeed!

Very important to pay attention to pin functionality!

This is why it's a good idea to prototype first on a dev board!

shilpa said:

Can we make any other changes to make this solve

You haven't actually identified what the issue is yet.

Again:

awneil said:

look at the SPI lines with an analyser or oscilloscope - that will show you if they are behaving as required

[shilpa]

Hello,

awneil said:

look at the SPI lines with an analyser or oscilloscope - that will show you if they are behaving as required

Yes I will definitely go with it.

So as I you specified is not at all possible to find any solution for the same.?

shilpa said:

can we do anything with CONFIG_GPIO_AS_PINRESET .

I read that disabling CONFIG_GPIO_AS_PINRESET could works, but not sure.

If so, how to disable CONFIG_GPIO_AS_PINRESET in segger embedded studio.

Regards,

Shilpa

[Jørgen Holmefjord]

shilpa said:

If so, how to disable CONFIG_GPIO_AS_PINRESET in segger embedded studio.

This config is set in the preprocessor symbols. Please have a look at this video tutorial about where to find this in SES. 

[shilpa]

Hi,

Could CONFIG_GPIO_AS_PINRESET resolve the issue?

Regards,

Shilpa

[Jørgen Holmefjord]

shilpa said:

Could CONFIG_GPIO_AS_PINRESET resolve the issue?

That is not easy for me to answer, you did not describe the problem much beyond saying it does not work. I suggest you try it and post some screenshots of what happens on the SPI lines.