Application Code hangs after SUCCESSFULLY sending notification to central

[patjshan]

Hi All. 

I am writing an application that has several notifiable characteristics, and up until now they have been sending data just fine, however the other day I was cleaning up some code and i decided to change the function that handles the notification process a little bit, make it more robust. I was previously just passing in the data i wanted to be sent along with its length and then inside the function deducing what characteristic handle was appropriate based on the length of the data, but then I should really just pass the appropriate handle along to the function also so i don't have to do all that deduction and can just point to the value thats' passed through. anyways Now the notification goes through to the central and they receive the data but a second or two later peripheral hangs on a hardfault (disassembly shows it is at address 0xa60) but i haven't the slightest Idea why. 

Some more background: I was initially calling the function from inside a timeout handler that interrupts every 100ms, and I saw in another post that that might be screwing with the softdevice so I moved the function call to inside main (call only happens when the appropriate flag has been raised). I still get the hardfault even when the call is in main and I can see from some debug lines that I have added that the notification call goes through fine, sd_ble_gatt_hvx returns NRF_SUCCESS, then the application runs through main 5-6 more times before the hardfault appears. Weird thing is I can perform other gatt operations just fine, writing and reading go off without a hitch.

Also, I dont think this is the issue but it may be relevant, these characteristics were previously indicatable instead of notifiable, but I believe I have changed the properties appropriately in the service initializer. Could this be the issue? could the softdevice be waiting for a confirmation from the central and then hang?

I am working with the nrff52832, using softdevice s132 V 6.1.1, sdk 15.3.0, and Segger Embedded Studio

Really at a loss on this one and any help that can be offered is appreciated.

 

Thanks,

Patrick

[Vidar Berg]

Hello,

I can't think of any obvious reasons as to why the hardfault exception gets  triggered when you attempt to send notifications from your main loop. It also sounds like the issue is possibly not directly related to the hvx call iteself since it is returning back application. Anyway, I think my best suggestion to further troubleshoot is to include the HardFault handling library in your project and see if you could get some more details about what caused the fault.

Steps to enable the Hardfault handling libary

1. make sure the following two source files are included in the project:

      <file file_name="../../../../../../components/libraries/hardfault/hardfault_implementation.c" />
      <file file_name="../../../../../../components/libraries/hardfault/nrf52/handler/hardfault_handler_gcc.c" />

2. Apply the following sdk_config.h settings to enable hardfault handler and RTT logging in debug terminal

HARDFAULT_HANDLER_ENABLED 1
NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED 0
NRF_LOG_BACKEND_RTT_ENABLED 1

3. Select the debug configuration to prevent the hardfault handler from performing a system reset.

4. Optional: disable 'hardfault' breakpoint to prevent the debugger from halting inside the MBR's hardfault handler at 0xa60. Alternatively, you can press the "play" button to continue execution from this address.

Best regards,

Vidar

[patjshan]

Thanks for the info! I enabled all of the macros and included the files in my project, but the NRF_ERROR_LOG statements still weren't being executed and I'm not sure why. I know I'm probably not supposed to but in the interest of time I switch the error log call in the for loop in hardfault_implementation to a printf() just to see which error log  I got and it printed this:

"Cause: The processor has attempted to execute an instruction that makes illegal use of the EPSR."

any thoughts on what this means?

Thanks,

Patrick

[Vidar Berg]

Hm, not sure why the logging isn't working, but could you try to log the PC register value as well, then look up the PC address in the disassembly view to see if it points to the faulting instruction.

I'm also happy to try debugging this here in case you are able to share a minimal version of your project. 

*Edit* Here is a screenshot showing what it may look like when logging is enabled

[patjshan]

I fixed the logger, a macro was being redefined and I hadn't noticed the first time. Now the output looks like this (i tried to attach this as a screenshot but it wouldn't allow me to):

<error> hardfault: HARD FAULT at 0x00000000
<error> hardfault: R0: 0x2000FE9C R1: 0x20003234 R2: 0x2000FE9C R3: 0x00000000
<error> hardfault: R12: 0x0000000D LR: 0x0003D1D9 PSR: 0x20000026
<error> hardfault: Cause: The processor has attempted to execute an instruction that makes illegal use of the EPSR.

[Vidar Berg]

That's good, it makes debugging a bit easier. The hardfault seems to be occuring in the the SD_EVT_IRQn context (ie. inside one of the softdevice handlers) according to the PSR register (ISR number = 0x26 - 0x10 = SWI2_EGU2_IRQn) . And the fault itself is caused by the program jumping to address 0x0 I think.

Are you doing anything interesting inside the HVX_TX_Complete event?

[patjshan]

Not really, up until recently I didn't care about the tx complete evt so I wasn't handling it anywhere. Since I had the problem I've added a debug line that just prints out that the evt has happened but it never gets that far