nrfx_gpiote interrupt causing hard fault

[aplatts]

Hi

Using the nrf52840-dk with SD S140 and nrfx_gpiote, everything runs fund (BLE, TWI etc) but interrup on pin 0,28 causes a Hard Fault. I can not get any sensible logs to diagnose the issue (I'm using VSC and not familiar with Debug).

//IMU Interrup PIN Handler
    nrfx_gpiote_in_config_t in_config = NRFX_GPIOTE_CONFIG_IN_SENSE_HITOLO(true);
    in_config.pull = NRF_GPIO_PIN_PULLDOWN; //NRF_GPIO_PIN_NOPULL;
    in_config.hi_accuracy = true;
    err_code = nrfx_gpiote_in_init(MPU_INT_PIN, &in_config, in_pin_handler);
    APP_ERROR_CHECK(err_code);
    nrfx_gpiote_in_event_enable(MPU_INT_PIN, true);

Any ideas?

Thanks

[Håkon Alseth]

Hi,

 

Could you try to increment the define sdk_config.h::GPIOTE_CONFIG_NUM_OF_LOW_POWER_EVENTS and see if this helps?

 

Kind regards,

Håkon

[aplatts]

Hi

Currently set to 6, fault still present:

#ifndef NRFX_GPIOTE_CONFIG_NUM_OF_LOW_POWER_EVENTS

#define NRFX_GPIOTE_CONFIG_NUM_OF_LOW_POWER_EVENTS 6

#endif

Less than 4 causes a Mem Fault in GPIOTE.

As I am using bsp_btn_ble, will this conflict?

Thanks

[Håkon Alseth]

Hi,

 

If you are using more input buttons (with interrupt on them) than the number specified in the define, it will return an error code, and if you do a APP_ERROR_CHECK() on the returned code, it'll assert.

Kind regards,

Håkon

[aplatts]

Hi

I understand that, but I am still getting a hard fault when and input occurs triggering an interrupt on pin 0,28.

My question was concerning are there any compatibility issues between nrfx_gpiote, S140 and bsp_btn_ble.

Thanks

[Håkon Alseth]

I'm very sorry, I misread your former response.

Could you enter debug mode, and provide a trace? Here's a guide on how to get started with gdb from command line, if you haven't setup vscode + cortex debug:

https://devzone.nordicsemi.com/nordic/nrf-connect-sdk-guides/b/getting-started/posts/using-gdb-with-nordic-devices

 

Its essentially starting the JLink GDB server (there's a GUI for that in windows) and going into arm-none-eabi-gdb.

In a command line:

c:path\to\arm-none-eabi-gdb nrf5\examples\my_example\_build\nrf52840_xxaa.out

In arm-none-eabi-gdb:

target remote localhost:2331 # connect to localhost's GDB server
b HardFault_Handler # set the breakpoint
mon reset # reset the device
c # continue to run

When the breakpoint is hit, input:

bt full

 

If the breakpoint isn't hit (maybe its suck some other place?), please do "CTRL+C" and then issue "bt full".

This should give you a full backtrace. Could you paste the output?

 

Using gdb directly is not everyone's cup of tea. If you have issues (ie: spend more than 20 minutes getting the trace), you could also try Segger Ozone for GUI based debugging. This is a pure debugging software, which requires only the .out (ELF file) to debug.

 

Kind regards,

Håkon

[aplatts]

Hi

This is the output from arm-none-eabi-gdb:

c
Continuing.
{"token":33,"outOfBandRecord":[],"resultRecords":{"resultClass":"running","results":[]}}

Program
 received signal SIGTRAP, Trace/breakpoint trap.
0x00028a10 in app_error_fault_handler (id=id@entry=16385, pc=pc@entry=0, info=info@entry=537132804) at ../../../../nRF5SDK160098a08e2/components/libraries/util/app_error_weak.c:100
100	    NRF_BREAKPOINT_COND;
bt full
#0  0x00028a10 in app_error_fault_handler (id=id@entry=16385, pc=pc@entry=0, info=info@entry=537132804) at ../../../../nRF5SDK160098a08e2/components/libraries/util/app_error_weak.c:100
No locals.
#1  0x000289dc in app_error_handler_bare (error_code=<optimized out>) at ../../../../nRF5SDK160098a08e2/components/libraries/util/app_error.c:73
        error_info = {line_num = 0
, p_file_name = 0x0
, err_code = 537132796
}

#2  0x000343d4 in ble_stack_init () at ../../../main.c:635
        LOCAL_ERR_CODE = <optimized out>
        err_code = <optimized out>
        ram_start = 785441024

[Håkon Alseth]

Hi,

 

Thank you for the stack trace. 

The compiler is optimizing a bit too much here, but I suspect this error is due to the amount of RAM that the stack is given.

Could you try to adjust the RAM start address in your linker script (.ld file in your armgcc folder) to see if this helps?

https://devzone.nordicsemi.com/nordic/short-range-guides/b/getting-started/posts/adjustment-of-ram-and-flash-memory

 

If you change the optimization level to "-Og -ggdb" in your makefile, and recompile/flash, you should see more symbols in the debug view. If you in addition, add the CFLAGS += -DDEBUG, you will enable blocking assertions with "error_info" struct above being populated with file name, line number, error code, so you can see exactly where the assert occurred.

 

Kind regards,

Håkon