DMA & circular buffer improvements

edo512 · 2009-04-26 18:55:49

I have noticed that some of the software UART routines in the Proxmark tend to exceed the DMA circular buffer capabilities fairly easily (hi14snoop for instance). In the latest (Revision 12) SVN, I have made an attempt at increasing the limit at which the routines complain about the DMA buffer being 'blown', but I am not 100% sure I followed the right method: at what limit should we declare that the DMA buffer is blown? DMA buffer size ? A bit less ?

In particular, it seems that depending on the toolchain I use, I get very different performance on the same routines, some giving very good performance - the Windows toolchain on this site -, others being pretty bad - gcc 4.3.0 on Linux for instance. Does anyone have advice on the right choices there ?

Also: most routines make use of a globally-defined DMA buffer size: is there any reason not to adapt the DMA buffer size to requirements depending on the function that is called ?

Thanks for your input!

ED

reuse · 2009-04-27 07:40:22

hi,edo512

i'm also suffer form the blew error message, no matter what version i'm using,
the binary file from here or the binary files compiled by the toolchains provided here.
so whree can i change the buffer size or others and make the hi14asnoop routine run successfully.
i'm using AT91sam7s256 chip.

rule · 2009-04-27 09:37:34

circular buffer blown is not always related to the size of the buffer, it could be because the communication with the FPGA is not parsed in time. For example, if you add to much (debug)logging in your functions, you will notice this problem as well.

I suggest to use small and clean functions to avoid useless cpu-power thrown away from the microprocessor. But I must agree, sometimes the errors seems not relevant at all. For instance it could make a difference if you declare your variables as globals, static globals or local(with stack usage).

@reuse
If your Proxmark ALWAYS gives this message, you probably have a hardware problem. The device should work out of the box with the default binary files available on this site.

edo512 · 2009-04-27 09:51:11

reuse,

Can you try the latest SVN version compiled with the Windows toolchain provided on this site and let us know? In my case, I never get those "blew circular buffer" errors anymore with hi14snoop or hi14asnoop...

reuse · 2009-04-27 10:55:58

hi,
@edo512, i have tried the latest SVN version, the same error message....

@roel , so where can i check the hardware? the hi14areader and hi14asim function acts well
may because the fpga demage?

I really do not know where to inspect now.

btw, when i run armpgm.exe , read the MC_FSR register, now value is 0000002f01 , i think i have change some bit
of it, but i don't know the original value , may this cause the error?

>> Started prox, built Apr 27 2009 17:39:10
>> Connected to device
> tune
# LF antenna @   0 mA /   134 mV [1273 ohms] 125Khz
# LF antenna @   0 mA /     0 mV [1187 ohms] 134Khz
# HF antenna @   0 mA /    96 mV [235 ohms] 13.56Mhz
> tune
# LF antenna @   0 mA /     0 mV [1273 ohms] 125Khz
# LF antenna @   0 mA /     0 mV [1187 ohms] 134Khz
# HF antenna @  59 mA / 13954 mV [235 ohms] 13.56Mhz
> tune
# LF antenna @   0 mA /   134 mV [1273 ohms] 125Khz
# LF antenna @   0 mA /     0 mV [1187 ohms] 134Khz
# HF antenna @  38 mA /  8991 mV [235 ohms] 13.56Mhz
> hi14areader
#db# 000012a8, 000000cc, 000000cc

#db# ready..
> hi14alist
recorded activity:
 ETU     :rssi: who bytes
---------+----+----+-----------
 +      0:    :     52    
 +     64:   0: TAG 04  00    
 +    -64:    :     93  20    
 +    128:   0: TAG 45  2c  f4  44  d9    
 +   -128:    :     93  70  45  2c  f4  44  d9  92  a3    
 +    200:   0: TAG 08  b6  dd    
 +   -200:    :     95  70  c2  0a    
 +      0:    :     52    
 +    272:   0: TAG 04  00    
 +   -272:    :     93  20    
 +    336:   0: TAG 45  2c  f4  44  d9    
 +   -336:    :     93  70  45  2c  f4  44  d9  92  a3    
...........
> hi14asim
Emulating 14443A TAG with UID 0               0
#db# button press
#db# 00000000, 00000000, 00000000

> hi14asnoop
#db# blew circular buffer!
#db# 00000191, 00000000, 00000000

#db# 00000020, 00000000, 00000000

> hi14snoop
#db# blew circular buffer!
#db# 000000ff, 00000000, 00000000

Last edited by reuse (2009-04-27 11:08:29)

rule · 2009-04-27 11:51:46

reuse wrote:

btw, when i run armpgm.exe , read the MC_FSR register, now value is 0000002f01 , i think i have change some bit of it, but i don't know the original value , may this cause the error?

At the moment I do not have a JTAG at hand, but looks not like the value my Proxmark has. I remember some hex-value with only one bit. But I would not bet on it that it was 0000000001 .

You can lookup the MC_FSR register settings of the ARM in the datasheet to understand it better.

It would be useful to get someone to read this out for you from a working Proxmark. I will add this "correct" MC_FSR to the flash-howto.

shinechou · 2009-04-28 04:30:22

