This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/simtrace@lists.osmocom.org/.
Min Xu mxu at sanjole.comThanks 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>