Toggle LED in custom application

RE: Toggle LED in custom application

ovrebekk — Thu, 03 Nov 2022 13:09:17 GMT

Hi Jamie

I am glad I could be of help 🙂

If you have any more questions related to this topic just let me know. For other questions just open a new ticket.

Best regards
Torbjørn

RE: Toggle LED in custom application

jmilliken — Thu, 03 Nov 2022 11:42:27 GMT

Thank you. This is great information. I'll take some time to digest it and see if I have any further questions, but I think I have everything I need to proceed at this point. Thanks for all the help.

-Jamie

RE: Toggle LED in custom application

ovrebekk — Wed, 02 Nov 2022 13:32:09 GMT

Hi Jamie

Simon is currently unavailable, so I will help you out instead.

[quote user="jmilliken"]1) Why was this code inserted and from where is network_gpio_allow() called since it is clearly not called from main()?[/quote]

The only reference to this function I can find is in the main.c file of the empty_app_core example.

The assumption is that if you are not running any code in the app core you want all the GPIO's available to the network core, since this is where you're running all your code.

In the end it is up to the app core to decide which pins are assigned to which core, which is why the app core has to run this during boot.

The SYS_INIT macro allows you to schedule code to be run during the boot process of the Zephyr kernel, before the main thread or any other application code has started.

The call to the various SYS_INIT functions will come from the init.c file in the zephyr\kernel folder, more specifically this line.

[quote user="jmilliken"]Where are the initialization calls taking place since?[/quote]

Essentially this is triggered by the z_cstart(void) function in the init.c file I mentioned earlier.

The various modules in your system that needs some kind of boot time initialization can define init functions using either the SYS_INIT macro, or one of the DEVICE macros for device drivers, as described here.

[quote user="jmilliken"]3) In STM32 applications, we also get an assembly file - e.g. startup_stm32h743zitx.s - which, upon reset, initializes all the memory then jumps to main. Where does this occur in Zephyr?[/quote]

The reset code is implemented in /zephyr/arch/arm/core/aarch32/cortex_m/reset.S, which in turn calls the z_arm_prep_c() function in /zephyr/arch/arm/core/aarch32/prep_c.c, which among other things call the z_cstart() function in init.c that I mentioned earlier.

[quote user="jmilliken"]4) Does Zephy code adhere to CMSIS conventions? [/quote]

Yes, all the hardware registers have CMSIS definitions available.

I believe you need to include <device.h> to get access to them.

Please note that all peripheral in the nRF devices use the NRF_ prefix, eg:

NRF_TIMER0->TASKS_START = 1;

Best regards
Torbjørn

RE: Toggle LED in custom application

jmilliken — Sun, 30 Oct 2022 22:06:12 GMT

Hi Simon

So I have solved my problem, but it brought up some other questions. First, the solution to what was happening is that the auto-generated main() function for the two non-functional examples had this code hanging around below main() that I hadn't noticed (somehow!):

-----------------------------------------------------------------------------------------------------

/** @brief Allow access to specific GPIOs for the network core.

* Function is executed very early during system initialization to make sure

* that the network core is not started yet. More pins can be added if the

* network core needs them.

static int network_gpio_allow(const struct device *dev)

{

ARG_UNUSED(dev);

/* When the use of the low frequency crystal oscillator (LFXO) is

* enabled, do not modify the configuration of the pins P0.00 (XL1)

* and P0.01 (XL2), as they need to stay configured with the value

* Peripheral.

uint32_t start_pin = (IS_ENABLED(CONFIG_SOC_ENABLE_LFXO) ? 2 : 0);

/* Allow the network core to use all GPIOs. */

for (uint32_t i = start_pin; i < P0_PIN_NUM; i++) {

NRF_P0_S->PIN_CNF[i] = (GPIO_PIN_CNF_MCUSEL_NetworkMCU <<

GPIO_PIN_CNF_MCUSEL_Pos);

}

