I am working with a particular encoder which uses 512M boot time allocated memory. I am supposed to allocate the memory through dts file configuration. The physical memory is devided into low and high as below in the dts file:
/* 256MB at 0x0 */
memory#0 {
device_type = "memory";
reg = <0x0 0x00000000 0x0 0x10000000>;
};
/* 2GB at 0x8010000000 */
memory#8000000000 {
device_type = "memory";
reg = <0x80 0x10000000 0x0 0x80000000>;
};
Now I want to allocate the boot time carved out memory from the high memory. I can think of creating a dts entry as below
encoder: encoder#0xxxxxxxxx {
compatible = "xyz, abc";
reg= <0x0 0x80000000 0x0 0x20000000>;
}
Here the encoder#xxxx is the actual device entry and it has already a set of register region as below:
encoder: encoder#0xxxxxxxxx{
compatible = "xyz, abc";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x0 0xxxxxxxxxx 0x0 0x1234>;
status = "disabled";
};
So after adding the carvedout memory the entry would look like this:
encoder: encoder#0xxxxxxxxx{
compatible = "xyz, abc";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x0 0xxxxxxxxxx 0x0 0x1234>;
reg= <0x0 0x80000000 0x0 0x20000000>;
status = "disabled";
};
Would this work? I am not sure though how the driver code would know where is the start address of the carved out memory and the size of it?
Can anyone please help?
Thanks.
I have achieved this by creating curving out memory from the lower part of the high memory for my device. To do this I modified my dtsi file to reflect the mew memory map as below:
/* 256MB at 0x0 - this is the low memory region*/
memory#0 {
device_type = "memory";
reg = <0x0 0x00000000 0x0 0x10000000>;
};
/* 1GB at 0x8010000000 - high memory region, this used to be 2GB earlier. I curved out to 1GB and allocated 1GB to my device*/
memory#8000000000 {
device_type = "memory";
reg = <0x80 0x10000000 0x0 0x40000000>;
};
/* 1GB carved out for my device.*/
my_device: mydevice#8050000000 {
compatible = "xxx,xxx-yyy";
reg = <0x00 0x20810000 0x0 0x010000>,
**<0x80 0x50000000 0x0 0x40000000>;**
interrupts = <GIC_SHARED xx IRQ_TYPE_LEVEL_HIGH>;
status = "disabled";
};
Allocation of 1GB was a bit too much and I have modified to it to 256MB but that is not important here.
Then in the driver I retried the memory details as below:
struct resource *res;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0); /*this is to get hold of the the registers of my device*/
res = platform_get_resource(pdev, IORESOURCE_MEM, 1); /* this is the device memory for my device which had been set aside in the dtsi file above.*/
For using the memories retrieve as above use the below:
res->start /* start address of the memory region */
res->end - res->start + 1 /* this is to calculate the size of the memory*/
devm_ioremap_resource(&pdev->dev, res); /* this will give the mapped kernel virtual address for the memory bank*/
Related
When I jump from FREERTOS App1 To FreeRTOS App2 the program is stuck in the default handler.
FreeRTOS App1 boundary - 0x0 To 0x14000
FreeRTOS App2 boundary - 0x15000 To 0x30000
#define FAPP2_ADDRESS ((uint32_t)0x15000)
#define FAPP2_SIZE ((uint32_t)0x15000)
#define MSP_SPMPU (0)
#define PSP_SPMPU (1)
void app_jumpTo(uint32_t jumpLocation)
{
if (jumpLocation != 0xFFFFFFFF)
{
__set_MSP (*(uint32_t*) jumpLocation);
__set_PC (*(uint32_t*) (jumpLocation + 4));
}
}
void jump_to_app2(void)
{
xTimerStop(g_rtos_timer0, 0);
R_IOPORT_Close (&g_ioport_ctrl);
__disable_irq ();
memset ((uint32_t*) NVIC->ICER, 0xFF, sizeof(NVIC->ICER));
memset ((uint32_t*) NVIC->ICPR, 0xFF, sizeof(NVIC->ICPR));
SysTick->CTRL = 0;
SCB->ICSR |= SCB_ICSR_PENDSTCLR_Msk;
SCB->VTOR = (uint32_t) FAPP2_ADDRESS;
/* Disable the HW Stack monitor for MSP and PSP */
R_MPU_SPMON->SP[MSP_SPMPU].PT = 0xA500;
R_MPU_SPMON->SP[PSP_SPMPU].PT = 0xA500;
R_MPU_SPMON->SP[MSP_SPMPU].CTL = 0x0000;
R_MPU_SPMON->SP[PSP_SPMPU].CTL = 0x0000;
//Jump to our application entry point
app_jumpTo ((uint32_t) FAPP2_ADDRESS);
}
Fault Status Windows shows
HFSR 0x40000000
MMFSR 0x0
UFSR 0x2
For a project I try do use the ESP8266 RTOS SDK.
First step I install the tools and the toolchain. The hello_world example and the other gpio example works fine. I try the softAP example and get a Guru Meditation Error: Core 0 panic'ed (StoreProhibited). Exception was unhandled Error. I figured out that the line 62 : .automode = WIFI_AUTH_WPA_WPA2_PSK not works. I tried WIFI_AUTH_WEP,WIFI_AUTH_WPA_PSK,WIFI_AUTH_WPA2_PSK but only with WIFI_AUTH_OPEN the softAP works. Anyone same behavior or some tips?
Console Trace:
ets Jan 8 2013,rst cause:1, boot mode:(3,6)
load 0x40100000, len 7040, room 16
tail 0
chksum 0xe5
load 0x3ffe8408, len 24, room 8
tail 0
chksum 0x6c
load 0x3ffe8420, len 3312, room 8
tail 8
chksum 0x75
csum 0x75
I (123) boot: ESP-IDF v3.4-rc 2nd stage bootloader
I (123) boot: compile time 19:41:32
I (207) qio_mode: Enabling default flash chip QIO
I (207) boot: SPI Speed : 40MHz
I (208) boot: SPI Mode : QOUT
I (212) boot: SPI Flash Size : 2MB
I (219) boot: Partition Table:
I (224) boot: ## Label Usage Type ST Offset Length
I (236) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (247) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (259) boot: 2 factory factory app 00 00 00010000 000f0000
I (271) boot: End of partition table
I (277) esp_image: segment 0: paddr=0x00010010 vaddr=0x40210010 size=0x52c80 (339072) map
I (406) esp_image: segment 1: paddr=0x00062c98 vaddr=0x40262c90 size=0x0f594 ( 62868) map
I (428) esp_image: segment 2: paddr=0x00072234 vaddr=0x3ffe8000 size=0x005fc ( 1532) load
I (429) esp_image: segment 3: paddr=0x00072838 vaddr=0x40100000 size=0x00080 ( 128) load
I (439) esp_image: segment 4: paddr=0x000728c0 vaddr=0x40100080 size=0x05560 ( 21856) load
I (460) boot: Loaded app from partition at offset 0x10000
I (481) wifi softAP: ESP_WIFI_MODE_AP
I (484) system_api: Base MAC address is not set, read default base MAC address from EFUSE
I (486) system_api: Base MAC address is not set, read default base MAC address from EFUSE
phy_version: 1163.0, 665d56c, Jun 24 2020, 10:00:08, RTOS new
I (557) phy_init: phy ver: 1163_0
I (567) wifi softAP: ----------------###------------
ESP_ERROR_CHECK failed: esp_err_t 0x2 (ERROR) at 0x4021f7cc
file: "softap_example_main.c" line 73
func: wifi_init_softap
expression: esp_wifi_set_config(ESP_IF_WIFI_AP, &wifi_config)
abort() was called at PC 0x4021f7cf on core 0
Guru Meditation Error: Core 0 panic'ed (StoreProhibited). Exception was unhandled.
Core 0 register dump:
PC : 0x40221c72 PS : 0x00000030 A0 : 0x40221c70 A1 : 0x3ffeb550
A2 : 0x00000000 A3 : 0xffffffdb A4 : 0x00000001 A5 : 0x00000001
A6 : 0x00000000 A7 : 0x4026663c A8 : 0x00000020 A9 : 0x00000000
A10 : 0x00000008 A11 : 0x00000000 A12 : 0x00000000 A13 : 0x00000000
A14 : 0x00000000 A15 : 0x00000000 SAR : 0x0000001e EXCCAUSE: 0x0000001d
Backtrace: 0x40221c72:0x3ffeb550 0x4021f7d2:0x3ffeb560 0x4022182e:0x3ffeb570 0x40221894:0x3ffeb630 0x402118ef:0x3ffeb640
Example Code from GitHub: (examples/wifi/getting_started/softAP/main/softap_example_main.c)
/* WiFi softAP Example
This example code is in the Public Domain (or CC0 licensed, at your option.)
Unless required by applicable law or agreed to in writing, this
software is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR
CONDITIONS OF ANY KIND, either express or implied.
*/
#include <string.h>
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "esp_system.h"
#include "esp_wifi.h"
#include "esp_event.h"
#include "esp_log.h"
#include "nvs_flash.h"
#include "lwip/err.h"
#include "lwip/sys.h"
/* The examples use WiFi configuration that you can set via project configuration menu.
If you'd rather not, just change the below entries to strings with
the config you want - ie #define EXAMPLE_WIFI_SSID "mywifissid"
*/
#define EXAMPLE_ESP_WIFI_SSID CONFIG_ESP_WIFI_SSID
#define EXAMPLE_ESP_WIFI_PASS CONFIG_ESP_WIFI_PASSWORD
#define EXAMPLE_MAX_STA_CONN CONFIG_ESP_MAX_STA_CONN
static const char *TAG = "wifi softAP";
static void wifi_event_handler(void* arg, esp_event_base_t event_base,
int32_t event_id, void* event_data)
{
if (event_id == WIFI_EVENT_AP_STACONNECTED) {
wifi_event_ap_staconnected_t* event = (wifi_event_ap_staconnected_t*) event_data;
ESP_LOGI(TAG, "station "MACSTR" join, AID=%d",
MAC2STR(event->mac), event->aid);
} else if (event_id == WIFI_EVENT_AP_STADISCONNECTED) {
wifi_event_ap_stadisconnected_t* event = (wifi_event_ap_stadisconnected_t*) event_data;
ESP_LOGI(TAG, "station "MACSTR" leave, AID=%d",
MAC2STR(event->mac), event->aid);
}
}
void wifi_init_softap()
{
tcpip_adapter_init();
ESP_ERROR_CHECK(esp_event_loop_create_default());
wifi_init_config_t cfg = WIFI_INIT_CONFIG_DEFAULT();
ESP_ERROR_CHECK(esp_wifi_init(&cfg));
ESP_ERROR_CHECK(esp_event_handler_register(WIFI_EVENT, ESP_EVENT_ANY_ID, &wifi_event_handler, NULL));
wifi_config_t wifi_config = {
.ap = {
.ssid = EXAMPLE_ESP_WIFI_SSID,
.ssid_len = strlen(EXAMPLE_ESP_WIFI_SSID),
.password = EXAMPLE_ESP_WIFI_PASS,
.max_connection = EXAMPLE_MAX_STA_CONN,
.authmode = WIFI_AUTH_WPA_WPA2_PSK
},
};
if (strlen(EXAMPLE_ESP_WIFI_PASS) == 0) {
wifi_config.ap.authmode = WIFI_AUTH_OPEN;
}
ESP_ERROR_CHECK(esp_wifi_set_mode(WIFI_MODE_AP));
ESP_ERROR_CHECK(esp_wifi_set_config(ESP_IF_WIFI_AP, &wifi_config));
ESP_ERROR_CHECK(esp_wifi_start());
ESP_LOGI(TAG, "wifi_init_softap finished. SSID:%s password:%s",
EXAMPLE_ESP_WIFI_SSID, EXAMPLE_ESP_WIFI_PASS);
}
void app_main()
{
ESP_ERROR_CHECK(nvs_flash_init());
ESP_LOGI(TAG, "ESP_WIFI_MODE_AP");
wifi_init_softap();
}
You have to run idf.py menuconfig and set the SSID and password values.
Password´s under 8 characters gets a Guru-Meditation ERR if the
wifi_config.ap.authmode = WIFI_AUTH_WEP or,
wifi_config.ap.authmode = WIFI_AUTH_WPA_PSK or,
wifi_config.ap.authmode = WIFI_AUTH_WPA2_PSK . Other authmodes not yet testet.
To provid this Error, make sure your pw has more then 7 characters or/and set
the If-Condition after the wifi_config to:
if (strlen(EXAMPLE_ESP_WIFI_PASS) < 8) {
wifi_config.ap.authmode = WIFI_AUTH_OPEN;
ESP_LOGI(TAG," pw-lenght under 8 charcters. Set WIFI_AUTH_OPEN");
}
Your WiFi is not protectet but your µC not crashes.
I am facing an issue while using the cJSON Library. I am assuming that there is a memory leak that is breaking the code after a certain time (40 mins to 1 hr).
I have copied my code below :
void my_work_handler_5(struct k_work *work)
{
char *ptr1[6];
int y=0;
static int counterdo = 0;
char *desc6 = "RSRP";
char *id6 = "dBm";
char *type6 = "RSRP";
char rsrp_str[100];
snprintf(rsrp_str, sizeof(rsrp_str), "%d", rsrp_current);
sensor5 = cJSON_CreateObject();
cJSON_AddItemToObject(sensor5, "description", cJSON_CreateString(desc6));
cJSON_AddItemToObject(sensor5, "Time", cJSON_CreateString(time_string));
cJSON_AddItemToObject(sensor5, "value", cJSON_CreateNumber(rsrp_current));
cJSON_AddItemToObject(sensor5, "unit", cJSON_CreateString(id6));
cJSON_AddItemToObject(sensor5, "type", cJSON_CreateString(type6));
/* print everything */
ptr1[counterdo] = cJSON_Print(sensor5);
printk("Counterdo value is : %d\n", counterdo);
cJSON_Delete(sensor5);
counterdo = counterdo + 1;
if (counterdo==6){
for(y=0;y<=counterdo;y++){
free(ptr1[y]);
}
counterdo = 0;
}
return;
}
I read some other threads regarding freeing up the memory and tried to do the same. Can anyone let me know if this is the right approach to free up the space allocated to the cJSON Object.
Regards,
Adeel.
Since cJSON is a portable library with no dependencies, this is better to look for a potential issue in your code on a PC: they are specialized tools available in this environment for facilitating the investigation. I am assuming here you have a Linux system, a Windows system with WSL or WSL2 installed, or a Linux virtual machine, available, and gcc, valgrind installed.
A minimal, self-contained, portable version of your code could be:
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <cJSON.h>
static int rsrp_current = 1;
static char *time_string = NULL;
void
my_work_handler_5 ()
{
char *ptr1[6];
int y = 0;
static int counterdo = 0;
char *desc6 = "RSRP";
char *id6 = "dBm";
char *type6 = "RSRP";
char rsrp_str[100];
snprintf (rsrp_str, sizeof (rsrp_str), "%d", rsrp_current);
cJSON *sensor5 = cJSON_CreateObject ();
cJSON_AddItemToObject (sensor5, "description", cJSON_CreateString (desc6));
cJSON_AddItemToObject (sensor5, "Time", cJSON_CreateString (time_string));
cJSON_AddItemToObject (sensor5, "value", cJSON_CreateNumber (rsrp_current));
cJSON_AddItemToObject (sensor5, "unit", cJSON_CreateString (id6));
cJSON_AddItemToObject (sensor5, "type", cJSON_CreateString (type6));
/* print everything */
ptr1[counterdo] = cJSON_Print (sensor5);
printf ("Counterdo value is : %d\n", counterdo);
cJSON_Delete (sensor5);
counterdo = counterdo + 1;
if (counterdo == 6)
{
for (y = 0; y <= counterdo; y++)
{
free (ptr1[y]);
}
counterdo = 0;
}
return;
}
int
main (int argc, char **argv)
{
time_t curtime;
time (&curtime);
for (int n = 0; n < 3 * 6; n++)
{
my_work_handler_5 ();
}
}
Build procedure:
wget https://github.com/DaveGamble/cJSON/archive/v1.7.14.tar.gz
tar zxf v1.7.14.tar.gz
gcc -g -O0 -IcJSON-1.7.14 -o cjson cjson.c cJSON-1.7.14/cJSON.c
Running valgrind on the program:
valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes --verbose ./cjson
..indicates some memory is being freed that was not previously allocated: Invalid free() / delete / delete[] / realloc():
==6747==
==6747== HEAP SUMMARY:
==6747== in use at exit: 0 bytes in 0 blocks
==6747== total heap usage: 271 allocs, 274 frees, 14,614 bytes allocated
==6747==
==6747== All heap blocks were freed -- no leaks are possible
==6747==
==6747== ERROR SUMMARY: 21 errors from 2 contexts (suppressed: 0 from 0)
==6747==
==6747== 3 errors in context 1 of 2:
==6747== Invalid free() / delete / delete[] / realloc()
==6747== at 0x483CA3F: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==6747== by 0x1094DA: my_work_handler_5 (cjson.c:42)
==6747== by 0x10955A: main (cjson.c:59)
==6747== Address 0x31 is not stack'd, malloc'd or (recently) free'd
==6747==
==6747==
==6747== 18 errors in context 2 of 2:
==6747== Conditional jump or move depends on uninitialised value(s)
==6747== at 0x483C9F5: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==6747== by 0x1094DA: my_work_handler_5 (cjson.c:42)
==6747== by 0x10955A: main (cjson.c:59)
==6747== Uninitialised value was created by a stack allocation
==6747== at 0x109312: my_work_handler_5 (cjson.c:11)
==6747==
==6747== ERROR SUMMARY: 21 errors from 2 contexts (suppressed: 0 from 0)
Replacing:
for (y = 0; y <= counterdo; y++)
{
free (ptr1[y]);
}
by:
for (y = 0; y < counterdo; y++)
{
free (ptr1[y]);
}
and executing valgrind again:
==6834==
==6834== HEAP SUMMARY:
==6834== in use at exit: 1,095 bytes in 15 blocks
==6834== total heap usage: 271 allocs, 256 frees, 14,614 bytes allocated
==6834==
==6834== Searching for pointers to 15 not-freed blocks
==6834== Checked 75,000 bytes
==6834==
==6834== 1,095 bytes in 15 blocks are definitely lost in loss record 1 of 1
==6834== at 0x483DFAF: realloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==6834== by 0x10B161: print (cJSON.c:1209)
==6834== by 0x10B25F: cJSON_Print (cJSON.c:1248)
==6834== by 0x1094AB: my_work_handler_5 (cjson.c:30)
==6834== by 0x10959C: main (cjson.c:59)
==6834==
==6834== LEAK SUMMARY:
==6834== definitely lost: 1,095 bytes in 15 blocks
==6834== indirectly lost: 0 bytes in 0 blocks
==6834== possibly lost: 0 bytes in 0 blocks
==6834== still reachable: 0 bytes in 0 blocks
==6834== suppressed: 0 bytes in 0 blocks
==6834==
==6834== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Some memory is definitively being leaked.
The reason is that char *ptr1[6] is not static, and is therefore created on the stack every time my_work_handler_5() is being called. The pointers that were returned are by cJSON_Print() are therefore lost between two calls, and free() is being called on arbitrary pointer values, since ptr1[] is not initialized as it could be:
char *ptr1[6] = { NULL, NULL, NULL, NULL, NULL, NULL };
Since you are freeing memory every 6 calls, this is causing the memory leak you were suspecting.
Replacing:
char *ptr1[6];
by:
static char *ptr1[6];
compiling, running valgrind again:
==6927==
==6927== HEAP SUMMARY:
==6927== in use at exit: 0 bytes in 0 blocks
==6927== total heap usage: 271 allocs, 271 frees, 14,614 bytes allocated
==6927==
==6927== All heap blocks were freed -- no leaks are possible
==6927==
==6927== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
The modified version of the program should now work on your bare-metal system.
When I am trying to adjust of stack size of threads:
- (void)testStack:(NSInteger)n {
NSThread *thread = [[NSThread alloc]initWithTarget:self selector:#selector(dummy) object:nil];
NSUInteger size = 4096 * n;
[thread setStackSize:size];
[thread start];
}
- (void)dummy {
NSUInteger bytes = [[NSThread currentThread] stackSize];
NSLog(#"%#", #(bytes));
}
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
// Override point for customization after application launch.
for (NSInteger i = 126; i <= 130; i++) {
[self testStack:i];
}
return YES;
}
in the output, the size is not changed:
2015-06-19 11:05:06.912 Stack[52982:2082454] 524288
2015-06-19 11:05:06.913 Stack[52982:2082457] 524288
2015-06-19 11:05:06.913 Stack[52982:2082456] 524288
2015-06-19 11:05:06.913 Stack[52982:2082458] 524288
2015-06-19 11:05:06.913 Stack[52982:2082455] 524288
is the iPhone stack size fixed?
p.s. I am testing the above in iPhone 6 Plus, debug mode.
UPDATE: the stack can be adjusted when running in the Simulator on MacBook:
2015-06-19 11:25:17.042 Stack[1418:427993] 528384
2015-06-19 11:25:17.042 Stack[1418:427994] 532480
2015-06-19 11:25:17.042 Stack[1418:427992] 524288
2015-06-19 11:25:17.042 Stack[1418:427991] 520192
2015-06-19 11:25:17.042 Stack[1418:427990] 516096
The stack size is bounded on the device, and in most cases cannot exceed 1MB for the main thread on iPhone OS, nor can it be shrunk.
The minimum allowed stack size for secondary threads is 16 KB and the stack size must be a multiple of 4 KB. The space for this memory is set aside in your process space at thread creation time, but the actual pages associated with that memory are not created until they are needed.
Actually you can set it. I am not sure if this changed with iOS 10, but on iOS 10.2.1 this does work. The only limitation is that the stack size has to be a multiple of 4kb.
pthread_attr_t tattr;
int ret = pthread_attr_init ( &tattr ) ;
size_t size;
ret = pthread_attr_getstacksize(&tattr, &size);
printf ( "Get: ret=%d,size=%zu\n" , ret , size ) ;
size = 4096 * 512 ;
ret = pthread_attr_setstacksize(&tattr, size);
int ret2 = pthread_attr_getstacksize(&tattr, &size);
printf ( "Set & Get: ret=%d ret2=%d,size=%zu\n" , ret , ret2 , size ) ;
I'm using breakpad in my project to handle crashes and generate stack trace.
In stack trace, there are different ways how function calls info found by stackwalker. Process described here Finding_the_caller_frame:
Found by: stack scanning
Found by: call frame info
Found by: given as instruction pointer in context
What`s the difference between them? And more importantly how they could help in terms of debugging?
Thread 0 (crashed)
0 test_google_breakpad!crash [test_breakpad.cpp : 17 + 0x4]
r4 = 0x00015530 r5 = 0xbea2cbe4 r6 = 0xffffff38 r7 = 0xbea2cb5c
r8 = 0x00000000 r9 = 0x00000000 r10 = 0x00000000 fp = 0x00000000
sp = 0xbea2cb50 lr = 0x00009025 pc = 0x00008f84
Found by: given as instruction pointer in context
1 test_google_breakpad!main [test_breakpad.cpp : 25 + 0x3]
r4 = 0x00015530 r5 = 0xbea2cbe4 r6 = 0xffffff38 r7 = 0xbea2cb5c
r8 = 0x00000000 r9 = 0x00000000 r10 = 0x00000000 fp = 0x00000000
sp = 0xbea2cb50 pc = 0x00009025
Found by: call frame info
2 libc.so + 0x164e5
r4 = 0x00008f64 r5 = 0xbea2cc34 r6 = 0x00000001 r7 = 0xbea2cc3c
r8 = 0x00000000 r9 = 0x00000000 r10 = 0x00000000 fp = 0x00000000
sp = 0xbea2cc18 pc = 0x400c34e7
Found by: call frame info
The instruction pointer method means that there's a CPU register already pointing at the function's memory location so there was no need to search for the function. This is the easiest and most reliable way to find the current stack frame.
Next using the call frame technique you can find the caller of the current function by looking at the place in stack memory where the return address is stored. This is the exact technique that a "return" would use to find its return destination. This technique can be chained because each previous call also put its return value on the stack. This is pretty reliable, but can fail if some stack memory got corrupted (maybe stack overflow, maybe buggy pointer write) and one or more return addresses were obliterated.
Finally the least reliable technique is to just search the stack memory for anything that looks like a function address. This can help you recover from a corrupted stack but it can be hard to tell data (including function pointers!) apart from function addresses so it's guesswork. If you find one, though, you can often then chain back to the call frame technique if you find some stack that wasn't trashed.