Incomplete trace (due to high-speed SIM?)

[Rupert Lloyd]

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)

Thanks for the change!

Rupert


On Fri, Aug 9, 2013 at 4:54 PM, Min Xu <mxu at sanjole.com> wrote:

> Hi Holger
>
> 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:
>
> 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
>
> 2)  Disable USB interrupt before deciding to Continue to send stuff to USB
> until returning from function.
>
> 3)  lock out interrupt ONLY when retrieving a new req_ctx to transmit to
> USB
>
> 4)  Some additional code change to detect if a req_ctx is completely
> transmitted ..
>
> 5)  An additional function call in the main loop to detect (and output to
> debug serial) if an overrun occured
>
> Attached is my diff file based on what's in git.
>
>  Let me know if it works for you
>
>
> On Thu, Aug 8, 2013 at 9:58 PM, Holger Hans Peter Freyther <
> holger at freyther.de> wrote:
>
>> On Wed, Aug 07, 2013 at 09:52:04AM -1000, Min Xu wrote:
>>
>> Dear Min,
>>
>>
>> > There appears to be numerous references to "decrease the buffer in the
>> > firmware" to workaround the problem of losing bytes... but
>>
>>
>> src/simtrace/iso7816_uart.c:process_byte
>>
>>         if (rctx->tot_len >= rctx->size || ih->rctx_must_be_sent) {
>>                 ih->rctx_must_be_sent = 0;
>>                 send_rctx(ih);
>>         }
>>
>> You could change this part.
>>
>> > can you clarify which buffer to decrease, in which source file?
>> >
>> > I am guessing it's the req_ctx.c / req_ctx.h?
>>
>> yes, or make sure the ->size is smaller.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/simtrace/attachments/20130813/37f7317e/attachment.htm>