GPIO pins don't work as expected.

RE: GPIO pins don't work as expected.

nemunoz — Wed, 31 Jan 2018 14:10:20 GMT

That is why the leds are acting like that! Because LEDS_ACTIVE_STATE sets 0 as active value. I was thinking there was a list of states (I could not imagine where this list could be) and the file was taking the one that has the value 0. I am sorry for my ignorance.

Now I am working with the updated SDK (14.2.0) and everything in GPIO is working properly. Maybe I modified something without realizing it in the old version and that is why GPIO was not working.

Thanks for your help in everything, AmbystomaLabs!

RE: GPIO pins don't work as expected.

AmbystomaLabs — Tue, 30 Jan 2018 20:02:34 GMT

There are a lot of blog answers on BSP. Also here is the tutorial: devzone.nordicsemi.com/.../

RE: GPIO pins don't work as expected.

AmbystomaLabs — Tue, 30 Jan 2018 19:53:07 GMT

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

RE: GPIO pins don't work as expected.

nemunoz — Tue, 30 Jan 2018 19:40:42 GMT

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.

RE: GPIO pins don't work as expected.

AmbystomaLabs — Tue, 30 Jan 2018 16:19:42 GMT

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.

RE: GPIO pins don't work as expected.

nemunoz — Tue, 30 Jan 2018 10:58:23 GMT

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?

RE: GPIO pins don't work as expected.

AmbystomaLabs — Fri, 26 Jan 2018 21:50:25 GMT

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.