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/.
Holger Hans Peter Freyther holger at freyther.deOn Fri, Aug 09, 2013 at 10:54:28AM -1000, Min Xu wrote: > Hi Holger Dear Min, > > 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: thank you for the analysis and the change! Would you like to create entire git commits for the various things and follow the kernel coding style? > 5) An additional function call in the main loop to detect (and output to > debug serial) if an overrun occured great! We have a slightly different coding style but the change itself looks good and I would support it to be included. > 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 this seems reasonable. Using git gui blame on the req_ctx.h I notice that this has already been increased for the SIM, increasing it further can make sense. > > 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 .. I can't comment on these three as I have not looked into the inner workings of the USB code yet. I would propose we start with creating three git commits for the first three things and then look into locking/disabling irqs. thanks a lot holger