This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF9160 DK SPI Example causing hard fault.

I am trying to get a simple spi setup working. Through the dev zone I found a link to this https://github.com/Rallare/fw-nrfconnect-nrf/tree/nrf9160_samples/samples/nrf9160/spi repository.

I was successful in getting the uart example from the same repository to build and run on my nRF9160 DK. However when I attempt to run the spi example it results in the ***** HARD FAULT **** that can be seen in the serial output below. I have attached my nrf9160_pca10090.overlay prj.conf and main.c files

Serial output

***** Booting Zephyr OS v1.14.99-ncs1 *****
Flash region..Domain..Permissions
00 0x00000 0x08000 .Secure..rwxl
01 0x08000 0x10000 .Non-Secure.rwxl
02 0x10000 0x18000 .Non-Secure.rwxl
03 0x18000 0x20000 .Non-Secure.rwxl
04 0x20000 0x28000 .Non-Secure.rwxl
05 0x28000 0x30000 .Non-Secure.rwxl
06 0x30000 0x38000 .Non-Secure.rwxl
07 0x38000 0x40000 .Non-Secure.rwxl
08 0x40000 0x48000 .Non-Secure.rwxl
09 0x48000 0x50000 .Non-Secure.rwxl
10 0x50000 0x58000 .Non-Secure.rwxl
11 0x58000 0x60000 .Non-Secure.rwxl
12 0x60000 0x68000 .Non-Secure.rwxl
13 0x68000 0x70000 .Non-Secure.rwxl
14 0x70000 0x78000 .Non-Secure.rwxl
15 0x78000 0x80000 .Non-Secure.rwxl
16 0x80000 0x88000 .Non-Secure.rwxl
17 0x88000 0x90000 .Non-Secure.rwxl
18 0x90000 0x98000 .Non-Secure.rwxl
19 0x98000 0xa0000 .Non-Secure.rwxl
20 0xa0000 0xa8000 .Non-Secure.rwxl
21 0xa8000 0xb0000 .Non-Secure.rwxl
22 0xb0000 0xb8000 .Non-Secure.rwxl
23 0xb8000 0xc0000 .Non-Secure.rwxl
24 0xc0000 0xc8000 .Non-Secure.rwxl
25 0xc8000 0xd0000 .Non-Secure.rwxl
26 0xd0000 0xd8000 .Non-Secure.rwxl
27 0xd8000 0xe0000 .Non-Secure.rwxl
28 0xe0000 0xe8000 .Non-Secure.rwxl
29 0xe8000 0xf0000 .Non-Secure.rwxl
30 0xf0000 0xf8000 .Non-Secure.rwxl
31 0xf8000 0x100000 .Non-Secure.rwxl

SRAM region..Domain..Permissions
00 0x00000 0x02000.Secure..rwxl
01 0x02000 0x04000.Secure..rwxl
02 0x04000 0x06000.Secure..rwxl
03 0x06000 0x08000.Secure..rwxl
04 0x08000 0x0a000.Secure..rwxl
05 0x0a000 0x0c000.Secure..rwxl
06 0x0c000 0x0e000.Secure..rwxl
07 0x0e000 0x10000.Secure..rwxl
08 0x10000 0x12000.Non-Secure.rwxl
09 0x12000 0x14000.Non-Secure.rwxl
10 0x14000 0x16000.Non-Secure.rwxl
11 0x16000 0x18000.Non-Secure.rwxl
12 0x18000 0x1a000.Non-Secure.rwxl
13 0x1a000 0x1c000.Non-Secure.rwxl
14 0x1c000 0x1e000.Non-Secure.rwxl
15 0x1e000 0x20000.Non-Secure.rwxl
16 0x20000 0x22000.Non-Secure.rwxl
17 0x22000 0x24000.Non-Secure.rwxl
18 0x24000 0x26000.Non-Secure.rwxl
19 0x26000 0x28000.Non-Secure.rwxl
20 0x28000 0x2a000.Non-Secure.rwxl
21 0x2a000 0x2c000.Non-Secure.rwxl
22 0x2c000 0x2e000.Non-Secure.rwxl
23 0x2e000 0x30000.Non-Secure.rwxl
24 0x30000 0x32000.Non-Secure.rwxl
25 0x32000 0x34000.Non-Secure.rwxl
26 0x34000 0x36000.Non-Secure.rwxl
27 0x36000 0x38000.Non-Secure.rwxl
28 0x38000 0x3a000.Non-Secure.rwxl
29 0x3a000 0x3c000.Non-Secure.rwxl
30 0x3c000 0x3e000.Non-Secure.rwxl
31 0x3e000 0x40000.Non-Secure.rwxl

