Issue with buttons_led_init when trying to program with HX711

[JWCode]

Hello,

I am using a nRF52840-DK with an HX711 in SES. I have been utilizing the code provided by Vidar Berg that can be seen here. 

I downloaded the zip file, unzipped it, and then copied it into the ble_app_uart example folder, running the pca10056_s140 SES project file with the main.c, hx711.c, and hx711.h files from Vidar's code above. Everything complies correctly but I noticed the device wasn't advertising. Whenever I upload the code, LED5 begins flickering/flashing rapidly, and no other LEDs turn on. After some debugging I realized the program is prompting an error in buttons_led_init. The error is highlighted below in the main.c file.

Other people have gotten this code to work quite easily, and I trust that is correct considering Vidar wrote it. However after hours of debugging, changing memory, using DK boards, modifying files, and searching the devzone, I have found nothing that has worked. I am new to the nRF community so I feel like I may be making an obvious mistake. If anyone has any suggestions or tips, it would be much appreciated! Thanks in advance.

[Einar Thorsrud]

Hi,

Please elaborate on what you have found during your debugging. Specifically, which error code is returned from the call to bsp_init()? The error code will most of the time give a fairly good indication about what the problem is. I interpret what you wrote to mean that you don't get the error if you don't include BSP_INIT_BUTTONS in the call to buttons_led_init(), is that correct? If so, then the problem probably is within the "if (type & BSP_INIT_BUTTONS)" statement in the bsp_init implementation in bsp.c. You can debug to see exactly where.

[JWCode]

It probably has something to do with the fact that the main.c, hx711.c, and hx711.h files were written to support s132 and I am using a s140. Do you know if this could be the case and if so how I could fix it?

[JWCode]

Unfortunately, that did not work. When I tried stepping through bsp_init(), I made it through the entire function. However, once it kicked back out into main, the function went to ASM volatile in app_error_handler. I am not quite sure where the error is coming within bsp_init as I do not fully understand what should be happening within the function. Are there any typical red flags or error functions I should be keeping an eye out for?

[Einar Thorsrud]

Hi,

Perhaps it is easier if I try to debug your application. Can you upload your complete application (port of Vidars application for nRF52840-DK)? Then I can test on my side.

[JWCode]

Yes, that would be great. Is there an easy way to do that on devzone? I can add individual source code but am unsure what steps to take to upload a complete application.

[Einar Thorsrud]

The easiest is to zip the example application folder (e.g. <SDK>\examples\ble_peripheral\ble_app_uart_SDK\ if that is where you have your project) and upload the zip file here using Insert -> Insert image/video/file.

[JWCode]

ble_app_uart_HX711_2.zip

I really appreciate your help Einar. Let me know what you find.

[Einar Thorsrud]

Hi,

I see you sent me the older project where you used overlapping pins for buttons and HX711. Since my memory is like a goldfish I forgot about it, and found it again, writing down the procedure to show you how you can debug similar problems in the future:

Stepping in bsp_init() -> app_button_init() you can see that the second iteration in the while loop tries to configure a button on GPIO pin 24. This fails on line 174 in app_button.c, which is caught by the error check on line 175. The error code is 8, which is NRF_ERROR_INVALID_STATE. This error is likely caused by the pin already being configured for GPIOTE, and you can confirm this by stepping into nrfx_gpiote_in_init(), where you will see this clearly on line 523-525 in nrfx_gpiote.c. So you need to specify different pins on line 30-32 in hx711.c (I selected 2, 3 and 4, but it does not matter as long as they are available).

Once fixed, we get the second problem you described, where NRF_ERROR_NO_MEM is returned from the call to bsp_init(). We will apply the same debugging technique here, stepping down in the code to see what is going on. Stepping down the hiararcy you can find that NRF_ERROR_NO_MEM is returned from the call to nrf_drv_gpiote_in_init() on line 174 in app_button.c (which is in the implementation of app_button_init()), when this is called with pin 11. The pin number is not directly relevant here, though, but we take not of it.

Then, step into nrfx_gpiote_in_init() when pin 11 is configured, and step through it. You will see that the error code is set on line 557 in nrfx_gpiote.c, and this is because the internal channel_port_alloc() on line 529 returned NO_CHANNELS. It is not very easy to see, but this happens because loop in channel_port_alloc ends without finding an available low-power "channel". This is because NRFX_GPIOTE_CONFIG_NUM_OF_LOW_POWER_EVENTS is too low, which in turn is because GPIOTE_CONFIG_NUM_OF_LOW_POWER_EVENTS in your sdk_config.h is too low. So the fix is to set GPIOTE_CONFIG_NUM_OF_LOW_POWER_EVENTS to 5 in your sdk_config.h.

[JWCode]

Perfect, thank you so much for your very clear and thorough answer. I appreciate you taking the time to help me in figuring this out!