nRF9160 DK SPI Example causing hard fault.

RE: nRF9160 DK SPI Example causing hard fault.

Håkon Alseth — Tue, 11 Jun 2019 08:40:10 GMT

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

RE: nRF9160 DK SPI Example causing hard fault.

Zada — Fri, 07 Jun 2019 14:37:50 GMT

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. Håkon Alseth Any thoughts on how to fix this final part so I don't have to double include the same lines?

RE: nRF9160 DK SPI Example causing hard fault.

Håkon Alseth — Fri, 07 Jun 2019 10:47:20 GMT

This is embarrassing from my side..

Thanks to Linus, 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

RE: nRF9160 DK SPI Example causing hard fault.

Zada — Thu, 06 Jun 2019 17:44:00 GMT

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.

RE: nRF9160 DK SPI Example causing hard fault.

Håkon Alseth — Thu, 06 Jun 2019 10:28:26 GMT

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

RE: nRF9160 DK SPI Example causing hard fault.

Zada — Wed, 05 Jun 2019 21:10:59 GMT

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 devzone.nordicsemi.com/.../8726.spi.zip

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

RE: nRF9160 DK SPI Example causing hard fault.

Håkon Alseth — Wed, 05 Jun 2019 10:58:25 GMT

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

RE: nRF9160 DK SPI Example causing hard fault.

Håkon Alseth — Wed, 05 Jun 2019 08:53:03 GMT

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: devzone.nordicsemi.com/.../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

RE: nRF9160 DK SPI Example causing hard fault.

Zada — Tue, 04 Jun 2019 19:35:17 GMT

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.

RE: nRF9160 DK SPI Example causing hard fault.

Håkon Alseth — Tue, 04 Jun 2019 10:49:11 GMT

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

RE: nRF9160 DK SPI Example causing hard fault.

Zada — Mon, 03 Jun 2019 18:26:19 GMT

Håkon Alseth 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?

RE: nRF9160 DK SPI Example causing hard fault.

Håkon Alseth — Mon, 03 Jun 2019 06:59:05 GMT

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.

RE: nRF9160 DK SPI Example causing hard fault.

John — Sat, 01 Jun 2019 22:01:46 GMT

https://devzone.nordicsemi.com/f/nordic-q-a/48057/ncs-v0-4-0-asset-tracker-application---faulting-instruction-address-0x7140/190370#190370

The above link may get you further.

RE: nRF9160 DK SPI Example causing hard fault.

DevinCallahan — Fri, 31 May 2019 15:25:06 GMT

I think in the file "build_nrf9160_pca10090ns/CMakeCache.txt" there should be an entry like this:

//Selected board
CACHED_BOARD:STRING=nrf9160_pca10090ns

The project I have that was built for the "ns" board has that as the string.

Conversely the "nrf/samples/nrf9160/spm" project I was using as the bootloader has this for that entry:

//Selected board
CACHED_BOARD:STRING=nrf9160_pca10090

They have to be exactly those strings because the zephyr cmake files use them to find the correct dts and overlays in the board directory at "zephyr/boards/arm/nrf9160_pca10090".

Also if you use the nrf9160_pca10090ns board, you need to rename your .overlay file to nrf9160_pca10090ns.overlay for the zephyr build to pull it in automatically. Their script uses the board string when looking for overlay files in the project source directory.

RE: nRF9160 DK SPI Example causing hard fault.

Zada — Fri, 31 May 2019 08:50:33 GMT

nrf9160_pca10090.overlay

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

nrf9160_pca10090_ns.overlay

//nrf9160_pca10090.overlay
&spi3 {
        status = "ok";
        sck-pin = <13>;
        mosi-pin = <11>;
        miso-pin = <12>;
        ss-pin = <10>;
        spi-max-frequency = <4000000>;
};

No change. Still getting the **** Hard Fault *****

RE: nRF9160 DK SPI Example causing hard fault.

Alan Jones — Thu, 30 May 2019 22:34:29 GMT

I think you have a pin conflict in your SPI definition, which is also in the secure, rather than non-secure (nrf9160_pca10090ns.overlay).

I've used this in the application directory as the non-secure overlay with the Dev Kit with success out of the box:

&spi3 {
        status = "ok";
        sck-pin = <13>;
        mosi-pin = <11>;
        miso-pin = <12>;
        ss-pin = <10>;
        spi-max-frequency = <4000000>;
};

I believe if you want to use your previous pin config, you need that in the secure overlay in SPM, as well as the same definition in the non-secure overlay in your application directory.

RE: nRF9160 DK SPI Example causing hard fault.

Zada — Thu, 30 May 2019 22:24:32 GMT

I believe I am building the project for the nrf9160_pca10090ns

The build_nrf9160_pca10090ns build folder is being created automatically. Is there a better way to confirm the project is being built for ns?

RE: nRF9160 DK SPI Example causing hard fault.

Zada — Thu, 30 May 2019 22:20:40 GMT

updated 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

CONFIG_GPIO=y
CONFIG_GPIO_NRF_P0=y

The same error is occurring.

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

RE: nRF9160 DK SPI Example causing hard fault.

Alan Jones — Thu, 30 May 2019 22:00:56 GMT

I've seen that fault address too many times to count. Try either of these in the project configuration settings and you should be running again:

CONFIG_GPIO=y

CONFIG_GPIO_NRF_P0=y

I think the GPIO is somehow locked down as secure, and when you jump to it, the UART tries to execute the printk, and bumps up against non-functional pins, so it errors out in the UART peripheral address space. There seems to be a problem with the default GPIO config lately.

RE: nRF9160 DK SPI Example causing hard fault.

DevinCallahan — Thu, 30 May 2019 21:26:59 GMT

Could you trying building the project for the nrf9160_pca10090ns board instead? It might not be getting linked to account for the bootloader.