Closed sh7d closed 4 years ago
maybe a git bisect
to find the triggering point.
It seems to me it doesn't always trigger. We would need to find a way to trigger it reliable.
Most likely the sumadc/avgadc changes to get a better fine tuning in the voltage steps that overflows the u32.
@iceman1001 its not only the tune, the commands also not working (see my example whit lf search), soo i dont think that type overflow is a problem there (but not for sure :))
I found commit that makes things unreliable: On daa39dff works with this litte patch:
diff --git a/Makefile.defs b/Makefile.defs
index fb8a7a45..3eac6926 100644
--- a/Makefile.defs
+++ b/Makefile.defs
@@ -52,7 +52,7 @@ DEFCFLAGS = -Wall -Werror -O3 -fstrict-aliasing -pipe
# Some more warnings we want as errors:
DEFCFLAGS += -Wbad-function-cast -Wredundant-decls -Wmissing-prototypes -Wchar-subscripts -Wshadow -Wundef
# Some more warnings we need first to eliminate, so temporarely tolerated:
-DEFCFLAGS += -Wcast-align -Wno-error=cast-align
+DEFCFLAGS += -Wcast-align -Wno-error=cast-align -Wno-stringop-truncation
DEFCFLAGS += -Wswitch-enum -Wno-error=switch-enum
ifeq ($(platform),Darwin)
On a53c4a8a5bbc2c034d3f4341a5821f222b0d0e2e the bad magic happens So i reverted a53c4a8a5bbc2c034d3f4341a5821f222b0d0e2e and my proxmark started working as usual Looks like its related to the famous stack size can of worms :)
More info:
$ gcc --version
gcc (GCC) 10.1.0
$ arm-none-eabi-gcc --version
arm-none-eabi-gcc (Arch Repository) 10.1.0
However we are not using 9K stack, we are using 8488 bytes now. the tune command doesn't use much variables. Could be from swapping LF -> HF....
https://github.com/RfidResearchGroup/proxmark3/commit/b5345eb0bd83d53a0f4241ce6c726c238dec32a1
However we are not using 9K stack, we are using 8488 bytes now.
Yes, and i reverted change on the newest master and it magically working, so its not that i reporting it working under daa39df Just what i did it was:
$ git checkout master
$ git revert a53c4a8a5bbc2c034d3f4341a5821f222b0d0e2
$ git mergetool
$ git add common_arm/ldscript.common
$ git commit
$ git show HEAD
commit 751288ace18e5343ef3e5e3d8376c7e264ee589c (HEAD -> master)
Author: sh7d <47714037+sh7d@users.noreply.github.com>
Date: Thu Jun 25 16:57:30 2020 +0200
Revert "chg: adapt stack , run "lf search" on a blank t55xx now ok"
This reverts commit a53c4a8a5bbc2c034d3f4341a5821f222b0d0e2e.
diff --git a/common_arm/ldscript.common b/common_arm/ldscript.common
index 610e5c0b..c1fb5e84 100644
--- a/common_arm/ldscript.common
+++ b/common_arm/ldscript.common
@@ -9,7 +9,7 @@ ms of the GNU GPL, version 2 or,
-----------------------------------------------------------------------------
*/
-stacksize = DEFINED(stacksize) ? stacksize : 8488;
+stacksize = DEFINED(stacksize) ? stacksize : 6K;
commonareasize = 0x20;
/* AT91SAM7S256 has 256k Flash and 64k RAM */
Could be from swapping LF -> HF....
If you mean of swapping of physical connection i assure you that is impossible: i use proxmark 3 rdv4 and you cant close the casing when antenna is swapped like that (beside the wrong pin configuration), also tested it with the other (old type with no switches) antenna with similar result
Sadly the smaller stack size makes the newest fun with hitags2 tags impossible so im stuck for now :(
Try increasing 6k->7k,-8k and see where the tune messes up
$ git diff
diff --git a/common_arm/ldscript.common b/common_arm/ldscript.common
index 610e5c0b..0472b8fd 100644
--- a/common_arm/ldscript.common
+++ b/common_arm/ldscript.common
@@ -9,7 +9,7 @@ ms of the GNU GPL, version 2 or,
-----------------------------------------------------------------------------
*/
-stacksize = DEFINED(stacksize) ? stacksize : 8488;
+stacksize = DEFINED(stacksize) ? stacksize : 8K;
commonareasize = 0x20;
/* AT91SAM7S256 has 256k Flash and 64k RAM */
Works, double checked if that change matters in that case. And also, hitag finally working:
> lf hitag reader 21
[+] UID: 273b1b10
[=] Hitag2 tag information
[=] ------------------------------------
[+] Config byte : 0x06 [ 00000110 ]
[+] Encoding : Manchester
[+] Version : Hitag2
[+] Coding in HITAG 2 operation: manchester
[+] Tag is in : Password mode
[+] Page 6,7 : RW
[+] Page 4,5 : RW
[+] Page 3 : RW
[+] Page 1,2 : RW
[=] ------------------------------------
Wow, hitag2 works again. This is awesome!
I am closing this issue. See https://github.com/RfidResearchGroup/proxmark3/issues/921
I think many of those bad swaps of fpga image has been resolved in latest master, but if you still have this issue, looking at the output from hw status
shows a telling indication whats wrong. See that linked issue for actions.
[#] Tracing
[#] tracing ................1
[#] traceLen ...............0
[#] Current FPGA image
[#] mode.................... --- telling tale that device is unstable.
[#] Flash memory
Describe the bug In recent software revision (branch: master, commit: 1c275103948ca33580f621c7b3fc3266290de2d6) hw antenna tune going just hairwire and gives weird results:
Sometimes HF antena are working:
In any case lf tags are not found, so its not only the problem with the command: lf search with tag on proxmark:
When i checkout v4.9237 its working like a charm:
And yes, i reflashed firmware between the runs
To Reproduce Steps to reproduce the behavior:
Expected behavior Hw tune should work same regardless of the software revision
Desktop (please complete the following information):
Using the newest software from master branch: