GPIO pins don't work as expected.

[nemunoz]

Hi to everyone!

I have a custom board (based on nRF52832) with two LEDS and other GPIO ports. In some point of the code I have to activate one device by setting one port to 1. This is designed like that for power saving. But I realized this device never turns on.

Unless there is other way, I use the function nrf_gpio_cfg_output to configure the port and the functions nrf_gpio_pin_set and nrf_gpio_pin_clear to turn the device on and off, respectively.

After some tests I detected that even the LEDs (and the other GPIO ports) are not working correctly (but in nRF52832DK they worked). If I use nrf_gpio_cfg_output with one LED, then this LED lights up until I use again nrf_gpio_cfg_output with other port (for example with the other LED).

After configuring (I hope) the LEDs as output, when I use nrf_gpio_pin_clear the LEDs lights up and when I use nrf_gpio_pin_set the LEDs turn off. So the result I get is exactly the opposite I expected.

Any Ideas why this is happening?

Could be a problem with crystals or something like that?

Thanks in advance!

[AmbystomaLabs]

Based on your information, I am assuming you bought the board from some company and did not design it yourself.

The most likely reason the LED activity is backward is that LED's are commonly sinked and not sourced via the IC. The reason for this is that there is a limit to how much current one can have the IC (nRF SoC) source but generally it can sink to ground much more. Thus power for the LED's comes from a separate connection to Vdd and the cathode of LED is connected to gpio.

So, a clear turns it on and a set turns it off.

You should probably start first by securing a schematic to the nRF based board. It will probably illustrate the reasons for your other gpio issues.

[nemunoz]

Hi AmbystomaLabs.

This is a prototype board and we are looking for the problem to fix it (yes I did not design it).

But recently I have seen in deep the Nordic files code (and retesting them with the nRF52832DK) and I realize that the code in boards.c also has this "problem" in mind (I do not know if it is finally a problem).

I mean: In the function bsp_board_led_on, where the led should light up, the nrf_gpio_pin_write function is called with 0 as parameter and, in this write function, if 0 is the parameter, then nrf_gpio_pin_clear function is called (if not, then the nrf_gpio_pin_set is called`).

In summary, bsp_board_led_on uses nrf_gpio_pin_clear to light up the leds and bsp_board_led_off uses nrf_gpio_pin_set to turn off the leds.

What does the variable LEDS_ACTIVE_STATE mean with value 0?

[AmbystomaLabs]

All the examples work correctly with the development kits. Nordic does not support module vendors.

All boards need to have board definition header file that is used with boards.c to define how they are configured. For example the nRF52832DK is pca10040.h. You will find it in sdk/components/boards.

Sounds like you are using the wrong header file.

You need to go back to your board vendor and get a probably configured board file or you need to get a copy of the schematic for your board and make the correct file yourself. The SDK is only designed for the development kits.

[nemunoz]

I do not saying any of the examples are not working, that is why I put the word problem between quoation marks, because in the end I thought I was missing something.

I am saying that I do not understand why a function to turn on a led uses clear and a function to turn it off uses set, because I guess that set puts the pin in 1 (sending current) and clear puts the pin in 0 (cleaning the current). And with this current I turn on the led or I turn off the led if I remove the current. At least I thought so until I saw how are working the leds.

And I am taking the pca10040.h file as example to develop our custom board definition header file because both the custom board and the develop board use the same SoC. That is why I asked you for the meaning of LEDS_ACTIVE_STATE variable and why it's own value has a number and is 0.

[AmbystomaLabs]

Your LED issue is due to using the wrong BSP file for your board. Without a schematic of your board you will have to guess at whether the LED's sink or source to activate. Also, you could inspect it under a microscope and try to figure out the connections.

LED_ACTIVE_STATE is what you expect it to be. The definition of whether they source or sink to turn on.

All the bsp definitions are here: appiko.github.io/.../group__board__pca10040.html