Basic SPI reads and writes

[RodWatt]

Hi,

I have a SPI peripheral connected to the nRF960 DK. In order to access this correctly, I need to be able to write a byte to a specific address first and then read back from specific addresses. 

I can run the basic SPI example

https://github.com/Rallare/fw-nrfconnect-nrf/tree/nrf9160_samples/samples/nrf9160/spi

which carries out a basic loop back. This all works fine but I can't see how to write a specific byte to a specific address or read a specific address.

So, ideally I would like to write 0xD2 to address 0x80, wait 1 second and then read data from address 0x00.

Can you point me to a simple example please?

Ta,
Rod

[RodWatt]

Hi Øyvind,

Ok, I have put the BME280 code to the side for the minute and am just trying to get SPI to work with my own device, a MAX31865. I am basing my code on code that was supplied by Jeff Seaman on this thread.

https://devzone.nordicsemi.com/f/nordic-q-a/42736/problems-with-spi-on-nrf9160-and-zephyr/182841#182841

In this code, Jeff sets up the CS pin using

cs_control.gpio_dev = gpio_dev;
cs_control.gpio_pin = 22;

I have added this and this seems to have fixed my 

[00:00:00.000,061] <inf> spi_nrfx_spim: CS control inhibited (no GPIO device)

problem. I am still playing around with this. Once I have the code tidied up, I will let you know if I have made any progress,

Regards,

Rod

[Jan Tore Guggedal]

Hi Rod,

I tried to reproduce the issues you're seing locally with the BME280 sample, but didn't see the error. I used the overlay and prj.conf that you pasted earlier in the thread. The prj.conf contains a bit of unnecessary configurations for this sample, but I can't see anything that should cause these issues. This hardfault type is typically seen when attempting to use uninitialized memory from non-secure, such as dereferecing a pointer, that points to an address within the secure address space.

To help more, I'd need to know which commit SHA on the -nrf repo you're working on. I assume you have checked out the -nrf repository, then run west update, before moving to <ncs folder>/zephyr/samples/sensor/bme280.

The CS message is caused by the chip select pin not being set in your ovarlay file. If you have a chip select for the chip, you can add this line to the overlay:

&spi3 {
    ...
    cs-gpios = <&gpio0 CS-pin-number 0>;
    
    bme280@0 {
    ...
};

Regards,

Jan Tore

[RodWatt]

Hi Jan,

Thanks for your reply. I will add the cs-gpios... code as above in my overlay file and see if that helps.

I have updated my code base using the following 

cd ncs/nrf
git checkout c1939d963fe2c18013ffb8de0bd8f6fc1d91724d
git checkout -b <choose_branch_name>
west update 

Previously, Øyvind suggested I replace the secure boot code with the new SPM. You will see above that I have tried to install and build this but I keep getting errors. 

Could you have a look at the errors above please and let me know if you see what Im doing wrong

Thanks,

Rod

[Jan Tore Guggedal]

Hi Rod,

If you are on the latest NCS master ("git fetch ncs" and checkout ncs/master or rebase your branch on top of it, then "west update"), SPM will automatically be included when you compile for nrf9160_pca10090ns. It will be compiled and merged with your application, so that when you run "west flash" to program the DK, both SPM and application are programmed together. You don't need to compile and program secure_boot/SPM separately. By default SPI3 instance is then set as non-secure and you should be good to go.

Let us know how it goes.

Regards,

Jan Tore

[RodWatt]

Hi Jan,

So just to clarify the update process, (sorry for this, I just want to check I'm not missing any steps.)

cd ncs
git fetch ncs
west update 

I am then building my application and flashing as follows

cmake -GNinja -DBOARD=nrf9160_pca10090ns ..
ninja flash

Regards,

Rod