Access physical address from kernel space in Linux - memory

I'm writing a kernel module that needs access to a memory region outside the Kernel and User spaces. I know the physical address and the size of such a memory. I've tried with ioremap(), but the virtual address returned by such a function points to a phisical address different from the one I gave as an argument to ioremap. Then I tried to use phys_to_virt() after ioremap(), this time the virtual address obtained points to the correct physical one, however when I try to access an element inside such memory area I get the following error: Unable to handle kernel paging request at virtual address ffffff801400000f
What I'm wrong?
EDIT:
Code snippet:
#define FLAG_SIZE 1
#define BUF_SIZE 4
#define ELEM_SIZE 5
res = ioremap_nocache(MEMORY_ADDR, BUF_SIZE*ELEM_SIZE);
void *virt = phys_to_virt(MEMORY_ADDR);
printk(KERN_INFO "Physical address %px mapped in virtual address %px\n", virt_to_phys(virt), virt);
// DEBUG: print buffers content
char *flags = res + BUF_SIZE*(ELEM_SIZE-FLAG_SIZE);
for(i=0; i < BUF_SIZE; i++){
printk(KERN_INFO "row %d [flag: %c]: %d\n", i, readb(flags + i), virt + i*ELEM_SIZE);
}
where:
-MEMORY_ADDR: is the physical address
-BUF_SIZE: number of elements in the buffer
-ELEM_SIZE: size of the elements
The flags buffers is an array of chars at the end of such memory region
The full outputs returned are:
Physical address 1409286144 mapped in virtual address 335544320
Unable to handle kernel paging request at virtual address ffffff801400000f
Mem abort info:
ESR = 0x96000006
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000006
CM = 0, WnR = 0
swapper pgtable: 4k pages, 39-bit VAs, pgdp=00000000407c8000
[ffffff801400000f] pgd=000000004fffb003, pud=000000004fffb003, pmd=0000000000000000
Internal error: Oops: 96000006 [#1] SMP
Modules linked in: source(O)
CPU: 1 PID: 107 Comm: ifconfig Tainted: G O 5.4.88 #1
Hardware name: linux,dummy-virt (DT)
pstate: 20000005 (nzCv daif -PAN -UAO)
pc : getFlag+0x24/0x40 [source]
lr : shmem_net_open+0x168/0x2c0 [source]
sp : ffffffc010b4b9d0
x29: ffffffc010b4b9d0 x28: 0000000000001043
x27: ffffff800e2b4c00 x26: ffffffc01077c000
x25: 0000000000000005 x24: ffffffc008661158
x23: 0000000000000004 x22: 0000000000000000
x21: ffffff800e24e200 x20: ffffff800e255000
x19: ffffff800e255858 x18: 0000000000020000
x17: 000000004a0b804e x16: 0000000031b76cb0
x15: ffffffc010859c40 x14: 0720072007200720
x13: 0720073007320733 x12: 0734073407350735
x11: 0733073307200773 x10: 0773076507720764
x9 : 076407610720076c x8 : 000000000000006f
x7 : 076907760720076e x6 : 0000000000000001
x5 : ffffff800e255840 x4 : 0000000000000005
x3 : 0000008040000000 x2 : 0000000000000000
x1 : 000000000000000f x0 : ffffff801400000f
Call trace:
getFlag+0x24/0x40 [source]
__dev_open+0xe4/0x160
__dev_change_flags+0x160/0x1c0
dev_change_flags+0x20/0x60
devinet_ioctl+0x63c/0x700
inet_ioctl+0x2f4/0x360
sock_do_ioctl+0x44/0x2b0
sock_ioctl+0x1c8/0x510
do_vfs_ioctl+0x984/0xb70
ksys_ioctl+0x44/0x90
__arm64_sys_ioctl+0x1c/0xc0
el0_svc_common.constprop.0+0x68/0x160
el0_svc_handler+0x6c/0x90
el0_svc+0x8/0x1fc
Code: 1b047c21 8b21c041 8b010000 cb030000 (39400000)
---[ end trace 5a219c0b95978c47 ]---
Segmentation fault
The processor used is an Armv8 cortex 53
EDIT 2: corrected the previous code snippets, now no kernel panic, however the output is incorrect:
[SHMEM_NET] Physical address 0000000054000000 mapped in virtual address ffffffc01000d000
row 0 [flag: ]: 268488704
row 1 [flag: E]: 268488707
row 2 [flag: E]: 268488710
row 3 [flag: E]: 268488713
row 4 [flag: E]: 268488716
The issue is that I should find the first 'E' at row 0 and row 4 should be instead outside the mapped region. Moreover if now I modify such memory region, the modifications can be seen by this machine, but other machines accessing same memory regions still sees the old values.

The virtual address' returned by ioremap and phys_to_virt are not the same.
ioremap: creates a new mapping page table
phys_to_virt: substract a fixed offset from the address. Check MMU for phy_offset.
How to test?
void* addr1 = phys_to_virt(MEMORY_ADDR);
void* addr2 = ioremap_nocache(MEMORY_ADDR, BUF_SIZE*ELEM_SIZE);
printk(KERN_INFO "virt_addr1: %x\n", (unsigned int volatile *) addr1);
printk(KERN_INFO "virt_addr2: %x\n", (unsigned int volatile *) addr2);
You will see addr1 and addr2 are different. I think you dont need to use phys_to_virt.
Simply use:
void* virt_addr = ioremap_nocache(MEMORY_ADDR, BUF_SIZE*ELEM_SIZE);

Related

Xcode not opening and question mark on ios simulator

When I am trying to open xcode then it gives me an error
For your kind information I am working on Flutter
Xcode error screenshot:-
enter image description here
Xcode full error:-
Translated Report (Full Report Below)
-------------------------------------
Process: Xcode [987]
Path: /Applications/Xcode.app/Contents/MacOS/Xcode
Identifier: com.apple.dt.Xcode
Version: 13.4.1 (20504)
Build Info: IDEFrameworks-20504000000000000~2 (13F100)
App Item ID: 497799835
App External ID: 849405240
Code Type: ARM-64 (Native)
Parent Process: launchd [1]
User ID: 501
Date/Time: 2022-07-05 20:18:29.6652 +0600
OS Version: macOS 12.4 (21F79)
Report Version: 12
Anonymous UUID: BFC37DE6-5667-DA64-D362-1D0670B53487
Time Awake Since Boot: 420 seconds
System Integrity Protection: enabled
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Application Specific Information:
abort() called
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x1b01c2d98 __pthread_kill + 8
1 libsystem_pthread.dylib 0x1b01f7ee0 pthread_kill + 288
2 libsystem_c.dylib 0x1b0132340 abort + 168
3 Xcode 0x1042ff4c4 main.cold.1 + 40
4 Xcode 0x1042febd0 main + 356
5 dyld 0x1045ed08c start + 520
Thread 0 crashed with ARM Thread State (64-bit):
x0: 0x0000000000000000 x1: 0x0000000000000000 x2: 0x0000000000000000 x3: 0x0000000000000000
x4: 0x000000004b010001 x5: 0x0000000000000001 x6: 0x0000000000000000 x7: 0x0000000000000000
x8: 0x13f54261f51d14cd x9: 0x13f54260f17b114d x10: 0x007ffffffffffff8 x11: 0x00000003f2f7001a
x12: 0x000000000000000a x13: 0x0000000000000000 x14: 0x00000001afecc000 x15: 0x000000026ad98000
x16: 0x0000000000000148 x17: 0x000000020a283680 x18: 0x0000000000000000 x19: 0x0000000000000006
x20: 0x0000000104660580 x21: 0x0000000000000103 x22: 0x0000000104660660 x23: 0x0000000144806260
x24: 0x0000000000000000 x25: 0x0000000000000000 x26: 0x0000000000000000 x27: 0x0000000000000000
x28: 0x0000000000000000 fp: 0x000000016bb03940 lr: 0x00000001b01f7ee0
sp: 0x000000016bb03920 pc: 0x00000001b01c2d98 cpsr: 0x40001000
far: 0x0000000142f28050 esr: 0x56000080 Address size fault
Binary Images:
0x1b01b9000 - 0x1b01f0fff libsystem_kernel.dylib (*) <03f48dc5-caa7-3678-af61-1a3c7fa8b06e> /usr/lib/system/libsystem_kernel.dylib
0x1b01f1000 - 0x1b01fdfff libsystem_pthread.dylib (*) <42166a2c-89a9-3c38-a215-f028544cea23> /usr/lib/system/libsystem_pthread.dylib
0x1b00b8000 - 0x1b0139fff libsystem_c.dylib (*) <86746b94-88e3-342d-b2b2-54303404e492> /usr/lib/system/libsystem_c.dylib
0x1042fc000 - 0x1042fffff com.apple.dt.Xcode (13.4.1) <209ad0d0-251b-3efc-a3ea-fd175763be79> /Applications/Xcode.app/Contents/MacOS/Xcode
0x1045e8000 - 0x104647fff dyld (*) <d9c2a46e-8dc4-3950-9d6a-f799e8ccb683> /usr/lib/dyld
External Modification Summary:
Calls made by other processes targeting this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by all processes on this machine:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
VM Region Summary:
ReadOnly portion of Libraries: Total=817.4M resident=0K(0%) swapped_out_or_unallocated=817.4M(100%)
Writable regions: Total=163.1M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=163.1M(100%)
VIRTUAL REGION
REGION TYPE SIZE COUNT (non-coalesced)
=========== ======= =======
Kernel Alloc Once 32K 1
MALLOC 35.1M 13
MALLOC guard page 96K 5
MALLOC_MEDIUM (reserved) 120.0M 1 reserved VM address space (unallocated)
STACK GUARD 56.0M 1
Stack 8176K 1
__AUTH 1863K 147
__AUTH_CONST 10.2M 292
__DATA 8604K 279
__DATA_CONST 10.2M 296
__DATA_DIRTY 806K 111
__FONT_DATA 4K 1
__LINKEDIT 577.3M 3
__OBJC_CONST 1357K 114
__OBJC_RO 83.0M 1
__OBJC_RW 3152K 1
__TEXT 240.1M 309
__UNICODE 592K 1
dyld private memory 1024K 1
shared memory 16K 1
=========== ======= =======
TOTAL 1.1G 1579
TOTAL, minus reserved VM space 1.0G 1579
-----------
Full Report
-----------
{"app_name":"Xcode","timestamp":"2022-07-05 20:18:31.00 +0600","app_version":"13.4.1","slice_uuid":"209ad0d0-251b-3efc-a3ea-fd175763be79","adam_id":"497799835","build_version":"20504","platform":1,"bundleID":"com.apple.dt.Xcode","share_with_app_devs":1,"is_first_party":0,"bug_type":"309","os_version":"macOS 12.4 (21F79)","incident_id":"9321D790-BA4A-4748-9B50-681A237C3F19","name":"Xcode"}
{
"uptime" : 420,
"procLaunch" : "2022-07-05 20:18:24.3525 +0600",
"procRole" : "Background",
"version" : 2,
"userID" : 501,
"deployVersion" : 210,
"modelCode" : "MacBookAir10,1",
"procStartAbsTime" : 10082599645,
"coalitionID" : 995,
"osVersion" : {
"train" : "macOS 12.4",
"build" : "21F79",
"releaseType" : "User"
},
"captureTime" : "2022-07-05 20:18:29.6652 +0600",
"incident" : "9321D790-BA4A-4748-9B50-681A237C3F19",
"bug_type" : "309",
"pid" : 987,
"procExitAbsTime" : 10210035128,
"translated" : false,
"cpuType" : "ARM-64",
"procName" : "Xcode",
"procPath" : "\/Applications\/Xcode.app\/Contents\/MacOS\/Xcode",
"bundleInfo" : {"CFBundleShortVersionString":"13.4.1","CFBundleVersion":"20504","CFBundleIdentifier":"com.apple.dt.Xcode"},
"buildInfo" : {"ProjectName":"IDEFrameworks","SourceVersion":"20504000000000000","ProductBuildVersion":"13F100","BuildVersion":"2"},
"storeInfo" : {"storeCohortMetadata":"10|date=1656723600000&sf=143441&pgtp=Software&pgid=497799835&prpg=Search_osx&ctxt=Search&issrch=1&lngid=1","itemID":"497799835","deviceIdentifierForVendor":"6C4FDE9F-1F16-5026-ADB9-A87FF85DC63E","thirdParty":true,"softwareVersionExternalIdentifier":"849405240"},
"parentProc" : "launchd",
"parentPid" : 1,
"coalitionName" : "com.apple.dt.Xcode",
"crashReporterKey" : "BFC37DE6-5667-DA64-D362-1D0670B53487",
"sip" : "enabled",
"isCorpse" : 1,
"exception" : {"codes":"0x0000000000000000, 0x0000000000000000","rawCodes":[0,0],"type":"EXC_CRASH","signal":"SIGABRT"},
"asi" : {"libsystem_c.dylib":["abort() called"]},
"extMods" : {"caller":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"system":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"targeted":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"warnings":0},
"faultingThread" : 0,
"threads" : [{"triggered":true,"id":11247,"threadState":{"x":[{"value":0},{"value":0},{"value":0},{"value":0},{"value":1258356737},{"value":1},{"value":0},{"value":0},{"value":1438128644506326221},{"value":1438128640150409549},{"value":36028797018963960},{"value":16961175578},{"value":10},{"value":0},{"value":7246495744},{"value":10382573568},{"value":328},{"value":8760342144},{"value":0},{"value":6},{"value":4368762240,"symbolLocation":0,"symbol":"_main_thread"},{"value":259},{"value":4368762464,"symbolLocation":224,"symbol":"_main_thread"},{"value":5444231776},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":7249821408},"cpsr":{"value":1073745920},"fp":{"value":6101678400},"sp":{"value":6101678368},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":7249603992,"matchesCrashFrame":1},"far":{"value":5418156112}},"queue":"com.apple.main-thread","frames":[{"imageOffset":40344,"symbol":"__pthread_kill","symbolLocation":8,"imageIndex":0},{"imageOffset":28384,"symbol":"pthread_kill","symbolLocation":288,"imageIndex":1},{"imageOffset":500544,"symbol":"abort","symbolLocation":168,"imageIndex":2},{"imageOffset":13508,"symbol":"main.cold.1","symbolLocation":40,"imageIndex":3},{"imageOffset":11216,"symbol":"main","symbolLocation":356,"imageIndex":3},{"imageOffset":20620,"symbol":"start","symbolLocation":520,"imageIndex":4}]}],
"usedImages" : [
{
"source" : "P",
"arch" : "arm64e",
"base" : 7249563648,
"size" : 229376,
"uuid" : "03f48dc5-caa7-3678-af61-1a3c7fa8b06e",
"path" : "\/usr\/lib\/system\/libsystem_kernel.dylib",
"name" : "libsystem_kernel.dylib"
},
{
"source" : "P",
"arch" : "arm64e",
"base" : 7249793024,
"size" : 53248,
"uuid" : "42166a2c-89a9-3c38-a215-f028544cea23",
"path" : "\/usr\/lib\/system\/libsystem_pthread.dylib",
"name" : "libsystem_pthread.dylib"
},
{
"source" : "P",
"arch" : "arm64e",
"base" : 7248510976,
"size" : 532480,
"uuid" : "86746b94-88e3-342d-b2b2-54303404e492",
"path" : "\/usr\/lib\/system\/libsystem_c.dylib",
"name" : "libsystem_c.dylib"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4365205504,
"CFBundleShortVersionString" : "13.4.1",
"CFBundleIdentifier" : "com.apple.dt.Xcode",
"size" : 16384,
"uuid" : "209ad0d0-251b-3efc-a3ea-fd175763be79",
"path" : "\/Applications\/Xcode.app\/Contents\/MacOS\/Xcode",
"name" : "Xcode",
"CFBundleVersion" : "20504"
},
{
"source" : "P",
"arch" : "arm64e",
"base" : 4368269312,
"size" : 393216,
"uuid" : "d9c2a46e-8dc4-3950-9d6a-f799e8ccb683",
"path" : "\/usr\/lib\/dyld",
"name" : "dyld"
}
],
"sharedCache" : {
"base" : 7246495744,
"size" : 3136077824,
"uuid" : "513553bb-5ca5-3b9e-a613-b0603ffe3038"
},
"vmSummary" : "ReadOnly portion of Libraries: Total=817.4M resident=0K(0%) swapped_out_or_unallocated=817.4M(100%)\nWritable regions: Total=163.1M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=163.1M(100%)\n\n VIRTUAL REGION \nREGION TYPE SIZE COUNT (non-coalesced) \n=========== ======= ======= \nKernel Alloc Once 32K 1 \nMALLOC 35.1M 13 \nMALLOC guard page 96K 5 \nMALLOC_MEDIUM (reserved) 120.0M 1 reserved VM address space (unallocated)\nSTACK GUARD 56.0M 1 \nStack 8176K 1 \n__AUTH 1863K 147 \n__AUTH_CONST 10.2M 292 \n__DATA 8604K 279 \n__DATA_CONST 10.2M 296 \n__DATA_DIRTY 806K 111 \n__FONT_DATA 4K 1 \n__LINKEDIT 577.3M 3 \n__OBJC_CONST 1357K 114 \n__OBJC_RO 83.0M 1 \n__OBJC_RW 3152K 1 \n__TEXT 240.1M 309 \n__UNICODE 592K 1 \ndyld private memory 1024K 1 \nshared memory 16K 1 \n=========== ======= ======= \nTOTAL 1.1G 1579 \nTOTAL, minus reserved VM space 1.0G 1579 \n",
"legacyInfo" : {
"threadTriggered" : {
"queue" : "com.apple.main-thread"
}
},
"trialInfo" : {
"rollouts" : [
{
"rolloutId" : "5ffde50ce2aacd000d47a95f",
"factorPackIds" : {
},
"deploymentId" : 240000167
},
{
"rolloutId" : "61301e3a61217b3110231469",
"factorPackIds" : {
"SIRI_FIND_MY_CONFIGURATION_FILES" : "6216ae152a40e71046e16225"
},
"deploymentId" : 240000016
}
],
"experiments" : [
]
}
}
Model: MacBookAir10,1, BootROM 7459.121.3, proc 8:4:4 processors, 8 GB, SMC
Graphics: Apple M1, Apple M1, Built-In
Display: Color LCD, 2560 x 1600 Retina, Main, MirrorOff, Online
Memory Module: LPDDR4
AirPort: Wi-Fi, wl0: Mar 23 2022 19:57:59 version 18.60.27.0.7.8.129 FWID 01-570be953
Bluetooth: Version (null), 0 services, 0 devices, 0 incoming serial ports
Network Service: Wi-Fi, AirPort, en0
USB Device: USB31Bus
USB Device: USB31Bus
Thunderbolt Bus: MacBook Air, Apple Inc.
Thunderbolt Bus: MacBook Air, Apple Inc.
Question mark and not opening ios simulator screenshot:-
enter image description here
All working perfectly. When I was installed xcode command line tools through system update and then I was installed homebrew and install cocoapods through brew. Then my problem starts.
I am begineer in this field. Thats why please look at it with an apologetic look.
Question mark appears when the app is not found
In your case Question mark is showing on Simulator which means Xcode is unable to fetch your IOS Simulator
Solution: Remove Caches from your Xcode and remove all older created IOS simulator and try creating new one with updated at IOS 15.5

ESP8266-12F WiFi soft AP config.authmode failed

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.

cJSON Memory leak when freeing cJSON object

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.

unhandled level 2 translation fault in h3ulcb running poky 2.1.3 while running cross-compiled cpp binary

yocto build 2.23 was succesfull and booted my renesas h3ulcb , cross-compiled an opencv application (2.4.13.7) using the sdk on the build system and when trying to execute the cross-compiled binary on the renesas the following error occurs.
However there are no errors while cross-compilation and application is running fine on ubuntu 16.04 but the following error occurs in the h3ulcb running poky 2.1.3
root#h3ulcb:/media/2.4.13_algo_target_# ./main_
Error! /media/2.[ 617.588072] main_[3025]: unhandled level 2 translation fault (11) at 0x00000008, esr 0x92000006
4.13_algo_target[ 617.599298] pgd = ffff8006f8d2a000
_/img/%04d.jpg N[ 617.605155] [00000008] *pgd=00000007374cd003ot Found!
[ 617.610668] , *pud=0000000737ad3003
, *pmd=0000000000000000[ 617.618244]
[ 617.620895]
[ 617.623581] CPU: 0 PID: 3025 Comm: main_ Tainted: G O 4.9.0-yocto-standard #1
[ 617.633050] Hardware name: Renesas H3ULCB board based on r8a7795 (DT)
[ 617.640712] task: ffff8006f77f7080 task.stack: ffff8006fab38000
[ 617.647859] PC is at 0xffff9fb846c8
[ 617.652572] LR is at 0x40498c
[ 617.656751] pc : [<0000ffff9fb846c8>] lr : [<000000000040498c>] pstate: 80000000
[ 617.665400] sp : 0000fffff3319350
[ 617.669956] x29: 0000fffff3319360 x28: 0000000000000000
[ 617.676556] x27: 0000000000000000 x26: 0000000000000000
[ 617.683147] x25: 0000000000000000 x24: 0000000000000000
[ 617.689717] x23: 0000000000000000 x22: 0000000000000000
[ 617.696241] x21: 0000000000000000 x20: 0000000000000000
[ 617.702709] x19: 0000fffff3319630 x18: 0000000000000010
[ 617.709151] x17: 000000000041b510 x16: 0000ffff9fb846a8
[ 617.715568] x15: 0000000032e5d35c x14: 0000ffff9fb2bcb4
[ 617.721960] x13: 0000ffffa02f7000 x12: efeeedecebeae9e8
[ 617.728337] x11: 0000000000000008 x10: 0101010101010101
[ 617.734709] x9 : d7d6d5d4d3d2d1d0 x8 : 0000000000000040
[ 617.741077] x7 : c7c6c5c4c3c2c1c0 x6 : 0000ffff9f290681
[ 617.747419] x5 : 0000000000000000 x4 : 0000000000000000
[ 617.753747] x3 : 0000000000000000 x2 : 0000000000000000
[ 617.760057] x1 : 0000fffff3319750 x0 : 0000ffff9fb83df0
[ 617.766367]
[ 617.768849] audit: type=1701 audit(1562349970.364:5): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=3025 comm="main_" exe="/media/2.4.13_algo_tar1
Segmentation fault (core dumped)
main_ is the executable cross-compiled
can anyone help me debug this issue? Thanks, in advance

Stack trace: stack scanning vs call frame vs given as instruction pointer in context

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.

Resources