Peripheral..Domain..Status
00 NRF_P0..Non-Secure.OK
01 NRF_CLOCK..Non-Secure.OK
02 NRF_RTC1..Non-Secure.OK
03 NRF_NVMC..Non-Secure.OK
04 NRF_UARTE1..Non-Secure.OK
05 NRF_UARTE2..Secure..SKIP
06 NRF_IPC..Non-Secure.OK
07 NRF_VMC..Non-Secure.OK
08 NRF_FPU..Non-Secure.OK
09 NRF_EGU1..Non-Secure.OK
10 NRF_EGU2..Non-Secure.OK
11 NRF_TWIM2..Non-Secure.OK
12 NRF_SPIM3..Non-Secure.OK
13 NRF_TIMER0..Non-Secure.OK
14 NRF_TIMER1..Non-Secure.OK
15 NRF_TIMER2..Non-Secure.OK
16 NRF_SAADC..Non-Secure.OK
17 NRF_GPIOTE1..Non-Secure.OK

SPM: NS image at 0x8000
SPM: NS MSP at 0x20022258
SPM: NS reset vector at 0xa191
SPM: prepare to jump to Non-Secure image.
Exception occurred in Secure State
***** HARD FAULT *****
  Fault escalation (see below)
***** BUS FAULT *****
  Precise data bus error
  BFAR Address: 0x50008120
***** Hardware exception *****
Current thread ID = 0x20020178
Faulting instruction address = 0x0
Fatal fault in ISR! Spinning...
 

nrf9160_pca10090.overlay

&spi3 {
	status = "ok";
	sck-pin = <9>;
	mosi-pin = <8>;
	miso-pin = <7>;
	ss-pin = <10>;
	spi-max-frequency = <4000000>;
};

prj.conf

CONFIG_SERIAL=y
CONFIG_TRUSTED_EXECUTION_NONSECURE=y
CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_UART_0_NRF_UARTE=y

# LTE link control
CONFIG_LTE_LINK_CONTROL=n
CONFIG_LTE_AUTO_INIT_AND_CONNECT=n

# BSD library
CONFIG_BSD_LIBRARY=y
CONFIG_BSD_LIBRARY_TRACE_ENABLED=n

# network
CONFIG_TEST_RANDOM_GENERATOR=y
CONFIG_NETWORKING=y
CONFIG_NET_BUF_USER_DATA_SIZE=1
CONFIG_NET_SOCKETS_OFFLOAD=y
CONFIG_NET_SOCKETS=y
CONFIG_NET_SOCKETS_POSIX_NAMES=y
CONFIG_NET_RAW_MODE=y
CONFIG_HEAP_MEM_POOL_SIZE=1024

# SPI
CONFIG_SPI=y
CONFIG_SPI_3=y
CONFIG_SPI_3_NRF_SPIM=y
CONFIG_SPI_3=y 
CONFIG_SPI_NRFX=y

main.c

/*

* Copyright (c) 2012-2014 Wind River Systems, Inc.

*

* SPDX-License-Identifier: Apache-2.0

*/

#include <zephyr.h>
#include <misc/printk.h>
#include <spi.h>

static const struct spi_config spi_cfg = {
	.operation = SPI_WORD_SET(8) | SPI_TRANSFER_MSB |
		     SPI_MODE_CPOL | SPI_MODE_CPHA,
	.frequency = 4000000,
	.slave = 0,
};

struct device * spi_dev;

static void spi_init(void)
{
	const char* const spiName = "SPI_3";
	spi_dev = device_get_binding(spiName);

	if (spi_dev == NULL) {
		printk("Could not get %s device\n", spiName);
		return;
	}
}

