Hard fault SD132 with timers and ble rwauth

RE: Hard fault SD132 with timers and ble rwauth

blungreen — Mon, 21 Mar 2016 10:13:23 GMT

Hi, i submitted a new case with the project. Thank you

RE: Hard fault SD132 with timers and ble rwauth

Vidar Berg — Fri, 18 Mar 2016 09:40:58 GMT

Are you able to share your project so I can try to debug here at my end? You can create a support ticket on mypage in case you don't want to post it here.

RE: Hard fault SD132 with timers and ble rwauth

blungreen — Fri, 18 Mar 2016 08:46:56 GMT

Hi, thanks for the reply, as you pointed out the timer instance is not the problem and it looks stack related.

It seems that when sd_ble_gatts_rw_authorize_reply() gets called, for some reason the program jumps to a specific address and, depending on what code is compiled there, i get HardFault. Just modify one char in a string makes the program to jump on another place.

Besides that, there are cases where added code doesn't brake program, and this is why i didn't noticed any fault untill i added timer instance.

For what i was able to test, It looks like the other BLE operations don't affect the code execution (no corruption). Another thing that i noted is that if i debug and do step in on rw_authorize_reply(), i don't get hardfault apparently. If i do run or stepover, crash. Maybe it is something related to concurrent use of the stack area between my application and the sd.

RE: Hard fault SD132 with timers and ble rwauth

Vidar Berg — Thu, 17 Mar 2016 19:32:03 GMT

Posted my reply as an answer since the comments have a limit on number of characters.

RE: Hard fault SD132 with timers and ble rwauth

Vidar Berg — Thu, 17 Mar 2016 19:30:27 GMT

Sorry for not responding sooner. I does sound like the stack frame may have gotten corrupted somehow, but don't see why this would happen only after you added the timer instance. It could however explain why the same code works when built in Keil. Difference between these two is that Keil places the call stack just above the globals whereas GCC places it in top of RAM. In other words, it is possible that the same thing is happening in your Keil project, but it doesn't corrupt the stack since it's placed lower in RAM.

I would suggest to try to move the stack upwards in RAM to see if this potential corruption is happening at a particular address in your current stack area. You can do that by increasing the RAM size in the linker script so that the total including softdevice is 64KB instead of 32K. Note that this will not work on the engineering A part (PCA10036) as the second RAM block was mapped to a different address range.

RE: Hard fault SD132 with timers and ble rwauth

blungreen — Wed, 16 Mar 2016 11:11:17 GMT

This is the requested screenshot

As you can see, when i perform an authorized read, the printf "ENTER SD_BLE_GATTS", then rw_auth_reply() gets executed but it looks like the return address is corrupted infact the code jumps to strncpy and then the Hardfault. What i have seen is that, if i change some lines of code (example i substitute "LOCKED" with "LOCKED1234" in strncpy), the program jumps to other places. It looks like a buffer overflow of some kind

RE: Hard fault SD132 with timers and ble rwauth

Vidar Berg — Wed, 16 Mar 2016 09:22:51 GMT

Could you add a screen dump of the disassemble view at 0x21744 together with the core registers when the exception has occurred?

To be able to set breakpoints in the startup file you need to do the following:

change the file extension from .s to capital .S in /components/toolchain/gcc
Add the -g3 option to the assembler flags.

As a side note, have experienced problems with debugging after updating to the 5.0 release of arm-none-eabi. I'd suggest to downgrade to 4.9 if you are using this one.

RE: Hard fault SD132 with timers and ble rwauth

blungreen — Tue, 15 Mar 2016 13:37:47 GMT

In gcc makefile i can see that ASM_SOURCE_FILE included is gcc_startup_nrf52.s not arm_startup_nrf52.s. Is it correct? I did open gcc_startup_nrf52.s anyway in Eclipse and set a breakpoint at line after HardFault_Handler: line (394) but it doesn't hit. But if i pause i can see the last call in the stack is

HardFault_Handler() at 0x2431a

The R0 here is 0x21744, which is the line inside on_rwauth() function just before rw_auth_reply()

RE: Hard fault SD132 with timers and ble rwauth

Carles — Tue, 15 Mar 2016 13:19:01 GMT

Yeah that's not a problem, it just means you're wasting some RAM between the SD and the app areas.

I assume you have a breakpoint in HardFault_Handler in arm_startup_nrf2.s. Can you check the value of the R0 register when that breakpoint hits?