roel wrote:

reuse wrote:
btw, when i run armpgm.exe , read the MC_FSR register, now value is 0000002f01 , i think i have change some bit of it, but i don't know the original value , may this cause the error?
At the moment I do not have a JTAG at hand, but looks not like the value my Proxmark has. I remember some hex-value with only one bit. But I would not bet on it that it was 0000000001 .
You can lookup the MC_FSR register settings of the ARM in the datasheet to understand it better.
It would be useful to get someone to read this out for you from a working Proxmark. I will add this "correct" MC_FSR to the flash-howto.

for me, it's "0x00000001", 20081211 version and working!

reuse · 2009-04-28 05:16:08

thx. i will try to recover to the original setting and test again.

after days of trying, with recover to the original value. the issue still not reolved.

so i have some tests.

first I comment the code that directly infect "blew buffer"

//        if(behindBy > maxBehindBy) {
//            maxBehindBy = behindBy;
//            if(behindBy >400) {
//              DbpIntegers(maxBehindBy, lastRxCounter, PDC_RX_COUNTER(SSC_BASE));
//                DbpString("blew circular buffer!");
//                goto done;
//            }
//        }

//        if(behindBy < 1) continue;

the results shows that only the PCD been captured. the answer from the tag seems been all lost.

> hi14asnoop
#db# cancelled_a
#db# 00000000, 00000000, 00000000

#db# 00000064, 0000004b, 00000053

> hi14alist
recorded activity:
 ETU     :rssi: who bytes
---------+----+----+-----------
 +      0:    :     52    
 +  30684:    :     93  20    
 +  33052:    :     93  70  f2  8e  01  e7  9a  00  16    
 +  64644:    :     30  0c  6e  62    
 +  32180:    :     30  0d  e7  73    
 +  32424:    :     53

all the other fuction hi14areader and hi14asim all works fine. so where should can i check next?

Last edited by reuse (2009-05-02 19:17:40)

reuse · 2009-05-02 19:47:51

after time and time testing... now i got the result as below...
i just comment the code as up post.

at least it works now just the sharp and number of coils of the antenna ,
also the position.....

now the question is that , the TAG only answer not more than 4 times..

> hi14asnoop
#db# cancelled_a
#db# 00000000, 00000000, 00000000

#db# 00000064, 0000008d, 000000ea

> hi14alist
recorded activity:
 ETU     :rssi: who bytes
---------+----+----+-----------
 +      0:    :     52    
 +     65:   0: TAG 04  00    
 +  31843:    :     93  20    
 +     64:   0: TAG 5c  94  5b  d3  40    
 +  32684:    :     93  70  5c  94  5b  d3  40  ff  da    
 +     64:   0: TAG 08  b6  dd    
 +  35212:    :     61  08  65  ee    
 +    112:   0: TAG eb  09  e3  b2    
 +  29160:    :     de  91  5f  2a      !crc
 +  32528:    :     7d  f8  77  b4      !crc
 +  32532:    :     d6  ce  db  44      !crc

Last edited by reuse (2009-05-02 20:31:09)

rule · 2009-05-03 10:17:10

Dear reuse,

Since this question came up several times in the community I decided to add the answer to the FAQ.
I hope this answer fix your problems.

cheers, Roel

reuse · 2009-05-03 13:34:34

thx roel,
the attena is so important.. ..

in my view now ,if the voltage is less than 14V, it is more difficult to capture the PCD answer.

HF antenna @  59 mA / 13954 mV [235 ohms] 13.56Mhz

if just want to read some HF card, I have tested that the voltage low to 8V, and when put the card on, the voltage actully increase a bit.. even the low votage , it read the card well.
may this can help somebody.

Last edited by reuse (2009-05-03 13:40:38)

toffe · 2010-04-12 23:41:13

I think there's a bug lurking somewhere beyond the ARM and maybe in the FPGA, look at this topic:
http://www.proxmark.org/forum/topic/542 … -of-order/

It seems something triggers the FPGA to output a constant serial stream of 1.695Mbit/s! It's no wonder the buffer is being blown.

Pondering, it seems 1.695MHz is exactly 1/8th of 13.56MHz... I wonder what that means.

Proxmark3 community

Announcement

#1 2009-04-26 18:55:49

DMA & circular buffer improvements

#2 2009-04-27 07:40:22

Re: DMA & circular buffer improvements

#3 2009-04-27 09:37:34

Re: DMA & circular buffer improvements

#4 2009-04-27 09:51:11

Re: DMA & circular buffer improvements

#5 2009-04-27 10:55:58

Re: DMA & circular buffer improvements

#6 2009-04-27 11:51:46

Re: DMA & circular buffer improvements

#7 2009-04-28 04:30:22

Re: DMA & circular buffer improvements

#8 2009-04-28 05:16:08

Re: DMA & circular buffer improvements

#9 2009-05-02 19:47:51

Re: DMA & circular buffer improvements

#10 2009-05-03 10:17:10

Re: DMA & circular buffer improvements

#11 2009-05-03 13:34:34

Re: DMA & circular buffer improvements

#12 2010-04-12 23:41:13

Re: DMA & circular buffer improvements

Board footer