Thingy91 How to manually configure SPI chip select pin as GPIO output pin

[zazas321]

I am having some issues with the Thingy91 and SPI. I want to configure GPIO0 8 as GPIO_OUTPUT pin.

This is my source code:

#include <stdio.h>
#include <stdlib.h>
#include <zephyr/kernel.h>
#include <zephyr/drivers/spi.h>
#include <zephyr/device.h>
#include <zephyr/drivers/gpio.h>

#define LOG_LEVEL CONFIG_LOG_DEFAULT_LEVEL
#include <zephyr/logging/log.h>
LOG_MODULE_REGISTER(main);


// Define the CS pin
#define CS_PIN 8
const struct device *gpio_dev;

int main(void)
{
	int err;
	printk("Program started \n");
	gpio_pin_configure(gpio_dev, CS_PIN, GPIO_OUTPUT);

	if (err < 0)
	{
		printk("GPIO pin configure failed with error %d\n", err);
		return 0;
	}
	k_msleep(1000);
	printk("getting into while loop \n");
	return 0;
}

You can also access my code at github:

https://github.com/krupis/thingy91_spi_test

gpio_configure_bug branch.

It is also important to mention that on the Thing91 nRF52840, Connectivity Bridge application is running. I am only interested in programming nRF9160.

I have read about how to configure CS pin as GPIO from the following post:

 Is it possible to control SPI chip select pin with Zephyr GPIO API? 

and basically copy and pasted the code that has been suggested.

But for me it does not seem to work. The code just halts when gpio_pin_configure(gpio_dev, CS_PIN, GPIO_OUTPUT); is called. I have tried looking at the serial monitor but no logs are coming out even though I have added multiple printk statements.

After launching debugger, I have discovered that the Securefault_hanlder is triggered when the gpio_pin_configure is called:

I have 2 questions

1. Am I configuring the GPIO correctly? (gpio0 8). If not, could you suggest an alternative way?
2. Why am I not seeing a single printk statement being printed to the serial console? I have printk("Program started \n"); statement before the gpio_pin_configure call but that never gets printed.

Thanks in advance.

[zazas321]

Since you mentioned printf and log_dbg, I have tried something out. Please see the source code below:

#include <stdio.h>
#include <stdlib.h>
#include <zephyr/kernel.h>
#include <zephyr/drivers/spi.h>
#include <zephyr/device.h>
#include <zephyr/drivers/gpio.h>

#define LOG_LEVEL CONFIG_LOG_DEFAULT_LEVEL
#include <zephyr/logging/log.h>
LOG_MODULE_REGISTER(main);


// Define the CS pin
#define CS_PIN 8
const struct device *gpio_dev;

int main(void)
{
	int err;
	printk("Program started printk\n");
	printf("Program started pritnf \n");
	LOG_DBG("Program started log_dbg\n");
	gpio_pin_configure(gpio_dev, CS_PIN, GPIO_OUTPUT);

	if (err < 0)
	{
		printk("GPIO pin configure failed with error %d\n", err);
		return 0;
	}
	k_msleep(1000);
	printk("getting into while loop \n");
	return 0;
}

with the following prj.conf:

CONFIG_LOG=y
CONFIG_SPI=y
CONFIG_GPIO=y

As you can see from the code above, I am trying 3 different print methods (printf, printk, and log_dbg).

From the serial terminal I see that only printf is being printed before the CPU crashed at the function gpio_pin_configure

This tells me that printf prints to the console instantly whereas log_dbg and printk is not.

[runsiv]

Hi Lukas

I tested your setup on my part. I was not able to recreate what you are seeing. At my side only the printk was printed before the crash. 
On your end it looks like it might be some corruption since you have the special sign before the printf line. You could also try with an CONFIG_LOG_IMMEDIATE to make it print the log at once. 

We have also in the past seen usb hubs might affect thing also. 

There is also a known bug in jlink that can affect you, we have a workaround for it here

Regards

Runar

[zazas321]

Please clarify if you are testing this on the Thingy 91 or some other DK? 

After adding CONFIG_LOG_MODE_IMMEDIATE=y

it now prints printf and printk before the crash:

I think that special character is just some serial data getting flushed out after I program the device. It only appears after I program the device while having the serial port open. It will not appear if I just reboot the device so I dont think that should be an issue.

It is also very concerning why would you not see the printf being printed. You should definately see printf being printed before the crash if you are using Thingy 91 as there is no reason why you would not.

Can you confirm if the order of your print statements are as following:

    printk("Program started printk\n");

    printf("Program started pritnf \n");

    LOG_DBG("Program started log_dbg\n");

runsiv said:

We have also in the past seen usb hubs might affect thing also. 

I plug the Thing91 directly to my laptop so expansion hubs should not be a problem.

It is very interesting why we both see different results on our identical setups (I assume you tried my project on the Thingy91).

 

If you did not try my specific project, could you please try it to ensure you are not able to reproduce the issue with my particular prj.conf and etc...

You need:

Thingy 91 (Connectivity Bridge application running on the nRF52840 and my program running on the nRF9160)

[runsiv]

I tested on a different DK. Working from home today, so will update the case tomorrow when I have my thing91 

Regards

Runar

[zazas321]

Yeah I figured that could be the case. The reason why I believe it could be somehow related to the Thingy 91 is because it does not support logging via UART from the nRF9160 by default. You need to have connectivity bridge application running on the nRF52840 so all the logs from the nRF9160 are transfered the nRF52840 and then being transfered to serial monitor.

Perhaps that has to do something why it acts so weird.