RE: Hard fault SD132 with timers and ble rwauth

blungreen — Tue, 15 Mar 2016 13:16:03 GMT

Yes i'm sure and app_error_fault_handler is not hit. Here is something more, this behaviour is seen in Eclipse GCC. I tried to compile with Keils 5 and i don't see HardFault anymore. One thing i noted in GCC is that sd debug info says:

RAM START ADDR 0x20001F00 should be adjusted to 0x20001E00
RAM SIZE should be adjusted to 0xE200 
sd_ble_enable: RAM START at 0x20001F00
sd_ble_enable: app_ram_base should be adjusted to 0x20001E10
ram size should be adjusted to 0xE1F0

I read that this shouldn't bother anyway.

RE: Hard fault SD132 with timers and ble rwauth

Carles — Tue, 15 Mar 2016 11:42:36 GMT

Not sure to be honest, but have you made sure you don't enter the block at all? Also can you verify if you are hitting the app_error_fault_handler() function, which will be called if APP_ERROR_CHECK() fails?

RE: Hard fault SD132 with timers and ble rwauth

blungreen — Tue, 15 Mar 2016 11:34:54 GMT

Here is something strange: in my on_rwauth() i manage the read of another characteristic (i didnt show on snippet), which i don't use. BUT if i comment this section i don't get hard fault apparently. I tried to investigate the block and seems that leaving APP_ERROR_CHECK(err_code) after its rw_authorize_reply(), triggers the hard fault when i read the used characteristic. I never enter the block, so uncommenting the code inside shouldn't change anything. Might be some king of overlap in the memory?

RE: Hard fault SD132 with timers and ble rwauth

Carles — Tue, 15 Mar 2016 11:20:06 GMT

Also R0 should contain the PC that triggered the hard fault. If you have a breakpoint in your hard fault handler then take a look at R0 to find out which instruction triggered it.

RE: Hard fault SD132 with timers and ble rwauth

Carles — Tue, 15 Mar 2016 11:07:10 GMT

So if you comment the call to rw_authorize_reply() then it still hard faults?

RE: Hard fault SD132 with timers and ble rwauth

blungreen — Tue, 15 Mar 2016 11:05:00 GMT

Thank you Carles, i corrected the gattc error but problem is still there. I have tried to comment but bad luck for now. I can't spot anything. Is there something i can do with HardFault_handler?

RE: Hard fault SD132 with timers and ble rwauth

Carles — Tue, 15 Mar 2016 10:32:42 GMT

Actually, I did spot something:

sd_ble_gatts_rw_authorize_reply(p_ble_evt->evt.gattc_evt.conn_handle

should be

sd_ble_gatts_rw_authorize_reply(p_ble_evt->evt.gatts_evt.conn_handle

RE: Hard fault SD132 with timers and ble rwauth

Carles — Tue, 15 Mar 2016 10:31:38 GMT

Thanks for the snippet, I see nothing obviously wrong in there. Have you tried commenting out the call to rw_authorize_reply() (leaving the timers on) to see if that still hardfaults?

RE: Hard fault SD132 with timers and ble rwauth

blungreen — Tue, 15 Mar 2016 10:13:24 GMT

I added a snippet in the question, the behaviour is: if system not initialized (system locked) print HELLO, else print state of LED.

RE: Hard fault SD132 with timers and ble rwauth

Carles — Tue, 15 Mar 2016 09:47:50 GMT

Can you perhaps provide a snippet of the code you use to call rw_authorize_reply() ?

RE: Hard fault SD132 with timers and ble rwauth

blungreen — Tue, 15 Mar 2016 09:46:07 GMT

Hi, thank you for the reply. The pointers look good to me, what i do in the reply is just strncpy "HELLO" into a buffer, set the buffer and its strlen to the param, and set the update flag to 1. SD seems to crash on authorized read, when program enters rw_authorize_reply(). It is very weird cause I get hard fault only if i place functions in the main loop

RE: Hard fault SD132 with timers and ble rwauth

Carles — Mon, 14 Mar 2016 14:18:02 GMT

This sounds like the data you are providing to rw_authorize_reply() is not valid. Can you check the pointer you are providing? Have you taken a look at the SD migration document, and more specifically the section where it describes how to handle authorized operations since there have been substantial changes since s130 v1.