void spi_test_send(void)
{
	int err;
	static u8_t tx_buffer[1];
	static u8_t rx_buffer[1];

	const struct spi_buf tx_buf = {
		.buf = tx_buffer,
		.len = sizeof(tx_buffer)
	};
	const struct spi_buf_set tx = {
		.buffers = &tx_buf,
		.count = 1
	};

	struct spi_buf rx_buf = {
		.buf = rx_buffer,
		.len = sizeof(rx_buffer),
	};
	const struct spi_buf_set rx = {
		.buffers = &rx_buf,
		.count = 1
	};

	err = spi_transceive(spi_dev, &spi_cfg, &tx, &rx);
	if (err) {
		printk("SPI error: %d\n", err);
	} else {
		/* Connect MISO to MOSI for loopback */
		printk("TX sent: %x\n", tx_buffer[0]);
		printk("RX recv: %x\n", rx_buffer[0]);
		tx_buffer[0]++;
	}	
}

void main(void)
{
	printk("SPIM Example\n");
	spi_init();

	while (1) {
		spi_test_send();
		k_sleep(1000);
	}
}

For building the solution I am using SEGGER V4.16 on Windows 10. I use Build Solution under the Build menu. The build succeeds. Then I Connect J-link under the Target menu and finally, I upload the merged.hex file using the Download Intel hex file... command under the Download submenu of the Target menu. The upload is successful. 

1. Is there something simple I am overlooking in the example that is causing the hard fault?

2. Is there a different example to test the spi with? My ultimate goal of being able to connect an adxl372 accelerometer. 

Parents
  • Hi,

     

    My apologies, this sample has not been updated in my repo to reflect the requirements of newer zephyr builds.

    Could you see if adding this line to prj.conf helps? Remember to clean the build folder.

    CONFIG_MAIN_STACK_SIZE=4096

     

    Kind regards,

    Håkon

     

    *edit*: Updated with this commit: https://github.com/Rallare/fw-nrfconnect-nrf/commit/6a02c1dcce42140ef737a408f9710c6982f91ac5

    Also rebased the nrf9160_samples branch to match "v0.4.0" tag upstream.

  •  The sample in your repository no longer hard faults with the changes. However, now the program gets to the line "err = spi_transceive(spi_dev, &spi_cfg, &tx, &rx);" and hangs.

    void spi_test_send(void)
    {
            printk("Starting spi_test_send\n");
    	int err;
    	static u8_t tx_buffer[1];
    	static u8_t rx_buffer[1];
    
    	const struct spi_buf tx_buf = {
    		.buf = tx_buffer,
    		.len = sizeof(tx_buffer)
    	};
    	const struct spi_buf_set tx = {
    		.buffers = &tx_buf,
    		.count = 1
    	};
    
    	struct spi_buf rx_buf = {
    		.buf = rx_buffer,
    		.len = sizeof(rx_buffer),
    	};
    	const struct spi_buf_set rx = {
    		.buffers = &rx_buf,
    		.count = 1
    	};
    
            printk("Before spi_transceive\n");
    	err = spi_transceive(spi_dev, &spi_cfg, &tx, &rx); // Program hangs here
            printk("After spi_transceive\n");
    
    	if (err) {
    		printk("SPI error: %d\n", err);
    	} else {
    		/* Connect MISO to MOSI for loopback */
    		printk("TX sent: %x\n", tx_buffer[0]);
    		printk("RX recv: %x\n", rx_buffer[0]);
    		tx_buffer[0]++;
    	}	
    }

    Serial Output

    ***** Booting Zephyr OS v1.14.99-ncs1 *****
    SPIM Example
    Starting spi_test_send
    Before spi_transceive
    

    Any thoughts on how to get this final piece working?

  • If you are able to print and have the spm (secure_boot) prints, then it runs the application as it should.

    Given that it does not fail in spi_init(), "spi_dev" should also be found.

     

    Have you altered the prj.conf and overlay files in any way? If yes, could you try to revert these changes and see if it runs?

    If you enter debug mode and run, do you get any fault or similar?

     

    Kind regards,

    Håkon

  • I did a fresh git pull of the repository, so no modifications to the prj.conf and overlay files. No faults in debug mode. The firmware just hangs in the spi_transceive() call.

  • I have tried to replicate this, but I'm unable to get this behavior.

    Could you ensure that there's no "other firmware" in flash when testing this, by issuing a "nrfjprog -e" to ensure a clean flash?

    If it still misbehaves, could you attach your "spi" example (.zip it) so I can try it out?

     

    Here's my spi + spm for reference: merged.hex

    After compiling in SES, you can go to the folder ..\ncs\nrf\samples\nrf9160\spi\build_nrf9160_pca10090ns in cmd.exe and write "ninja flash" to get it to generate a merged.hex file.

     

    Kind regards,

    Håkon

  • Hi again, I was actually able to reproduce this by connecting SCK to MOSI (shorting the clock). In that case, it hangs on the spi transfer function.

    Have you looped back any signals or connected them externally to a sensor or similar? If yes, please check the wiring.

     

    Kind regards,

    Håkon

  • I have successfully run the "nrfjprog -e" and still no success with my setup. However, I was able to flash the merged.hex file you provided and it successfully ran the spi demo. So we can rule out a hardware issue. Here is my spi example 8726.spi.zip

    I also tried the ninja flash method instead of uploading through SES and it still failed.

