tx_cfg->features is logged before the memcpy() that fills it.
Looks like no one is using config.ac --enable-sanitize?
Change-Id: Id8369d312c8600ba9eea80c8f7782f196d7e20d1
7816-3 8.1/8.2.1 allow TS plus 32 bytes.
atr_i is a byte count, not an index, process_byte_atr() guards its own
store with the same condition before incrementing, so atr_i reaches 33.
Change-Id: Ic8398cbefc0b522946b6470fd0268fa70662dab1
(~g_tpdu.packet[1]) == byte can never be true.
Unary ~ applies the integer promotions first,
so for tpdu INS = 0xA4 lhs should be 0x5B but as int
it gets zero extended to at least 16 bits and then flipped,
so it is 0xFFFFFF5B = -165, byte promotes to 0..255.
The ack was therefore dead code -> fallthrough to SW1
branch, fails 0x6x/0x9x test, TPDU gets flagged
SNIFF_DATA_FLAG_ERROR_MALFORMED from what I can tell.
But I am losing track of all these arcane issues to be honest.
Narrow the complement back to 8 bits.
Fyi this is unrelated to signedness and not specific to ARM.
Change-Id: I800f50ef35356429d07aa685ea919e70ec34946e
add_tpdu_byte() accumulates bytes received from the reader, but passes
reader_to_card = 0, but ISO 7816-3 10.3.2 says P3 == 0 means 256 not 0
Only reachable with P3 == 0 in a receive data phase, but
simtrace2-cardem-pcsc only requests PB_AND_RX when there is command data.
Fix this anyway.
Change-Id: I0fa4741bc1293549816595e6b4e8af9e22bcfbc1
cardem:
- dispatch_usb_command_cardem() appends to uart_tx_queue from the main loop
- tx_byte_tpdu() dequeues from the USART IRQ handler @ NVIC prio 0
card_handle_reset() has the same issue, drains queue and
frees uart_tx_msg from main loop while the ISR may own them.
All of this needs protection against the irq.
Needs a fixed llist_add_tail_irqsafe(), which called __enable_irq() instead of
restoring the saved PRIMASK for some unknown reason?!?!?!?
Change-Id: I7d9cdcc56263b27dfd4649dfb1da1d67761ee923
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
US_FIDI_FI_DI_RATIO_Msk is 0x7ff,
cemu rejected >= 0x400 in emu_update_fidi() and masked with 0x3ff
in card_emu_uart_update_fidi(), but update_fidi() used by
the sniffer already used 0x7ff.
-> ratios 1024..2047 are unusable in cemu, which is the entire upper
half of ISO 7816-3 Table 7 at Di=1.
A reader trying one of those in a PPS gets the proposal echoed and
accepted, after which the card keeps transmitting at the old rate.
FI_DI_RATIO is clock periods per bit -> larger ratio is a SLOWER link.
The old check rejected slow values but accepted Fi=372/Di=64, ratio 5 !?
Unify and use the register mask (= shifed by 0 so usable as value) and
reject ratios that do not fit rather than truncating to garbage dividers.
Change-Id: I6211dd5be7c5c5d2150af2aa37a403b33e6d340d
iso7816_3_compute_fd_ratio() multiplied F by D for every d_index >= 8,
presumably because the upper half of ISO 7816-3 Table 8 encodes 1/D.
But 7816-3 2006 and 1997 differ!
That assumption is only true for the range 1010..1111, which in the
2006 version is RFU. Indices 1000 and 1001 are Di = 12 and Di = 20,
see iso7816_3_di_table[].
So right now Fi=372/Di=12 -> 372 * 12 = 4464 instead of 372 / 12 =
31.
In the cemu value is rejected in emu_update_fidi()
and the old baud rate is silently kept.
In the sniffer update_fidi() programs US_FIDI as
4464 & 0x7ff = 368, which is garbage.
Use F/D for indices 1..9 and keep the legacy 1/D reading only for the RFU
range, where we cant really do anything useful anyway.
Change-Id: I44d6451d8b04aea2b0db7291b06a812afe84e52f
Due to popular demand people want elf files that can be loaded to get
debug symbols, so publish the elf file, but not the stub-less bin file.
This elf file can ONLY be used to look up symbols, it should NOT be
"load"ed into flash, because the preceding crc stub has to match. Mixing
older crc stubs that are still in flash and newer elf files means the
device will end up in DFU mode upon reset.
Change-Id: Ifceb16d385388356ac1bf8b13f5df62c643bebf8
DFU flashing of apps sometimes aborts, and although rare this leads to
broken devices if no boot button or serial/jtag access exists, because
the bootloader will keep trying to start a half-flashed app that then
crashes at some point.
The easiest fix that works with existing bootloaders is to prepend a
small 512 byte stub that calculcates the crc and compares it with the
crc calculated at build time, and then either starts the actual app, or
sets the dfu flag and resets. This ensures we either have a working,
running app, or end up in the bootloader, ready to flash again.
For obvious reasons this only applies to dfu apps, and not to flash
targets like the actual bootloader itself.
Change-Id: Id6df0486c8b779889d21800dc2441b3aa9af8a5f
The previous value was way too low and led to reenumeration issues when
switching from app to bl because the hosts are fairly lenient and
feature long delays until they accept disappearing devices as gone for
good instead of ignoring a presuambly flaky usb cable or connection.
Related: SYS5061
Change-Id: I9b8c8bf794ad5b94fc7ea2a01d1ebf4e36862c36
All the parts are DNP and never existed on the simtrace2 with sam3; the
sam3 has internal pullups that are part of the usb peripheral.
Change-Id: I04a703a2eba6ff1dc64692c089213389d0c1066d
This bl updater can be flashed as app and will update the bootloader and
then
delete itself before resetting the sam3, so the device will end up in
the newly
updated dfu bootloader afterwards, without having to press the
bootloader button
or requring any other manual interaction, ready to receive a new
application image.
Building the blupdater requires a previously built dfu-flash bootloader
bin file that
will then be embedded into the app during building.
Related: OS#1704
Related: SYS5061
Change-Id: I53dea57bba790a2ab3245d9483e0ff1c8d19d5e3
This led to occasional crashes for targets with leds since it was
introduced 3 years ago
The interesting thing is that most of the time it didn't crash...
Change-Id: Ia6a1b1fc0e44a301b4fb1d9c9fdbc27d61dcab97
Supposed to be used with https://github.com/ARM-software/LLVM-embedded-toolchain-for-Arm
+ distro provided binutils-arm-none-eabi package, might provide better and more reliable
binary sizes, especially for the bootloader.
Just run USE_CLANG=1 make
Change-Id: I1a19f40d44797efad5c46121e73115ed738a095b
This reverts commit e6a76c7bf4.
Might or might not cause weird issues depending on gcc and binutils
versions, let's see if this helps.
Change-Id: I2f593fd5e0f1494aae6b9fcfb2160a6c9168f5b8
We keep running out of rom space, so reduce tracing to nothing for alle
dfu targets, and let's hope newer gcc versions stop producing more
code...
Change-Id: I7d2947c84097035bed00ad489a175d614b4c388e
It does fit with some compiler versions, while others overflow the bl region,
so just reduce the trace level a bit to make it fits all the time.
Change-Id: I168a847da8dfc585aaeef0030f95fc225a713147
The "wait time extension timer" was apparently not being reset during
normal tx operations, which led to occasional NULL (0x60) bytes getting
injected into transfers, which in turn led to more tx bytes than what
the reader side expects...
The odd thing is that this was only noticeable with high baud rates,
probably due to the very long default WT of 9600 ETU, and even then only
because it led to weird ngff modem resets after benign transfers.
Change-Id: I15b0b83b7d93b8e5589f3640bd6eb2fc82f93394
Related: SYS#5553
There is no obvious reason why the st should be stuck in cardem mode
without a working running util on the host side since there is no state
that is being kept, so switch back to using the local sim upon reset.
Change-Id: Ib622af0027d40b4e8afbb0fa0d3689f0dbfcac92
Single threaded evaluation is (assumed to be!) left to right, depth
first - but with concurrent make using -j this breaks, because the
actual usb string header is generated after the attempt to concurrently
compile the code that needs it, since there is no explicit order among
the all: dependencies.
This is fixed by properly adding a dependency on that header.
Change-Id: I0bdf915deabeda861f6398e654764918e58a64c2
The tester has shifters, while the original simtrace relies upon the
reader restarting the powerup attempt with > 1v8 after not respondig due
to a lack of shifters and therefore 1v8 support.
Change-Id: I520aa26c6e0fb34568a4f632943efa59a0da831c
See Help->About Wireshark->Folders tab,the usual place this should go is
~/.local/lib/wireshark/plugins
Hot reload possible after editing using Analyze->Reload Lua Plugins
Change-Id: I360ab522dabc3a378969df36efd3b48fc4cade3c
make V=1 can be used to echo all compilation commands, which is useful
because it allows IDEs to parse the gcc output in oder to properly index
the source files using the actual defines passed to the compiler.
Change-Id: I25c41dff89302a73ddd2a4aaba7cb14912fac3b8
For some reason undefined symbols were downgraded to warnings, which
means building a firmware that calls missing functions (= address zero)
was perfectly fine, which of course made development more exciting....
This applies to builtins, too, printf of one char gets downgraded to
putchar, which we don't have, so disable builtins.
Change-Id: I492f41ad4162b9d07b1881ae4aed019db2dff8b5
dfu flashing the ST12 was easy, but i was never able to
get ST34 into dfu mode. Changing the firmware so it resets
itself just like the octsim instead of starting a timer and
waiting for a reset from the host made it work every time for me.
Change-Id: Ida636ec925f40d6d56551f170150181350d03bbd
cardem on the st2 has been broken forever and still does not work, so
stop uploading cardem binaries
Change-Id: I33828f799d41386afb3f8dcd9bb510902877e03f
Eric Wild