Incomplete trace (due to high-speed SIM?)

[Min Xu]

Thanks for the feedback Rupert.

Holger

I am not familiar with git... but isn't there access restrictions on commit
to the git similar to svn?  If not, then I would try commit it later this
week.

Thanks



On Tue, Aug 13, 2013 at 3:36 PM, Rupert Lloyd <rupert.lloyd at gmail.com>wrote:

> 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/cefc1171/attachment.htm>