ISO 7816-3 section 10.2 defines WT = WI x 960 x Fi/f seconds,
store as etu, etu = Fi / (D x f) seconds, so the Fi cancels,
but the D does not:
WT [etu] = WI x 960 x D
cemu dropped both (?!) -> WI x 960.
The old comment explains why Fi can be dropped, which is right, but
what about Di ?!
sniffer gets it right (wt_wi * 960UL * wt_d), so the two state machines
disagreed here again, by up to a factor of 64???!!?!!?
This was fixed in osmo-ccid-firmware in 066489d in 2020 but not ported
to st2.
Additionally the waiting time was only recalculated at the end of the ATR,
where D is still 1 by definition, so a PPS increasing D reprogrammed the
baud rate but left the waiting time untouched??!
etu duration shrinks with D by the same factor, wall clock WT is
independent of D, which is the whole point.
The old code decreased the waiting time by a factor of D:
after a PPS to D=8 the card emitted its NULL procedure byte at ~0.09s
instead of ~0.71s with a reader deadline of ~1.43s,
and the inactivity timeout fires 8x too early, which probably led to
unexplained wtime_exp errors.
Update wt when WI becomes known (end of ATR) and
where D changes (after the PPS response) + tests.
Change-Id: I4263176d6073029d01f9ff5b11a6311617956af6
The sim presence pin allows the simtrace2 to inform the modem
about the presence of the simcard. On a generic simcard slot a
button is pressed by the simcard which generate a high or low voltage level.
Even though there are specifications of minipcie or ngff defining this signal, certain
modems behave different.
Certain modems require different signals from the specification.
Extend the usb protocol to set the behaviour at runtime.
Related: SYS#6946
Change-Id: I77118114ba873fdf0778137402888b40f2442456
Instead of using the timer/counter peripheral to handle the waiting time
and corresponding timeout, the USART peripheral internal timeout
mechanism is used.
This is particularly important for the SIMtrace board since there
(contrary to other boards) the I/O signal is not wired to a TIO pin
of the timer/counter block, and hence Rx/Tx data cannot reset that
timer/counter.
As a result of this migration, cardem is now supported not only on
owhw + qmod, but also on the simtrace board.
The guts of this change have been lifted out of Change-Id
Ibcb2c8cace9137695adf5fb3de43566f7cfb93b5 by Kevin Redon, which was
unfortunately touching various different topics at the same time and
hence was split up. Some improvements are the introduction of the
ENABLE_TX_TIMER_ONLY mode, which avoids the USART interrupt handler
getting hammered with TXRDY between release of RST and start of the ATR.
Change-Id: Ibcb2c8cace9137695adf5fb3de43566f7cfb93b5
Related: OS#1704
previously the card RST, VCC, and CLK signal states have been initialized with
default values corresponding to an inactive reader.
this worked fine for actual inactive readers since the default values match
and would be updated when the signal changes (edge detection).
but if the reader is in another state, card activation detection could fail.
this is fixed since the actual signal values are now used during initialisation.
at the same time I changed the variable type from uint8_t to boolean since they
have only two possible states, and understanding the actual state when coding
is simpler (no need to check which integer corresponds to which state).
this change has been successfully tested on the 2 slots of OWHW board.
Change-Id: Ie9245d75d48ae93d16f97897d4fa5ad6cd402e73
this changes how ATR is handled.
the ATR is also printed when set (as important debug information).
the test is also updated to correspond to the new mechanism (
simulating the timeout before sending the ATR)
Change-Id: I69df797e2feadffa9f5f977cb71b69386cee7cd0
The current protocol was card-emulation specific. The new protocol is
generic/flexible enough to accommodate both tracing and card emulation,
as well as modem control and other future extensions.
We now generalize the USB communiction and abandon the 'req_ctx'
structure inherited from openpcd. Instead we use the libosmocore 'msgb'
structure to handle incoming and outgoing USB tranfers. We also use
linuxlist-based msgb-queues for each endpoint.
we want to ensure that the length of every (current or future) message
can be determined by looking at cardemu_usb_msg_hdr.msg_len, rather than
having a length that is relative to the respective specific command.
when the emulator has received some data, don't just check that
we see it coming up on teh USB side, but actually also check
the content of those messages
I couldn't help but to spend my sunday on working towards card
emulation, including
* various state machines in the target about ISO7816 states
* tc_etu timer import from simtrace1
* req_ctx import from simtrace1 (needs renaming and simplifiation)
* USB protocol description as cardemu_prot.h
* some host-based testing code to test the state machines
The code seems to work fine throughout card reset, sending ATR and
receiving the TPDU header of the first APDU, up to the point where it
marks the TPDU header as to-be-transmitted over th bulk-in endpoint.
Sending the ATR must be done inside the firmware for timing
requirements.
From that point onwards, the host needs to respond at the very least
with a procedure byte, and some indication whether or not the card
emulator should continue to transmit data (card->reader), or receive
data (reader->card).
The code is intentionally not hooked up yet with the USB logic nor with
the UART. I want host-based testing completed before doing that.
Eric Wild