Refer to ble_app_hrs_freertos example.Error calling xQueueReceive for the second time.

You have the hardfault instruction given here -> 0x20009834.

You can try to look at the map file and get the context in which the hardfault is happening.

Also make sure that there are no stack overflows due to the limited task stack sizes you create.

You have the hardfault instruction given here -> 0x20009834.

You can try to look at the map file and get the context in which the hardfault is happening.

Also make sure that there are no stack overflows due to the limited task stack sizes you create.

Hi,

I can confirm that it is not limited task.(I tried modifying the task usStackDepth)

The context of 0x20009444 was not found in the map.

<info> app: beacon started.
<info> app: BitLink FreeRTOS example started.
<info> app: lte thread.
<info> app: ----RES OK [OK
]
<info> app: AT 1
<info> app: ----RES data:
<info> app: 38 36 34 34 37 35 30 34|86447504
<info> app: 39 39 39 39 39 35 35 |9999955
<info> app: IMEI 1
<info> app: ----RES data:
<info> app: 2B 43 43 49 44 3A 20 38|+CCID: 8
<info> app: 39 38 36 30 36 32 30 32|98606202
<info> app: 32 30 30 32 30 35 39 34|20020594
<info> app: 39 38 37 |987
<info> app: ICCID 1
<info> app: lte thread.
<error> hardfault: HARD FAULT at 0x20009444
<error> hardfault: R0: 0x2000A818 R1: 0x20008BEC R2: 0x2000A7EC R3: 0x00000000
<error> hardfault: R12: 0xA5A5A5A5 LR: 0x0002EE8F PSR: 0x2000A82C
<error> hardfault: Cause: The processor has attempted an illegal load of EXC_RETURN to the PC, as a result of an invalid context, or an invalid EXC_RETURN value.

In your map file you can see the below two lines (Line 38163)

 .text.record_find
                0x00000000000293f0       0xe4 Output/Release/Obj/btk_bitlink_s140/fds.o
 .text.records_stat
                0x00000000000294d4       0xe4 Output/Release/Obj/btk_bitlink_s140/fds.o

You can see that 0x20009444 lies in the function record_find. There are two different directions that you can try to debug this issue.

1. Assuming that this hardfault is infact caused by something inside record_find inside fds.c file. One place where I can see is the below line
   

              fds_header_t const * p_header = (fds_header_t*)p_token->p_addr;
   
               // A valid record was found, check its header for a match.
               if ((p_file_id != NULL) &&
                   (p_header->file_id != *p_file_id))
               {
                   continue;
               }
   
               if ((p_record_key != NULL) &&
                   (p_header->record_key != *p_record_key))
               {
                   continue;
               }

   
   It looks like p_header is being assigned from p_token->p_addr but I do not see any NULL pointer checkes on p_header. There is a possibility of null pointer dereference here. You can add the check like below 
   

              fds_header_t const * p_header = (fds_header_t*)p_token->p_addr;
   
               if(p_header == NULL)
               {
                   continue;
               }
        
               // A valid record was found, check its header for a match.
               if ((p_file_id != NULL) &&
                   (p_header->file_id != *p_file_id))
               {
                   continue;
               }
   
               if ((p_record_key != NULL) &&
                   (p_header->record_key != *p_record_key))
               {
                   continue;
               }

   
   
   
   
   
• john.liu said:

  <error> hardfault: Cause: The processor has attempted an illegal load of EXC_RETURN to the PC, as a result of an invalid context, or an invalid EXC_RETURN value.

If we can trust the bits set in UsageFault Status Register in the CortexM3 processor, then it is telling us that the PC load value from the exc_return is invalid. This happens when a wrong/corrupted stack frame is popped back into the registers rendering the PC value with garbage or corrupted value. This happens mostly when the stack size of the current or the tasks using neighboring stack pool overflow its stack usage. You can do two things for debugging this..

1. Increase the task stack size significantly for the task that is running fds.c context. I am guessing that this one of your application tasks, since softdevice_task (components\softdevice\common\nrf_sdh_freertos.c)  should not use flash usage, unless you are making flash operations from the softdevice events callback
2. Enable stack overflow checking in FreeRTOS and see if you have any hits. This is not a failsafe way of checking stack overflows but there is a great chance that a stack overflow is caught in these checks if there are any.