cuda-gdb with cuda-memcheck error - cuda

I have this cuda code, that when I execute with cuda-memcheck it returns no errors, it exits normally, and the results I get are actually the expected...
At the same time, there is a file "cuda-memcheck-(put various mumbers here).out" created, that is empty.
When I run the same program under cuda-gdb, it also exits normally with no error reports.
But when I do "set cuda memcheck on" (under cuda-gdb) and then run the program, then a file "cuda-memcheck.out" is created that says:
Starting cuda-memcheck...
cuda-memcheck encountered an error (3,2,2)
that happens as soon as I execute 'run' from within cuda-gdb. Then, soon after the execution starts (and actually very close to a CUFFT kernel execution) i get the following:
Program received signal CUDA_EXCEPTION_1, Lane Illegal Address.
[Switching focus to CUDA kernel 81, grid 82, block (0,0,0), thread (1,17,0), device 0, sm 0, warp 2, lane 5]
*** glibc detected *** cuda-gdb: double free or corruption (!prev): 0x000000001070e5d0 ***
======= Backtrace: =========
/lib/libc.so.6(+0x774b6)[0x7f597c4814b6]
/lib/libc.so.6(cfree+0x73)[0x7f597c487c83]
/lib/libc.so.6(obstack_free+0x48)[0x7f597c48b128]
cuda-gdb[0x5c5a25]
cuda-gdb[0x4352d0]
cuda-gdb[0x5649c4]
cuda-gdb[0x5e42d7]
cuda-gdb[0x5e45fd]
cuda-gdb[0x56436c]
cuda-gdb[0x50d772]
cuda-gdb[0x50e3c3]
cuda-gdb[0x51373b]
cuda-gdb[0x50faff]
cuda-gdb[0x510194]
cuda-gdb[0x51373b]
cuda-gdb[0x50eaac]
cuda-gdb[0x504311]
cuda-gdb[0x50a09d]
cuda-gdb[0x4ffc4f]
cuda-gdb[0x410b9d]
cuda-gdb[0x519c48]
cuda-gdb[0x51a82c]
cuda-gdb[0x5f9b57]
cuda-gdb[0x519cb9]
cuda-gdb[0x5186c8]
cuda-gdb[0x51995a]
cuda-gdb[0x51373b]
cuda-gdb[0x4a1a40]
cuda-gdb[0x407529]
cuda-gdb[0x51373b]
cuda-gdb[0x408056]
cuda-gdb[0x51373b]
cuda-gdb[0x407464]
cuda-gdb[0x40742e]
/lib/libc.so.6(__libc_start_main+0xfe)[0x7f597c428d8e]
cuda-gdb[0x407339]
======= Memory map: ========
00400000-008b6000 r-xp 00000000 08:01 190634 /usr/local/cuda/bin/cuda-gdb
00ab5000-00ab6000 r--p 004b5000 08:01 190634 /usr/local/cuda/bin/cuda-gdb
00ab6000-00ac9000 rw-p 004b6000 08:01 190634 /usr/local/cuda/bin/cuda-gdb
00ac9000-0f0f8000 rw-p 00000000 00:00 0
0fef3000-11b2c000 rw-p 00000000 00:00 0 [heap]
7f5974000000-7f5974021000 rw-p 00000000 00:00 0
7f5974021000-7f5978000000 ---p 00000000 00:00 0
7f597a4df000-7f597aacc000 rw-p 00000000 00:00 0
7f597aacc000-7f597aacd000 rw-p 00000000 00:00 0
7f597b538000-7f597b54d000 r-xp 00000000 08:01 954799 /lib/libgcc_s.so.1
7f597b54d000-7f597b74c000 ---p 00015000 08:01 954799 /lib/libgcc_s.so.1
7f597b74c000-7f597b74d000 r--p 00014000 08:01 954799 /lib/libgcc_s.so.1
7f597b74d000-7f597b74e000 rw-p 00015000 08:01 954799 /lib/libgcc_s.so.1
7f597b75d000-7f597b764000 r-xp 00000000 08:01 954961 /lib/libthread_db-1.0.so
7f597b764000-7f597b963000 ---p 00007000 08:01 954961 /lib/libthread_db-1.0.so
7f597b963000-7f597b964000 r--p 00006000 08:01 954961 /lib/libthread_db-1.0.so
7f597b964000-7f597b965000 rw-p 00007000 08:01 954961 /lib/libthread_db-1.0.so
7f597b965000-7f597b966000 ---p 00000000 00:00 0
7f597b966000-7f597c166000 rw-p 00000000 00:00 0
7f597c166000-7f597c40a000 r--p 00000000 08:01 49399 /usr/lib/locale/locale-archive
7f597c40a000-7f597c584000 r-xp 00000000 08:01 954957 /lib/libc-2.12.1.so
7f597c584000-7f597c783000 ---p 0017a000 08:01 954957 /lib/libc-2.12.1.so
7f597c783000-7f597c787000 r--p 00179000 08:01 954957 /lib/libc-2.12.1.so
7f597c787000-7f597c788000 rw-p 0017d000 08:01 954957 /lib/libc-2.12.1.so
7f597c788000-7f597c78d000 rw-p 00000000 00:00 0
7f597c78d000-7f597c78f000 r-xp 00000000 08:01 954973 /lib/libdl-2.12.1.so
7f597c78f000-7f597c98f000 ---p 00002000 08:01 954973 /lib/libdl-2.12.1.so
7f597c98f000-7f597c990000 r--p 00002000 08:01 954973 /lib/libdl-2.12.1.so
7f597c990000-7f597c991000 rw-p 00003000 08:01 954973 /lib/libdl-2.12.1.so
7f597c991000-7f597c9b7000 r-xp 00000000 08:01 954792 /lib/libexpat.so.1.5.2
7f597c9b7000-7f597cbb7000 ---p 00026000 08:01 954792 /lib/libexpat.so.1.5.2
7f597cbb7000-7f597cbb9000 r--p 00026000 08:01 954792 /lib/libexpat.so.1.5.2
7f597cbb9000-7f597cbba000 rw-p 00028000 08:01 954792 /lib/libexpat.so.1.5.2
7f597cbba000-7f597cc3c000 r-xp 00000000 08:01 954964 /lib/libm-2.12.1.so
7f597cc3c000-7f597ce3b000 ---p 00082000 08:01 954964 /lib/libm-2.12.1.so
7f597ce3b000-7f597ce3c000 r--p 00081000 08:01 954964 /lib/libm-2.12.1.so
7f597ce3c000-7f597ce3d000 rw-p 00082000 08:01 954964 /lib/libm-2.12.1.so
7f597ce3d000-7f597ce53000 r-xp 00000000 08:01 954914 /lib/libz.so.1.2.3.4
7f597ce53000-7f597d053000 ---p 00016000 08:01 954914 /lib/libz.so.1.2.3.4
7f597d053000-7f597d054000 r--p 00016000 08:01 954914 /lib/libz.so.1.2.3.4
7f597d054000-7f597d055000 rw-p 00017000 08:01 954914 /lib/libz.so.1.2.3.4
7f597d055000-7f597d095000 r-xp 00000000 08:01 954818 /lib/libncurses.so.5.7
7f597d095000-7f597d294000 ---p 00040000 08:01 954818 /lib/libncurses.so.5.7
7f597d294000-7f597d298000 r--p 0003f000 08:01 954818 /lib/libncurses.so.5.7
7f597d298000-7f597d299000 rw-p 00043000 08:01 954818 /lib/libncurses.so.5.7
7f597d299000-7f597d2b1000 r-xp 00000000 08:01 954959 /lib/libpthread-2.12.1.so
7f597d2b1000-7f597d4b0000 ---p 00018000 08:01 954959 /lib/libpthread-2.12.1.so
7f597d4b0000-7f597d4b1000 r--p 00017000 08:01 954959 /lib/libpthread-2.12.1.so
7f597d4b1000-7f597d4b2000 rw-p 00018000 08:01 954959 /lib/libpthread-2.12.1.so
7f597d4b2000-7f597d4b6000 rw-p 00000000 00:00 0
7f597d4b6000-7f597d4d6000 r-xp 00000000 08:01 954965 /lib/ld-2.12.1.so
7f597d4df000-7f597d672000 rw-p 00000000 00:00 0
7f597d672000-7f597d678000 r--p 00a01000 08:06 26722558 /home/user/workspace/cuda/fullcu/current_debug/Default/shl_3D_cu
7f597d678000-7f597d67e000 r--p 00a15000 08:06 26722558 /home/user/workspace/cuda/fullcu/current_debug/Default/shl_3D_cu
7f597d67e000-7f597d687000 r--p 00a06000 08:06 26722558 /home/user/workspace/cuda/fullcu/current_debug/Default/shl_3D_cu
7f597d687000-7f597d6c0000 r--p 009c5000 08:06 26722558 /home/user/workspace/cuda/fullcu/current_debug/Default/shl_3D_cu
7f597d6c0000-7f597d6c5000 rw-p 00000000 00:00 0
7f597d6c5000-7f597d6ca000 r--p 009fd000 08:06 26722558 /home/user/workspace/cuda/fullcu/current_debug/Default/shl_3D_cu
7f597d6cb000-7f597d6cd000 rw-p 00000000 00:00 0
7f597d6cd000-7f597d6d4000 r--s 00000000 08:01 49265 /usr/lib/gconv/gconv-modules.cache0x000000000366a8d0 in fdividef<<<(16,1,1),(4,64,1)>>> (Aborted
and cuda-gdb crashes.
Should I take it that there is actually a faulty mem access in my code? or is it the error that hits upon the initialization of cuda-memcheck???
anyone seen that behaviour before??
Thank you for any ideas.

It looks like you have a memcheck-detectable error in your application. For some reason, cuda-gdb crashes when your application is suspended on the breakpoint.
Does your cuda-gdb crash when you stop on regular breakpoints in the device code?
What CUDA Toolkit and NVIDIA display driver versions are you using? We recommend you trying the latest CUDA Toolkit 5.0RC build as it has numerous stability and functionality improvements.
It would be invaluable if you could contact out team directly at cudatools#nvidia.com to provide more information (this way we may be able to fix the problem in the next CUDA Toolkit version). Can you also provide the application that triggers the crash?
Thank you in advance.

Based on Eugene's question on what happens on regular breakpoints, I added some in key points in the code ('key' with respect to the debugging output I have gotten until now) and I have the following 'odd' gdb output to report:
The following is from a CUFFT kernel call:
[Launch of CUDA Kernel 41 (spVector0016B_kernelTex<(fftDirection_t)-1><<<(16,1,1),(4,64,1)>>>) on Device 0]
0x00007ffff569c8b3 in select () from /lib/libc.so.6
(cuda-gdb) n
Single stepping until exit from function select, which has no line number information.
0x00007ffff3fe8de7 in ?? () from /usr/lib/libcuda.so
Is '??' normal output in that case because it's a CUFFT kernel?
The following is from another kernel launch, mine this time and I don't understand why it says 'no such file':
Breakpoint 5, BCSG<<<(1,1,1),(512,1,1)>>> (glerror=0x200620df8,
sL=0x2009ffff8, ijL=0x200aa7ffc, X=0x2006035f8, D=0x2006075f8,
Pre=0x200941ff8,
error=1.00000001e-10, L=700, N=1024, flag=0x200c00000, r=0x2006095f8, r0=0x20060b5f8, p1=0x20060d5f8, p2=0x20060f5f8,
vv=0x2006115f8, s1=0x2006135f8,
s2=0x2006155f8, t=0x2006175f8, T=0x2006195f8, r1=0x20061b600, a=0x20061cbf8, w=0x20061e1f8, beta=0x20061f7f8, ns1=0x200affffc) at
BCGC_solver.cu:96
96 BCGC_solver.cu: No such file or directory.
in BCGC_solver.cu
Also i would like to ask if this:
warning: Warp(s) other than the current warp had to be single-stepped.
...happens because of the execution within cuda-gdb, or if it is something that would happen in normal program execution as well. I do have the program hanging at parts of the code, soon after it freezes for good. But I think that if it was only a matter of serial execution, it would continue soon after, as it does in conventional code.

To well trace this issue, it is better to file a bug to Nvidia. The steps of filing a bug is listed as below:
1. Open page http://developer.nvidia.com/cuda/join-cuda-registered-developer-program;
2. If not registered, please click "Join Now", otherwise click "Login Now";
3. Input e-mail and password to login;
4. On the left panel, there is a "Bug Report" item in Home section, click it to file a bug;
5. Fill the required itmes, other items are optional, but detailed information will help us to target and fix the issue a lot;
6. If necessary, an attachment should be uploaded;
7. For Linux system, it is better to attach an nvidia-bug-report;
8. If an issue is related to specific code pattern, a sample code and instructions to compile it are desired for reproduction.

Related

ESP8266 repeatedly throws Exception(0)

I am making an IoT weighing scale with a load cell connected to an Arduino. The Arduino then sends data to an ESP8266 connected by serial which would subsequently update my database on Google's Firebase. However, my ESP8266 throws an exception when it starts. Half of the time it works perfectly fine. The other half throws the following error when I connect my serial cable. This error runs repeatedly so I think it might be an error inside void loop() but I can't seem to figure out what exactly is the problem. Also, my cables are not the best quality but I am not sure if that affects anything
Exception (0):
epc1=0x4025803e epc2=0x00000000 epc3=0x00000000 excvaddr=0x0000000a depc=0x00000000
>>>stack>>>
ctx: sys
sp: 3fffe0c0 end: 3fffffb0 offset: 01a0
3fffe260: 00000000 00000000 00000000 00000000
3fffe270: 00000000 00000000 00000000 40104b72
3fffe280: 40104b54 3fffc100 0000001a 00000000
3fffe290: 00000000 4025803e 00000000 00000000
3fffe2a0: 400005e1 00000000 00000000 00000000
3fffe2b0: 4025803e 00000033 00000010 00000000
3fffe2c0: 4025803e 40266fd0 00000000 00000001
3fffe2d0: fbf8ffff 04000002 3feffe00 00000100
3fffe2e0: 0000001a 00000018 04000102 40104b54
3fffe2f0: 3fffc100 0000001a 00000000 00000000
3fffe300: 00000000 00000000 00000000 00000000
3fffe310: 00000000 00000000 00000000 00000000
3fffe320: 00000000 00000000 00000000 00000000
3fffe330: 00000000 00000000 00000000 00000000
3fffe340: 00000000 00000000 00000000 00000000
3fffe350: 00000000 00000000 00000000 00000000
3fffe360: 00000000 00000000 00000000 00000000
3fffe370: 00000000 00000000 00000000 00000000
3fffe380: 00000000 00000000 00000000 00000000
3fffe390: 00000000 00000000 00000000 00000000
3fffe3a0: 00000000 00000000 00000000 00000000
3fffe3b0: 00000000 00000000 00000000 00000000
3fffe3c0: 00000000 00000000 00000000 40104b72
3fffe3d0: 40104b54 3fffc100 0000001a 00000000
3fffe3e0: 00000000 4025803e 00000000 00000000
3fffe3f0: 400005e1 00000000 00000000 00000000
3fffe400: 4025803e 00000033 00000010 00000000
3fffe410: 4025803e 40266fd0 00000000 00000001
3fffe420: fbf8ffff 04000002 3feffe00 00000100
3fffe430: 0000001a 00000018 04000102 40104b54
3fffe440: 3fffc100 0000001a 00000000 00000000
3fffe450: 00000000 00000000 00000000 00000000
3fffe460: 00000000 00000000 00000000 00000000
3fffe470: 00000000 00000000 00000000 00000000
3fffe480: 00000000 00000000 00000000 00000000
3fffe490: 00000000 00000000 00000000 00000000
3fffe4a0: 00000000 00000000 00000000 00000000
3fffe4b0: 00000000 00000000 00000000 00000000
3fffe4c0: 00000000 00000000 00000000 00000000
3fffe4d0: 00000000 00000000 00000000 00000000
3fffe4e0: 00000000 00000000 00000000 00000000
3fffe4f0: 00000000 00000000 00000000 00000000
3fffe500: 00000000 00000000 00000000 00000000
3fffe510: 00000000 00000000 00000000 40104b72
3fffe520: 40104b54 3fffc100 0000001a 00000000
3fffe530: 00000000 4025803e 00000000 00000000
3fffe540: 400005e1 00000000 00000000 00000000
3fffe550: 4025803e 00000033 00000010 00000000
3fffe560: 4025803e 40266fd0 00000000 00000001
3fffe570: fbf8ffff 04000002 3feffe00 00000100
3fffe580: 0000001a 00000018 04000102 40104b54
3fffe590: 3fffc100 0000001a 00000000 00000000
3fffe5a0: 00000000 00000000 00000000 00000000
3fffe5b0: 00000000 00000000 00000000 00000000
3fffe5c0: 00000000 00000000 00000000 00000000
3fffe5d0: 00000000 00000000 00000000 00000000
3fffe5e0: 00000000 00000000 00000000 00000000
3fffe5f0: 00000000 00000000 00000000 00000000
3fffe600: 00000000 00000000 00000000 00000000
3fffe610: 00000000 00000000 00000000 00000000
3fffe620: 00000000 00000000 00000000 00000000
3fffe630: 00000000 00000000 00000000 00000000
3fffe640: 00000000 00000000 00000000 00000000
3fffe650: 00000000 00000000 00000000 00000000
3fffe660: 00000000 00000000 00000000 40104b72
3fffe670: 40104b54 3fffc100 0000001a 00000000
3fffe680: 00000000 4025803e 00000000 00000000
3fffe690: 400005e1 00000000 00000000 00000000
3fffe6a0: 4025803e 00000033 00000010 00000000
3fffe6b0: 4025803e 40266fd0 00000000 00000001
3fffe6c0: fbf8ffff 04000002 3feffe00 00000100
3fffe6d0: 0000001a 00000018 04000102 40104b54
3fffe6e0: 3fffc100 0000001a 00000000 00000000
3fffe6f0: 00000000 00000000 00000000 00000000
3fffe700: 00000000 00000000 00000000 00000000
3fffe710: 00000000 00000000 00000000 00000000
3fffe720: 0af8a400 00000001 647a4f3a 00000000
3fffe730: 0af8a400 00000001 647a4f3a 00000000
3fffe740: 00000000 00000000 00000000 00000000
3fffe750: 00000000 00000000 00000000 00000000
3fffe760: 00000000 00000000 00000000 00000000
3fffe770: 00000000 15f14800 000015f1 00004800
3fffe780: 0000c8f4 000215f1 00000000 00000000
3fffe790: c8f49e74 00009e74 00000000 00000000
3fffe7a0: 00000000 00000000 00000000 00000000
3fffe7b0: 00000000 00000000 00000000 40104b72
3fffe7c0: 40104b54 3fffc100 0000001a 00000000
3fffe7d0: 00000000 4025803e 647a4f3a 00000000
3fffe7e0: 400005e1 00000002 000000ad 00000000
3fffe7f0: 4025803e 00000033 00000010 004e11a5
3fffe800: 4025803e 40266fd0 00000000 00000001
3fffe810: fbf8ffff 04000002 3feffe00 00000100
3fffe820: 0000001a 00000018 04000102 40104b54
3fffe830: 3fffc100 0000001a 00000000 00000000
3fffe840: ffffffff 00000000 00000001 00000000
3fffe850: 00005201 00000000 4026492a ffffffff
3fffe860: 00000000 fffffffd 00000000 00000000
3fffe870: 00000000 00000000 00000001 40006545
3fffe880: 00000000 00000000 00000000 40006545
3fffe890: 00000001 00000001 00000000 40006589
3fffe8a0: 00000000 3fffe922 00000000 40264b1e
3fffe8b0: 40264b32 00000001 00000000 00000000
3fffe8c0: 3fffe8d3 00000000 00000000 40006545
3fffe8d0: 000005e0 3fffe918 3ffef288 40226a30
3fffe8e0: 00000608 00000000 00000000 00000000
3fffe8f0: 00000000 00000020 402532c3 00000001
3fffe900: ffffffff 00000000 3ffe8e91 40104b72
3fffe910: 40104b54 3fffc100 0000001a 00000000
3fffe920: 00000000 4025803e 00000020 401001a4
3fffe930: 400005e1 00000000 00000000 401015bc
3fffe940: 4025803e 00000033 00000010 3ffed11c
3fffe950: 4025803e 40266fd0 00000000 00000001
3fffe960: fbf8ffff 04000002 3feffe00 00000100
3fffe970: 0000001a 00000018 04000102 40104b54
3fffe980: 3fffc100 0000001a 00000000 00000000
3fffe990: 00000000 00000002 3ffee8a0 402660a3
3fffe9a0: c0266089 7fffffff 00000002 40211114
3fffe9b0: 3ffe8765 00000002 3ffee898 4026608a
3fffe9c0: 00000000 7fffffff 3fff17ec 3ffed29c
3fffe9d0: 00000000 3ffeea48 3ffe8765 40222cde
3fffe9e0: 3fffea00 3ffeea1c 3ffe8765 3ffeea78
3fffe9f0: 3ffe8765 3ffeea9c 3ffe8765 40222cde
3fffea00: 3fffea20 3ffeebb4 3ffeeb24 3ffed29c
3fffea10: 3ffe8765 00000000 3ffee678 402063e8
3fffea20: 40247cf1 00000000 3ffeeaa8 402037d8
3fffea30: ffffffff 00000000 3ffeeaa8 402109af
3fffea40: 00000000 00000000 00000001 401001a4
3fffea50: 3ffedffc 3ffee028 3ffe8abc 40104b72
3fffea60: 40104b54 3fffc100 0000001a 00000000
3fffea70: 00000000 4025803e 00000001 402587be
3fffea80: 400005e1 00001000 40104e0d 000003fd
3fffea90: 4025803e 00000033 00000010 00000000
3fffeaa0: 4025803e 40266fd0 00000000 00000001
3fffeab0: fbf8ffff 04000002 3feffe00 00000100
3fffeac0: c_⸮⸮rS⸮
This is my code on the ESP8266. I apologize for any bad programming habits.
#include <ESP8266WiFi.h>
#include <FirebaseESP8266.h>
//Hidden for security
#define WIFINAME
#define WIFIPASSWORD
#define BAUTRATE 9600
#define FIREBASE_HOST
#define FIREBASE_COMMAND_ADDRESS
#define FIREBASE_AUTH
WiFiClientSecure client;
FirebaseData firebaseData;
unsigned long previousTime;
String firebaseWriteAddress;
String firebaseReadAddress;
String weight; // Stored in a string to accomodate the "loading" text
bool maxWRead;
bool minWRead;
bool displayPrefRead;
bool instructedToConnectWifi;
void readWeights(){
// function to read the min and max weights, then send to Arduino
if (!maxWRead){
String maxWAddress = firebaseReadAddress + "/Product/MaxW";
if (Firebase.get(firebaseData,maxWAddress)){
if (firebaseData.dataType() == "string"){
String maxWMessage = "max:"+ firebaseData.stringData();
Serial.println(maxWMessage);
maxWRead = true;
}
}
}
if (!minWRead){
String minWAddress = firebaseReadAddress + "/Product/MinW";
if (Firebase.get(firebaseData,minWAddress)){
if (firebaseData.dataType() == "string"){
String minWMessage = "min:"+ firebaseData.stringData();
Serial.println(minWMessage);
minWRead = true;
}
}
}
}
void readDisplayPref(){
String displayAddress = firebaseReadAddress + "/Display";
if (Firebase.get(firebaseData,displayAddress)){
if (firebaseData.dataType() == "string"){
String displayMessage = "dsp:"+ firebaseData.stringData();
Serial.println(displayMessage);
displayPrefRead = true;
}
}
}
void sendFireBase(){
// function to send data to Firebase Real-time Database
Firebase.setString(firebaseData, firebaseWriteAddress,weight);
}
void readFireBase(){
Firebase.begin(FIREBASE_HOST,FIREBASE_AUTH);
if(Firebase.get(firebaseData, FIREBASE_COMMAND_ADDRESS)){
if (firebaseData.dataType() == "string"){
String data = firebaseData.stringData();
String command = data.substring(0,4);
if (command == "read"){
firebaseReadAddress = "/UserData/" + data.substring(4);
readWeights();
firebaseWriteAddress = "/UserData/" + data.substring(4)
+ "/Weight";
}
}
}
}
void connectWifi(){
WiFi.begin(WIFINAME, WIFIPASSWORD);
byte wifiCounter = 0;
// Allow some buffer time to connect to WiFi
while (WiFi.status() != WL_CONNECTED) {
delay(100);
wifiCounter ++;
if (wifiCounter > 50){
// tries for 5 sec.
break;
}
}
if (WiFi.status() == WL_CONNECTED){
Serial.print("WiFi Connected!\n");
instructedToConnectWifi = true;
}
else {
Serial.print("Can't Connect. Trying Again\n");
connectWifi();
}
}
void readArd(){
// function to read Serial inputs from arduino
String message = Serial.readStringUntil('\n');
if (message == "ConnectWifi"){
connectWifi();
}
else{
weight = message;
// stores weight without the percentage sign. Only stores if its within 0-100
sendFireBase();
}
}
void setup() {
Serial.begin(BAUTRATE);
previousTime = millis();
maxWRead = false;
minWRead = false;
displayPrefRead = false;
instructedToConnectWifi = false;
}
void loop() {
if (Serial.available()){
readArd();
}
if (instructedToConnectWifi){
// if wifi disconnects halfway, auto connect back
if (WiFi.status() != WL_CONNECTED){
connectWifi();
}
}
unsigned long currentTime = millis();
if (currentTime - previousTime >2000){
// cycles every 2 sec to prevent spam
// TODO: fix overflow problem (49 days) if it becomes product
if (instructedToConnectWifi){
if (!minWRead || !maxWRead){
// stop once max and min has been read
readFireBase();
previousTime = currentTime;
}
else {
readDisplayPref();
previousTime = currentTime;
}
}
}
}
These exeption analysed gives me the following result:
Exception 0: Illegal instruction
looking deeper into the error reveals:
std::basic_string , std::allocator >::basic_string(char const*, std::allocator const&)
This error pattern is typical for the String class.
Replace all Strings with fixed char arrays (not dynamicly created ones(!))
Reason: the String class tends to fracture the heap which causes the ESPs to crash (8266 as well ESP32). Why those? Because we use them (opposite to "normal" Arduinos to 99% in WiFi scenarios (IoT). So there is a lot happening in memory.What to do? Get rid of String class (and delay() if used)
String firebaseWriteAddress;
String firebaseReadAddress;
String weight; // Stored in a string to accomodate the "loading" text
These above in combination with functions like (dynamicly defined String vars)
String data = firebaseData.stringData();
String command = data.substring(0,4);
if (command == "read"){
firebaseReadAddress = "/UserData/" + data.substring(4);
readWeights();
firebaseWriteAddress = "/UserData/" + data.substring(4)
+ "/Weight";
will ensure that the ESP crashes very quickly. Since there is no garbagge collection (and would have not enough memory anyway) you write at some point into occupied memory - see first line of my error analysis - crash.Why work fixed chars? - they are compiled into flash and you operate most of the time with pointers. So all "fixed" text messages go into flash (example)
char firebaseReadAddress[64] = {'\0'}; //Takes 63 chars
used like
strcpy(firebaseReadAddress, "/UserData/");
strcat(firebaseReadAddress, dataContent);
to check wether a char array starts with "read" you use this method:
if (strncmp( command, "read", 4) == 0) { /** Compare the first 4 characters - returns 0 if they are equal */
The handling is as easy as String class, but it lets your app run forever (at least as long there is a power source)Check also used libraries for heavy String use (especially if they are not dedicated for ESPs). If they do - ditch them or rewrite them ;-) The firebase lib is a positive example no use of dynamic Strings and heavy use of char arrays. Sorry for the bad newsRewrite your program if you ever want a stable app, I can assist you if there are special questions - just leave a comment here.

OS dev and where the boot sector is in qemu

I found this article about writing a simple OS:
https://www.cs.bham.ac.uk/~exr/lectures/opsys/10_11/lectures/os-dev.pdf
In chapter 3 part 4 there it says that an "X" will be written to the boot sector at: 0x7c00 but, in qemu if you dump the memory you can see its not written to 0x7c00, its written to, 0x7fc8.
Why is this?
What bytes does qemu use for the boot sector?
https://gyazo.com/6dcfaeffea19dfbc6edffa22a1bf0c83
This is the code in the os-dev pdf:
mov ah , 0 x0e
mov bx , the_secret
add bx , 0 x7c00
mov al , [bx]
int 0 x10`
jmp $ ; Jump forever.
the_secret :
db "X "
; Padding and magic BIOS number.
times 510 -( $ - $$ ) db 0
dw 0 xaa55

Decompiling 8051 binary, read from EEPROM

I'm trying to decompile the firmware of a Logitech Freedom 2.4 Cordless Joystick. I've managed to get something of the EEPROM. (here)
The EEPROM that is used is the Microchip 25AA320, which is a 32Kbit SPI-EEPROM. The MCU is a nRF24E1G , that contains a 8051 MCU.
The ROM should be 4096 bytes, so I think that my reading program looped over it self 4 times.
I managed to extract a 4kB ROM (here), but the start of the file doesn't look clean.
I loaded both files into IDA Pro and Ghidra and selected the 8051 processor. They don't generate anything useful.
Could anyone help me decompiling this ROM?
I used this Arduino Sketch to dump the rom.
Together with this python script
## Author: Arpan Das
## Date: Fri Jan 11 12:16:59 2019 +0530
## URL: https://github.com/Cyberster/SPI-Based-EEPROM-Reader-Writer
## It listens to serial port and writes contents into a file
## requires pySerial to be installed
import sys
import serial
import time
start = time.time()
MEMORY_SIZE = 4096 # In bytes
serial_port = 'COM5'
baud_rate = 115200 # In arduino, Serial.begin(baud_rate)
write_to_file_path = "dump.rom"
output_file = open(write_to_file_path, "wb")
ser = serial.Serial(serial_port, baud_rate)
print("Press d for dump ROM else CTRL+C to exit.")
ch = sys.stdin.read(1)
if ch == 'd':
ser.write('d')
for i in range(MEMORY_SIZE/32): # i.e. MEMORY_SIZE / 32
# wait until arduino response with 'W' i.e. 1 byte of data write request
while (ser.read() != 'W'): continue
ser.write('G') # sends back write request granted signal
for j in range(32):
byte = ser.read(1);
output_file.write(byte);
print(str(MEMORY_SIZE - (i * 32)) + " bytes remaining.")
print '\nIt took', time.time()-start, ' seconds.'
This is what I did, the next part left is for you. My machine is a Win10 notebook, however I used unix tools because they are so capable.
First of all, I divided the 16KB dump into four 4KB parts. The first one was different from the other three. And the provided 4KB dump is different to all of these parts. I did not investigate this further, and simply took one of the other three parts that are all equal.
$ split -b 4K LogitechFreedom2.4CordlessJoystick.rom part
$ cmp partaa partab
partaa partab differ: byte 1, line 1
$ cmp partab partac
$ cmp partac partad
$ cmp dump.rom partaa
dump.rom partaa differ: byte 9, line 1
$ cmp dump.rom partab
dump.rom partab differ: byte 1, line 1
From the microcontroller's data sheet I learned that the EEPROM contents has a header of at least 3 bytes (chapter 10.2 at page 61).
These bytes are:
0b Version = 00, Reserved = 00, SPEED = 0.5MHz, XO_FREQ = 16MHz
03 Offset to start of user program = 3
0f Number of 256 bytes block = 15
The last entry seems to be off by one, because there seems to be code in the 16th block, too.
Anyway, these bytes look decent, so I cut the first 3 bytes.
$ dd if=partad of=rom.bin bs=1 skip=3
4093+0 records in
4093+0 records out
4093 bytes (4,1 kB, 4,0 KiB) copied, 0,0270132 s, 152 kB/s
$ dd if=partad of=head.bin bs=1 count=3
3+0 records in
3+0 records out
3 bytes copied, 0,0043809 s, 0,7 kB/s
$ od -Ax -t x1 rom.bin > rom.hex
$ od -Ax -t x1 head.bin > head.hex
The hex files are nice for loading them into an editor and look around.
I loaded the remaining 4093 bytes into a disassembler I once wrote and peeked around a bit. It looks promising, so I think you can go on without me now:
C0000: ljmp C0F54
C0003: setb 021H.2
reti
C000B: xch a,r5
inc r6
xrl a,r6
mov a,#0B2H
movc a,#a+pc
movx #r1,a
mov r7,a
setb 021H.2
reti
C0F54: mov psw,#000H
mov sp,#07BH
mov r0,#0FFH
mov #r0,#000H
djnz r0,C0F5C
ljmp C0C09

In MIPS, how exactly are command line arguments stored in $a1?

Consider the following code, which reads the first command line argument and then prints it:
lw $a0, 0($a1)
li $v0, 4
syscall
This makes sense, because arguments are always stored in word-aligned offsets from $a1. However, supposes the first program argument is 'jklfjdsaklfjdsklfjsdklfjsklfjsklfjsdaklfjlsdkjfjfksalfjsadlkf'. There's no way this gigantic string fits into the four bytes between 0($a1) and 4($a1). Yet the code still runs and prints the string. Why?
Also how does the entire string get put into $a0? Because again it shouldn't really fit.
char fun0 ( char *x )
{
return(x[11]);
}
char fun1 ( char **x )
{
return(x[1][1]);
}
mips
00000000 <fun0>:
0: 8082000b lb $2,11($4)
4: 03e00008 jr $31
8: 00000000 nop
0000000c <fun1>:
c: 8c820004 lw $2,4($4)
10: 00000000 nop
14: 80420001 lb $2,1($2)
18: 03e00008 jr $31
1c: 00000000 nop
arm
00000000 <fun0>:
0: e5d0000b ldrb r0, [r0, #11]
4: e12fff1e bx lr
00000008 <fun1>:
8: e5903004 ldr r3, [r0, #4]
c: e5d30001 ldrb r0, [r3, #1]
10: e12fff1e bx lr
x86
0000000000000000 <fun0>:
0: 0f b6 47 0b movzbl 0xb(%rdi),%eax
4: c3 retq
5: 90 nop
6: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
d: 00 00 00
0000000000000010 <fun1>:
10: 48 8b 47 08 mov 0x8(%rdi),%rax
14: 0f b6 40 01 movzbl 0x1(%rax),%eax
18: c3 retq
so when you have int main ( int argc, char *argv[]) argv is an address and the compiler passes that address. If you are working at a different level, then the operating system/environment defines that the command line string is passed that way and that would cover the "why" question. You didnt provide enough information to answer the question.
And it basically has nothing to do with mips, it has to do with an implementation of some system that is targeted to mips. The same types of implementations can be used on non-mips targets as well.

Troubleshooting Sony Spresense Hard Fault

I have been working with the Sony Spresense board for a couple of days now but I am continuously getting a "hard fault". I have created multiple versions of the same code, but all get the same error. I am trying to copy the characters from a file on an SD card, inserted in the built-in SD Module and process them.
I have no idea what to do, the error just pops up at random points in the code, even if the board does not work with the SD Module at that point. If I comment out some lines of code before the point where the error message is sent, the error message is sent later on in the code.
The error message just gets printed to the serial monitor suddenly, the error seems to be present with all of my recent sketches. It looks like this.
up_hardfault: PANIC!!! Hard fault: 40000000
up_assert: Assertion failed at file:armv7-m/up_hardfault.c line: 171 task: init
up_dumpstate: sp: 0d0262d4
up_dumpstate: IRQ stack:
up_dumpstate: base: 0d026300
up_dumpstate: size: 00000800
up_dumpstate: used: 00000128
up_stackdump: 0d0262c0: 0d0262d8 0d01dc11 00000000 0d0262d8 0d00de13 00000003 00000000 0d00de1b
up_stackdump: 0d0262e0: 0d00ddf9 0d00dded 000000e0 0d02e804 00000047 0d02e8ec 0d024594 0d00d5f5
up_dumpstate: sp: 0d02e8d8
up_dumpstate: User stack:
up_dumpstate: base: 0d02ee18
up_dumpstate: size: 00001fec
up_dumpstate: used: 00000860
up_stackdump: 0d02e8c0: 00000000 00000000 00000000 00000000 00000000 0d000963 0d024c28 00000047
up_stackdump: 0d02e8e0: 0d02e934 0d0015c9 198b37d8 00000047 00007fff 0d0003e9 0d0351e0 0000000b
up_stackdump: 0d02e900: 0000000b 0d020e78 00000000 000003e8 deadbeef 0d035700 0d02cbb4 000000cc
up_stackdump: 0d02e920: 00000000 00000000 0d034e20 00000000 00000000 0d034e30 00000000 00000000
up_stackdump: 0d02e940: 0d034e40 00000000 00000000 deadbeef deadbeef deadbeef deadbeef deadbeef
up_stackdump: 0d02e960: deadbeef 0d034e50 00000000 00000000 0d034e60 00000000 00000000 0d034e70
up_stackdump: 0d02e980: 00000000 00000000 deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
up_stackdump: 0d02e9a0: 0d034e80 00000000 00000000 0d034e90 00000000 00000000 0d034ea0 00000000
up_stackdump: 0d02e9c0: 00000000 deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef 0d034eb0
up_stackdump: 0d02e9e0: 00000000 00000000 0d034ec0 00000000 00000000 0d034ed0 00000000 00000000
up_stackdump: 0d02ea00: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef 0d034ee0 00000000
up_stackdump: 0d02ea20: 00000000 0d034ef0 00000000 00000000 0d034f00 00000000 00000000 deadbeef
up_stackdump: 0d02ea40: deadbeef deadbeef deadbeef deadbeef deadbeef 0d034f10 00000000 00000000
up_stackdump: 0d02ea60: 0d034f20 00000000 00000000 0d034f30 00000000 00000000 deadbeef deadbeef
up_stackdump: 0d02ea80: deadbeef deadbeef deadbeef deadbeef 0d034f40 00000000 00000000 0d034f50
up_stackdump: 0d02eaa0: 00000000 00000000 0d034f60 00000000 00000000 deadbeef deadbeef deadbeef
up_stackdump: 0d02eac0: deadbeef deadbeef deadbeef 0d034f70 00000000 00000000 0d034f80 00000000
up_stackdump: 0d02eae0: 00000000 0d034f90 00000000 00000000 deadbeef deadbeef deadbeef deadbeef
up_stackdump: 0d02eb00: deadbeef deadbeef 0d034fa0 00000000 00000000 0d034fb0 00000000 00000000
up_stackdump: 0d02eb20: 0d034fc0 00000000 00000000 deadbeef deadbeef deadbeef deadbeef deadbeef
up_stackdump: 0d02eb40: deadbeef 0d034fd0 00000000 00000000 0d034fe0 00000000 00000000 0d034ff0
up_stackdump: 0d02eb60: 00000000 00000000 0d034c90 ffffffe9 00000000 00000000 00000000 00000000
up_stackdump: 0d02eb80: 0d035000 00000000 00000000 0d035010 00000000 00000000 0d035020 00000000
up_stackdump: 0d02eba0: 00000000 00000000 00000000 00000000 00000002 0d02c8f8 0d025954 0d035030
up_stackdump: 0d02ebc0: 00000000 00000000 0d035040 00000000 00000000 0d035050 00000000 00000000
up_stackdump: 0d02ebe0: 00000000 00000000 00000000 00000000 00000000 00000000 0d035060 00000000
up_stackdump: 0d02ec00: 00000000 0d035070 00000000 00000000 0d035080 00000000 00000000 0d02ec70
up_stackdump: 0d02ec20: 0000003c 0d015777 0d0244f4 0d015843 00000000 0d035090 00000000 00000000
up_stackdump: 0d02ec40: 0d0350a0 00000000 00000000 0d0350b0 00000000 00000000 0000000a 0d0164ed
up_stackdump: 0d02ec60: 0d027390 00000005 0d034c60 0d01de65 0d0350c0 00000000 00000000 0d0350d0
up_stackdump: 0d02ec80: 00000000 00000000 0d0350e0 00000000 00000000 0000ffff 00000026 0d035c60
up_stackdump: 0d02eca0: 00000000 00000004 00000080 0d0350f0 00000000 00000000 0d035100 00000000
up_stackdump: 0d02ecc0: 00000000 0d035110 00000000 00000000 000000e0 0000002a 0d02edd8 0d021348
up_stackdump: 0d02ece0: 0d024594 00000000 0d035120 00000000 00000000 0d035130 00000000 00000000
up_stackdump: 0d02ed00: 0d035140 00000000 00000000 0d003cd1 00000001 00000000 00000000 00000075
up_stackdump: 0d02ed20: 0d0245f4 0d035150 00000000 00000000 0d035160 00000000 00000000 0d035170
up_stackdump: 0d02ed40: 00000000 00000000 041ac000 0d014cf3 041ac000 0d006d01 0d006a75 0d0245e8
up_stackdump: 0d02ed60: 0d035180 00000000 00000000 0d035190 00000000 00000000 0d0351a0 00000000
up_stackdump: 0d02ed80: 00000000 000000e0 000000e0 041ac000 00000002 0d0068ef 0d0068cf 0d0351b0
up_stackdump: 0d02eda0: 00000000 00000000 0d0351c0 00000000 00000000 0d0351d0 00000000 00000000
up_stackdump: 0d02edc0: 00000000 0d0062f9 00000000 0d000f11 000003ff 0d000f29 0d02459c 0d02459c
up_stackdump: 0d02ede0: 0d000000 0d024594 00000000 00000000 00000000 0d000b51 0d008707 00000101
up_stackdump: 0d02ee00: 00000000 00000000 00000000 0d00920f 00000000 00000000 deadbeef 0d02ee24
up_registerdump: R0: 198b37d8 0d02e8ec 00000001 00000000 198b37d8 00000047 0d02e8ec 0d024594
up_registerdump: R8: 00000000 00000000 0000003c 00000000 00000002 0d02e8d8 0d0015c9 0d00156e
up_registerdump: xPSR: 21000000 BASEPRI: 000000e0 CONTROL: 00000000
up_registerdump: EXC_RETURN: ffffffe9
up_taskdump: Idle Task: PID=0 Stack Used=0 of 0
up_taskdump: hpwork: PID=1 Stack Used=584 of 2028
up_taskdump: lpwork: PID=2 Stack Used=352 of 2028
up_taskdump: lpwork: PID=3 Stack Used=352 of 2028
up_taskdump: lpwork: PID=4 Stack Used=352 of 2028
up_taskdump: init: PID=5 Stack Used=2144 of 8172
up_taskdump: cxd56_pm_task: PID=6 Stack Used=320 of 996
up_taskdump: <pthread>: PID=7 Stack Used=312 of 1020
It is basically printed in the middle of another serial print that I defined.
I played around with the code, and as previously said, the error just gets triggered at a random point, as it seems. It seems to be present in pretty much all the sketches I tried with the SD Module and the error pops up even if the device is not actively using the SD module.
This is the code that I am currently trying to use
#include <SDHCI.h>
SDClass SD;
File myFile;
struct Landmark
{
// strings
String name;
String sound;
String rawLocation;
// actual location
float latitude;
float longitude;
// grid co-ordinates
float p1;
float p2;
float p3;
float p4;
};
bool proDebug = true; // debugging?
void getData()
{
Serial.println("Getting Data");
Serial.println("________________________________________");
Serial.println("Locating File");
Serial.println(" OK - Preparing Variables");
Landmark landmark[20];
int newLine;
int space;
int comma;
Serial.println(" OK - Opening File 'datalog.txt'");
String buffer = "datalog.txt";
myFile = SD.open(buffer);
Serial.println(" OK - Verifying Presence");
if(myFile)
{
Serial.println(" Success - File Loaded");
Serial.println("");
Serial.println("Extracting Data");
Serial.println(" OK - Beginning Final Extraction");
while(myFile.available())
{
char c = myFile.read();
if(c == '\n')
{
newLine++;
}
else if(c == ' ')
{
space++;
}
else
{
if(space == 0)
{
landmark[newLine].name += c;
}
else if(space == 1)
{
if(c == ',')
{
comma++;
landmark[newLine].rawLocation += c;
}
if(comma == 0)
{
landmark[newLine].latitude += c;
}
else
{
landmark[newLine].longitude += c;
}
landmark[newLine].rawLocation += c;
}
else if(space == 2)
{
landmark[newLine].sound += c;
}
}
}
}
else
{
Serial.println(" Error - File not Present");
Serial.println(" OK - Terminating Algorithm");
Serial.println("________________________________________");
Serial.println("");
while(1) {};
}
myFile.close();
Serial.println(" Success - Data Loaded Locally");
Serial.println("");
Serial.println("Data Feedback");
Serial.println(" OK - Dumping All Data");
Serial.println("");
for(int i = 0; i < (newLine + 1); i++)
{
Serial.print("Struct "); Serial.println(i);
Serial.print(" location name "); Serial.println(landmark[i].name);
Serial.print(" sound file "); Serial.println(landmark[i].sound);
Serial.print(" raw location "); Serial.println(landmark[i].rawLocation);
Serial.print(" latitude "); Serial.println(landmark[i].latitude);
Serial.print(" longitude "); Serial.println(landmark[i].longitude);
}
Serial.println("");
Serial.println(" Success - Data Dumped");
Serial.println("________________________________________");
Serial.println("");
}
void setup()
{
Serial.begin(115200);
while(!Serial) {};
Serial.println("");
Serial.println("");
getData();
}
void loop()
{
}
I found this documentation to be very useful : https://www.nuttx.org/doku.php?id=wiki:howtos:cortexm-hardfault
Also your best hope is to use a jtag probe and see with a debugger & breakpoints what happens and where in the code