Reply Children
  • Thanks for the .zip. I ran your precompiled .hex file (in the nrf9160_pca10090ns build folder) and it runs as expected here:

    SPM: NS image at 0x8000
    SPM: NS MSP at 0x20022e58
    SPM: NS reset vector at 0xa1b1
    SPM: prepare to jump to Non-Secure image.
    ***** Booting Zephyr OS v1.14.99-ncs1 *****
    SPIM Example
    Starting spi_test_send
    Before spi_transceive
    After spi_transceive
    TX sent: 0
    RX recv: 0
    Starting spi_test_send
    Before spi_transceive
    After spi_transceive
    TX sent: 1
    RX recv: 0
    Starting spi_test_send
    Before spi_transceive
    After spi_transceive
    TX sent: 2
    RX recv: 0

     

    I also tried to compile the project and run it, ran as expected then as well.

     

    are you certain that you have the correct tag of the "zephyr" repo?

    Mine is on tag "v1.14.99-ncs1" (git checkout v1.14.99-ncs1)

     

    Do you have any other nRF9160-DKs to test this on?

    Have you ensured that the "SW5" switch is in nRF91 position? If you have programmed the nRF52 with the nRF91's SPI firmware, it might toggle some lines that you do not want to be toggled.

     

    Kind regards,

    Håkon

  • I received a new nRF9160-DK today and interesting results.

    nRF9160-DK V0.8.3 (old board)

    Håkon merged.hex = works

    Zach merged.hex = fails

    nRF9160-DK V0.8.5 (new board)

    Håkon merged.hex = works

    Zach merged.hex = works

    To summarize, the merged.hex that I sent to you works on the 0.8.5 hardware but not on the 0.8.3 hardware and the merged.hex file you sent me works on both hardware versions.

    I am working on wiping and reinstalling the entire ncs repository and version tag 0.4.0 to see if it helps. I will update here if it is successful.

  • This is embarrassing from my side..

    Thanks to , I think we have found the culprit:

    https://devzone.nordicsemi.com/f/nordic-q-a/48197/how-to-use-spi-on-nrf9160dk/191570#191570

    Could you check if this was the root of the issues on your side as well?

     

    Humble regards,

    Håkon

  • Yes this was also the root of the issue on my setup as well. However, on my setup after correcting the .overlay file name. SES can no longer load the project.

    The Fix I have found so far is to include the same lines in the ns.overlay file

    With the temporary fix, everything seems to be working as expected again. Any thoughts on how to fix this final part so I don't have to double include the same lines?

  • Hi,

     

    you should have two overlay files in your project:

    nrf9160_pca10090.overlay

    nrf9160_pca10090ns.overlay

     

    Both these should hold the configuration for your spi peripheral. Since this is a Cortex M33, it has two regions

    * Secure (nrf9160_pca10090.overlay)

    * Non-secure (nrf9160_pca10090ns.overlay)

     

    Depending on which region you configure for, the .overlay file will be appended to the overall device tree source. I include both to make the example as generic as possible.

      

    Kind regards,

    Håkon

Related