Closed SpenserStyles closed 5 years ago
Compiler Error? Or optimization got worse? The iso14443b code is quite timing critical, but I would have assumed that newer compilers would be able to generate faster code. Would you be able to compile iso14443b.c with both compilers to ARM assembler source (i.e. with options -S -o iso14443b.s
instead of -c -o iso14443b.o
, other options unchanged) and provide both assembler sources for downloading?
What OS?
Can you post the output of brew info? Like:
tom@SilverBox:~/Git/proxmark3-RRG-T$ brew info nitsky/stm32/arm-none-eabi-gcc nitsky/stm32/arm-none-eabi-gcc: stable 20180627 GCC for embedded ARM processors https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads /usr/local/Cellar/arm-none-eabi-gcc/20160926 (5,502 files, 447.0MB) * Built from source on 2018-08-16 at 07:36:19 /usr/local/Cellar/arm-none-eabi-gcc/20180627 (5,658 files, 467.4MB) Built from source on 2018-08-01 at 13:24:11 From: https://github.com/nitsky/homebrew-stm32/blob/master/arm-none-eabi-gcc.rb
I believe it to be an optimization issue that is screwing up the timing. More details: Compiled on Ubuntu 16.04 with arm-none-eabi-gcc v4.9.3 and "hf 14b sri512read" works Compiled on Ubuntu 18.04 with arm-none-eabi-gcc v6.3.1 and "hf 14b sri512read" does not work
Uploaded iso14443b.s files compiled with -S instead of -c for both compilers.
The v6.3.1 is definitely optimizing more. During reprogramming it program 365 blocks vs 370 blocks for v4.9.3.
I cannot confirm but you may have stumbled over the issue described here: https://www.raspberrypi.org/forums/viewtopic.php?t=187493
Try 7.3.1. It creates even smaller (362 blocks) code and hf 14b still works.
@SpenserStyles : can we close this?
Thanks for looking into it and yes please go ahead and close!
I am trying to read SRI512 card using PM3. I cloned the latest repo as of 2018-08-29. I can read SRI512 cards when I compiled the armsrc with arm-none-eabi-gcc v4.9.3 20150529. I can NOT read SRI512 cards when I compile the armsrc with arm-none-eabi-gcc v6.3.1 20170620.
Has anyone else seen this issue?