This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

app_error_fault_handler() called with PC at 0x128A0

Given this error handler function...

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
void app_error_fault_handler(uint32_t id, uint32_t pc, uint32_t info)
{
error_info_t * i = (error_info_t *)info;
NRF_LOG_ERROR("%d, %s line %d\n", (int)i->err_code, (int)i->p_file_name, (int)i->line_num);
NRF_LOG_ERROR("ID: %d, PC: %d\n", (int)id, (int)pc);
// Omitted: more logging.
NRF_LOG_FINAL_FLUSH();
// Omitted: reset.
}
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

and this logging from it with the Segger attached...

Fullscreen
1
2
3
E error 1405, KGJ`h??@h line 1024
E error ID: 1, PC: 75936
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

how do I debug this?

I presume the info passed in is bogus and just points to some random part of memory.

75936 is 0x128A0 and that's in the soft device.

My code is not doing anything in particular when it hits this. It tends to happen out of the blue. The nRF52832 is not in a BLE connection at the time but it is advertising. It's listening to a GPS module over SPI, running a bunch of timers, and that's about it.

Also, NRF_LOG_FINAL_FLUSH() doesn't appear to work, because I frequently see this while the Segger is attached, testing on the desk, but I never see it logged to my in-memory log in field testing.

[Edit]

Here are three log "files" to demonstrate my logging problem.

This one is a Segger RTT log taken from desk testing with the debugger attached. I get the error logging for the assert that stops execution just fine.

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
------
I state RESET
D state Reset reasons:
D state wake from system off from GPIO
I pwr_mgmt Init
D power Charge state: CHARGE_STATE_NOT_CHARGING
D power Started
D acc Programming for phase 2
D acc Now programmed for state ACC_STATE_PHASE_2
D acc Resting state from last sys off: -9, 4, 62
D acc 0, 0
D acc 11, 0
D acc 28, 0
D acc 48, 0
D acc 62, 0
D acc 62, 0
D acc 62, 28
D acc 62,108
D acc 62,189
D acc 62,226
D acc 72,226
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

This one is taken from my in-RAM log generated during field testing, but read back once I'm back at the desk with a tiny pynrfjprog Python script that just converts a RAM region to ASCII. I'm not worried about the PANIC at the end - that's just the panic function in my log backend being called as the Nordic goes into sys off. This is an example of a "good" in-RAM log for me - I can see everything up to the last sys off or assert.

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
I pwr_mgmt Init
D power Charge state: CHARGE_STATE_NOT_CHARGING
D power Started
D acc Programming for phase 2
D acc Now programmed for state ACC_STATE_PHASE_2
D acc Resting state from last sys off: 18472, 19048, -25106
D acc 67,188
D acc 140,373
D acc 203,555
D acc 264,738
D acc Threshold crossed
D modem Powering on
D state Event: modem on
D modem > AT$I=10
D modem < 00228892
D modem Response time: 19 ms
D modem Powered off
I state STATE_RESET -> BONDED
D power Battery ADC value: 1491/4096
I power Bat: 3.91V
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

And this one is taken from my in-RAM log again, same as the second one, but this one is "bad" because there's no sys off at the end and no assert. I have some normal debug logging from my GPS driver and then a lot of memory that looks like it never got zero'ed out when the in-RAM log was initialised. I can't tell what the software died from here. I suspect an error, because the device isn't doing anything, but I can't tell what's happened.

Note that my in-RAM log is a circular buffer so it'll wrap around to the beginning, which is why this one doesn't start with the same init stuff.

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
D gps > $PUBX,40,GSA,0,0,0,0,0,0*4E
D gps > $PUBX,40,VTG,0,0,0,0,0,0*5E
D gps > $PUBX,40,RMC,0,0,0,0,0,0*47
D gps > $PUBX,40,GLL,0,0,0,0,0,0*5C
D gps > $PUBX,40,GGA,0,0,0,0,1,0*5B
D gps > $PUBX,40,GSV,0,0,0,0,1,0*58
D gps NMEA output set for no fix yet. Starting 1 Hz timer.
$SV 0
D gps Started
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

[Edit]

Here's my error handling code.

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
/* Copyright (C) Bike Tracker Ltd - All Rights Reserved
* Unauthorized copying of this file, via any medium is strictly prohibited.
* Proprietary and confidential.
* Written by Eliot Stock, eliot@biketracker.cc
*/
#include <stdint.h>
#include <stdio.h>
#include <stdbool.h>
#include "app_error.h"
#include "ble_err.h"
#include "nrf_delay.h"
#include "nrf_nvic.h"
#include "nrf_soc.h"
#include "boards.h"
#include "util.h"
#include "error.h"
#define NRF_LOG_MODULE_NAME error
#include "nrf_log.h"
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

The build I'm testing with is a BUILD_FIELD_TEST.