The ChameleonMini is a versatile contactless smartcard emulator compliant to NFC. The ChameleonMini was developed by https://kasper-oswald.de. The device is available at https://shop.kasper.it. For further information see the Getting Started Page https://rawgit.com/emsec/ChameleonMini/master/Doc/Doxygen/html/_page__getting_started.html or the Wiki tab above.
Other
1.73k
stars
392
forks
source link
Enhancements to LOGMODE=LIVE logging functionality #279
The brief features added in this pull request (PR) are a preview of some of the modifications I have made in my firmware mod to support DESFire tag emulation. The bugs that this PR fixes have already been pointed out by @ceres-c in issue #276. There is also a slight modification to the LUFA config file LUFAConfig.h, which will eventually be needed to support the DESFire emulation (whenever that code is eventually ready). A few Makefile compiler flags have been tweaked, though nothing too substantially at this point.
The LOGMODE=LIVE feature, despite being a favorite method of mine to get immediate NFC data with the Chameleon devices and the reason I created my logger app for Android, seems to be underutilized by users. This is evident since there have not yet been bug fixes to correct for the common error that the new file LiveLogTick.h (included by Log.c) solves. Basically, the logging functionality onboard the RevG devices gets called in the application tick functions that run a given tag emulation specified by CONFIG=<NAME>. This causes a problem sometimes when semi-asynchronous calls to other serial USB transfer commands execute or overlap with these calls. When this seems to happen, the output over serial USB logged by my app, or say by a minicom session, can either get jumbled or concatenated. My app, for example, expects the log type header data to be at the start of a data buffer transferred over serial USB. The fix for the observed bug with LIVE logging improves the stability of things quite a bit.
The fix involves delaying writing data by logging commands LogEntry(...) until a separate tick function is executed, approximately every 3 * 100ms. In the meantime, since LIVE logging does not utilize the LogMem buffer usually reserved for LOGMODE=MEMORY settings for logging, we re-use this buffer to store the logging data structures (and their associated contents buffers) in an intermediate step between the next time new tick function goes off. This buffer comes with some additional overhead in the form of a simple linked list defined statically in the new header file implementation. When the new live logging tick feature gets triggered in the main loop, if there is data in the logging buffer that needs to get sent over the serial USB, we loop over all the list entries clearing the terminal buffer with the new Terminal.h command TerminalFlushBuffer(void) (before and after transmission of the log data). This ensures that no data sent back over the serial USB from the Chameleon terminal execution gets inadvertently interspersed with logging data (as described in the problem above). It also makes sure that the terminal buffer is completely cleared/flushed by the time any logs get transferred over the serial connection. Easy enough.
Testing to verify bug fixes
I have run some preliminary tests. The following screenshots illustrate that the LIVE logging feature works as intended with the CMLD application I use for testing:
Summary
The brief features added in this pull request (PR) are a preview of some of the modifications I have made in my firmware mod to support DESFire tag emulation. The bugs that this PR fixes have already been pointed out by @ceres-c in issue #276. There is also a slight modification to the LUFA config file
LUFAConfig.h, which will eventually be needed to support the DESFire emulation (whenever that code is eventually ready). A fewMakefilecompiler flags have been tweaked, though nothing too substantially at this point.The
LOGMODE=LIVEfeature, despite being a favorite method of mine to get immediate NFC data with the Chameleon devices and the reason I created my logger app for Android, seems to be underutilized by users. This is evident since there have not yet been bug fixes to correct for the common error that the new fileLiveLogTick.h(included byLog.c) solves. Basically, the logging functionality onboard the RevG devices gets called in the application tick functions that run a given tag emulation specified byCONFIG=<NAME>. This causes a problem sometimes when semi-asynchronous calls to other serial USB transfer commands execute or overlap with these calls. When this seems to happen, the output over serial USB logged by my app, or say by aminicomsession, can either get jumbled or concatenated. My app, for example, expects the log type header data to be at the start of a data buffer transferred over serial USB. The fix for the observed bug with LIVE logging improves the stability of things quite a bit.The fix involves delaying writing data by logging commands
LogEntry(...)until a separate tick function is executed, approximately every 3 * 100ms. In the meantime, since LIVE logging does not utilize theLogMembuffer usually reserved forLOGMODE=MEMORYsettings for logging, we re-use this buffer to store the logging data structures (and their associated contents buffers) in an intermediate step between the next time new tick function goes off. This buffer comes with some additional overhead in the form of a simple linked list defined statically in the new header file implementation. When the new live logging tick feature gets triggered in the main loop, if there is data in the logging buffer that needs to get sent over the serial USB, we loop over all the list entries clearing the terminal buffer with the newTerminal.hcommandTerminalFlushBuffer(void)(before and after transmission of the log data). This ensures that no data sent back over the serial USB from the Chameleon terminal execution gets inadvertently interspersed with logging data (as described in the problem above). It also makes sure that the terminal buffer is completely cleared/flushed by the time any logs get transferred over the serial connection. Easy enough.Testing to verify bug fixes
I have run some preliminary tests. The following screenshots illustrate that the LIVE logging feature works as intended with the CMLD application I use for testing: