Closed ceres-c closed 4 years ago
Very sorry about that, it was a rogue copy-paste. I'll fix it tomorrow :) BTW I have no idea how it did slip through, since I was pretty sure I tested everything
Done
Fixed the long standing https://github.com/emsec/ChameleonMini/issues/262
This PR includes and supersedes https://github.com/emsec/ChameleonMini/pull/272
Me and @MrMoDDoM have been refining ISO15 code due to an issue we faced with the ST CR95HF reader. We thought something was wrong with the codec because the Read Multiple Blocks failed when reading more than 7 blocks at once. It felt like an issue when modulating long frames but, after some investigation it turned out that the ST reader was very precise with SOF timings. Reading more than 7 blocks into the codec's buffer take too much time, and this means that ISO t1 time elapses before data is ready and the codec is stuck waiting for data before it can modulate anything, so the reader complains as it did not receive a SOF in time. This kind of issues is not present with the phones we've tested the code with
I'd like to discuss about ISO t1 time, since we could not explain how the old value
4192 + 128 + 128 - 1
was chosen. This value is greater than both ISO dictated nominal and maximum t1, but yielded better results than t1 nominal, so reading 10 blocks at a time was possible. This is possibly due to the fact that waiting "a bit more" allows the Application to generate needed data before the first interrupt hit occurs and, at that time, data is marked as ready to be processed by CodecTask. How was the old value chosen? Do we want to favor performance over emulation accuracy? Which value should be kept?Also, applications were updated to improve performance. Reading the UID on every ApplicationTask hit was totally unnecessary and a big performance drag