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?

[Einar Thorsrud]

Hi,

Which function returns NRF_ERROR_NO_MEM? (It seems you have made some modifications to Vidars example, so the line number (566) does not match with the code I have).

JWCode said:

What should my Macro memory values be? I thought they were correct at 

Some of it depends. In short:

• FLASH_START: should be the same as the size of the SoftDevice (you can either check in an example project using the same SoftDevice or the SoftDevice specification).
• FLASH_SIZE: Usually not that important unless you are using a lot of flash, but strictly speaking it should be set to the total flash size - FLASH_START - any-other-flash-usage-such-as-fds.
• RAM_START: It depends on the SoftDevice configuration. If you have changed the SoftDevice configuration (such as the number of peripheral or central links or attribute table size), this will increase. It is difficult to calculate, which is why the SoftDevice will tell you how to adjust it. See Adjustment of RAM and Flash memory for details.
• RAM_SIZE: Physical RAM size - RAM_START.
• The other parameters (*_PH_*) are supposed to represent the physical memory of the device, but it is not used for anything so it can be ignored.

JWCode said:

I have also tried modifying total links to 12, peripheral and central links to 6, and including the code linked here to ble_stack_init() to attempt to increase the attribute table size. Nothing has worked yet. Any ideas?

Why did you adjust the link counts? Using multiple links is no problem, but it is a good idea to get one thing working before moving on to the next.

[JWCode]

The same function I mentioned earlier(buttons_leds_init) returns the no memory error. It seems the adjustment of pins just changed the error code from error 8 to error 4. Specifically, the following two lines:

uint32_t err_code = bsp_init(BSP_INIT_LEDS | BSP_INIT_BUTTONS, bsp_event_handler);
APP_ERROR_CHECK(err_code);

Thanks for the thorough description of the Macros, that clears it up. I have changed the link counts back, I had just seen it suggested as a possible solution for the error code I have been receiving, but am still receiving the NO_MEM error.

[Einar Thorsrud]

Hi,

One possible explanation is that you have queued too many timer operations. Does it help to increase APP_TIMER_CONFIG_OP_QUEUE_SIZE? If not, have you tried to step into bsp_init() and see where the error comes from? the further in you go, the closes you will come. Probably you will just need to step down a few functions before you find the reason.

[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!