<div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">I applied this patch and it seems to have fixed my dropped byte issue. Before the patch I could not capture more than ~10 APDUs without dropping bytes, now I am getting through the entire startup sequence (600+ APDUS) <br>
<br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Thanks for the change!<br><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Rupert<br></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Fri, Aug 9, 2013 at 4:54 PM, Min Xu <span dir="ltr"><<a href="mailto:mxu@sanjole.com" target="_blank">mxu@sanjole.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div><div>Hi Holger<br><br>Thanks for getting back to me.  After analyzing the issue, I believe the issue is the overrun error the USART reports.  The issue appear to stem from the fact that each byte received by the USART is handled in the interrupt handler, but the USB sending code locks out the interrupt for the entirety of its call.  So I change the code in the following manner and it appears to solve the issue for me:<br>


<br></div>1)  Increase the small buffer to be large enough to hold 1 typical apdu:  270 bytes:  4 byte SIMTrace header, 4 byte command,  2 byte status, 1 byte instruction that appears to be repeated??  256 bytes payload<br>


<br></div>2)  Disable USB interrupt before deciding to Continue to send stuff to USB until returning from function.<br><br>3)  lock out interrupt ONLY when retrieving a new req_ctx to transmit to USB<br><br></div><div>4)  Some additional code change to detect if a req_ctx is completely transmitted ..<br>


<br></div><div>5)  An additional function call in the main loop to detect (and output to debug serial) if an overrun occured<br></div><div><br></div><div>Attached is my diff file based on what's in git.<br><br></div>

<div>
Let me know if it works for you<br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 8, 2013 at 9:58 PM, Holger Hans Peter Freyther <span dir="ltr"><<a href="mailto:holger@freyther.de" target="_blank">holger@freyther.de</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Aug 07, 2013 at 09:52:04AM -1000, Min Xu wrote:<br>
<br>
Dear Min,<br>
<div><br>
<br>
> There appears to be numerous references to "decrease the buffer in the<br>
> firmware" to workaround the problem of losing bytes... but<br>
<br>
<br>
</div>src/simtrace/iso7816_uart.c:process_byte<br>
<br>
        if (rctx->tot_len >= rctx->size || ih->rctx_must_be_sent) {<br>
                ih->rctx_must_be_sent = 0;<br>
                send_rctx(ih);<br>
        }<br>
<br>
You could change this part.<br>
<div><br>
> can you clarify which buffer to decrease, in which source file?<br>
><br>
> I am guessing it's the req_ctx.c / req_ctx.h?<br>
<br>
</div>yes, or make sure the ->size is smaller.<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>