for (uint32_t i = 0; i < P1_PIN_NUM; i++) {

NRF_P1_S->PIN_CNF[i] = (GPIO_PIN_CNF_MCUSEL_NetworkMCU <<

GPIO_PIN_CNF_MCUSEL_Pos);

}

return 0;

}

SYS_INIT(network_gpio_allow, PRE_KERNEL_1, CONFIG_KERNEL_INIT_PRIORITY_OBJECTS);

------------------------------------------------------------------------------------------------------

So at start-up, all pins were assigned to the network core via this embedded function call before main even had a chance to execute. Commenting out the last line ("SYS_INIT") fixes the problem and I/Os are under control. However, this brings up the following quesitons:

1) Why was this code inserted and from where is network_gpio_allow() called since it is clearly not called from main()?

2) Using STM32 applications as an example, in their main files we get something like the following:

So each of these HAL functions is called from main which makes it very easy to jump into the generated code and see exactly what registers are being set, etc, to configure a peripheral. In Zephyr code, this seems to be very obfuscated. Where are the initialization calls taking place since?

3) In STM32 applications, we also get an assembly file - e.g. startup_stm32h743zitx.s - which, upon reset, initializes all the memory then jumps to main. Where does this occur in Zephyr?

4) Does Zephy code adhere to CMSIS conventions? Again, citing STM32 code (sorry, I've just written a lot of that so it makes comparison easy for me), if I want to change a register in a timer, for example, I can write: TIM3->CNT = 0; which would access the count register of Timer 3 directly. Can I do the same for Zephyr code?

Thanks,

Jamie

RE: Toggle LED in custom application

Simon — Thu, 27 Oct 2022 11:37:20 GMT

I guess P0.29 is forwarded to the netcore using the dts compatible nordic,nrf-gpio-forwarder, like explained in this reply.

Try to disable forwarding pins to the netcore by doing adding the following to a file nrf5340dk_nrf5340_cpuapp (I assume you're not using cpuapp_ns)

/ {
	gpio_fwd: nrf-gpio-forwarder {
		compatible = "nordic,nrf-gpio-forwarder";
		status = "disabled";
	};
};

If that doesn't work, try to open the file <sample>/build/zephyr/zephyr.dts and search for "nordic,nrf-gpio-forwarder", and see what name the compatible is within. For example if it is within "some_name: nrf-gpio-forwarder" instead, use that in your overlay.

Best regards,

Simon

RE: Toggle LED in custom application

jmilliken — Thu, 27 Oct 2022 01:37:15 GMT

I've gotten a little closer to the root of the problem but still need some help. Looking at the registers for the pin, with the application that can successfully toggle the LED, I see this:

With the application that cannot, I see this:

So somehow the pin control is being assigned to the network core, not the application core. I verified that for both projects, the build configuration is the same (UBX_EVKNORAB10_NRF5340 Application MCU). So what project settings assign pins to the different cores and how do I set that up? In my application, at least for now, I have no need for the Network MCU to control pins directly, so all should be assigned to the Application core.

Thanks,

Jamie

RE: Toggle LED in custom application

Simon — Wed, 26 Oct 2022 14:05:40 GMT

[quote user="jmilliken"]To answer your question, I am using the NORA-B106 EVK from U-blox:[/quote]

Ah, okay. I thought you were using the nR5340 DK.

[quote user="jmilliken"]Okay, I will try this tonight and let you know.[/quote]

Sounds good.

RE: Toggle LED in custom application

jmilliken — Wed, 26 Oct 2022 13:53:03 GMT

Okay, I will try this tonight and let you know. To answer your question, I am using the NORA-B106 EVK from U-blox:

www.digikey.com/.../13534375

RE: Toggle LED in custom application

Simon — Wed, 26 Oct 2022 13:03:14 GMT

Hmm.. that is strange. What nRF5340 DK version do you have?

Are you able to get any output from any other pins? Try toggling P0.25 or P0.26 for example and connect a logic analyzer to the header and check if you can see any activity.

[quote user="jmilliken"] I went into debug mode to add a breakpoint at line 27 (from your code snippet above) but it would not let me add a breakpoint there. In fact, if I click to add a breakpoint there, it automatically inserts it at line 34 above, indicating that it must have optimized out the lines for getting the device tree reference. Any ideas?[/quote]

Try setting CONFIG_DEBUG_OPTIMIZATIONS=y in the prj.conf and do a pristine build.

Best regards,

Simon

RE: Toggle LED in custom application

jmilliken — Wed, 26 Oct 2022 01:36:22 GMT

Hi. Going back to the application generated from the hello world template, I have verified that the prj.conf has the following:

CONFIG_GPIO=y

CONFIG_SPI=y

main.c has the following includes:

#include <zephyr.h>

#include <drivers/gpio.h>

#include <drivers/spi.h>

Also, I added the code snippet above but still no LED. I went into debug mode to add a breakpoint at line 27 (from your code snippet above) but it would not let me add a breakpoint there. In fact, if I click to add a breakpoint there, it automatically inserts it at line 34 above, indicating that it must have optimized out the lines for getting the device tree reference. Any ideas?

-Jamie

RE: Toggle LED in custom application

Simon — Mon, 24 Oct 2022 12:27:54 GMT

I applied the following modifications to the hello world sample in NCS v2.1.0:

diff --git a/samples/hello_world/prj.conf b/samples/hello_world/prj.conf
index b2a4ba5910..d63ffc4391 100644
--- a/samples/hello_world/prj.conf
+++ b/samples/hello_world/prj.conf
@@ -1 +1,2 @@
 # nothing here
+CONFIG_GPIO=y
diff --git a/samples/hello_world/src/main.c b/samples/hello_world/src/main.c
index 8676d8940b..0e61e7a84d 100644
--- a/samples/hello_world/src/main.c
+++ b/samples/hello_world/src/main.c
@@ -5,8 +5,33 @@
  */
 
 #include <zephyr/zephyr.h>
+#include <zephyr/drivers/gpio.h>
+
+#define SLEEP_TIME_MS 500
 
 void main(void)
 {
 	printk("Hello World! %s\n", CONFIG_BOARD);
+	const struct device *dev0;
+    const int PIN=29;
+    int ret;
+
+    dev0 = DEVICE_DT_GET(DT_NODELABEL(gpio0));
+
+    if (dev0==NULL) {
+        printk("device not found");
+    }
+
+    if (!device_is_ready(dev0)) {
+        printk("GPIO controller not ready");
+    }
+
+    ret = gpio_pin_configure(dev0, PIN, GPIO_OUTPUT);
+    if(ret){
+        printk("gpio_pin configure failed: %d\n", ret);
+    }
+    while(1) {
+        gpio_pin_toggle(dev0, PIN);
+        k_msleep(SLEEP_TIME_MS);
+    }
 }

Then I programmed it onto the board nrf5340dk_nrf5340_cpuapp, and LED2 blinked as expected.

Here is the complete sample:

devzone.nordicsemi.com/.../2248.hello_5F00_world_5F00_blinky.zip

Best regards,

Simon

RE: Toggle LED in custom application

jmilliken — Mon, 24 Oct 2022 02:39:41 GMT

Update - I have recreated the application three different ways using different Application templates.

Created with nrf/samples/nrf5340/empty_app_core - LED toggle does not work.
Created with zephry/samples/hello_world - LED does not work.
Created with zephyr/samples/basic/blinky - LED works.

I should note that it is not just the LED that doesn't toggle, I also have SPI transciever code and I can see that the GPIOs associated with clock, chip select, and data lines also do not work (i.e. they are always held low) in 1 and 2 above, but work in 3 above.

So my pins are under control now, which is great. But so that I can understand, what is going on "behind the scenes" that causes the first two applications to fail and the third to work? What options or configurations do I need to enable to make 1 and 2 work?

Thanks,

Jamie