I’m messing with ST25DV16 NFC/I2C EEPROM. The new hex view is so nice I want to use it all the time. Initially I dumped by pretending it’s a 24x32 EEPROM, but that doesn’t give access to everything in the chip.
I tried the current dump command, which just does multiple reads in the current mode and saves them to a file. It seems like there’s a timeout in this chip though, I only read back 0xff with the dump command.
This led to two thoughts: build out a more intricate dump command, and add the hex viewer to the syntax display of RX/TX bytes when length > 4 or 6 or 8.
An I2C dump command could be pretty universal and follow the EEPROM command framework.
dump -i <i2c 7 bit address> -w <width of address register> -a <register address> -b <bytes> -f <file>
This would cover dumping any I2C EEPROM (at least a single page) and the registers of most I2C devices.
It could be a more generic command like i2c with dump/read/write options.
Then the other thing that might be nice: showing RX/TX in the hex viewer when the length is above a certain number of bytes. This will take some rework of the syntax post processor, which is needed, but not a super high priority at the moment.
I remember trying to find specs on how to encode Type 5 tags … the specifications for RFID are all over the place.
Is something like the following helpful?
Specifically, starting at section 3.2, which defines the NDEF record layout. See also section 2.3.3, which defines how to handle chunked payloads.
Yes, it’s a painful mess of variable-length structures whose existence is defined by prior bitfields. Good for packing the data, terrible for decoder complexity (and thus bugs and security issues abound).
For the TypeNameFormat (least significant three bits of that first byte), the specification above doesn’t list all the options. There’s also … flexibility, such that major OS (iOS, Android) prefer URLs encoded differently.
Even after understanding the basic format, this is a deep rabbit hole … compatibility and actually implemented decoding. Hope this helps you get started!
Thank you, that’s exactly what I was looking for! It’s a good outline and now I know what the bytes represent and it gives me what I need to hunt down what the values mean. A lot of the defs can probably be pulled from STMs library
(ndeftools) ...:~/ndeftools$ echo "91010B5402656E7265636F7264203111010C5402656E7265636F726420313111010D5402656E7265636F72642031313151010E55046275737069726174652E636F6D" | xxd -r -p | ndeftool print
Reading data from standard input
NDEF Text Record ID '' Text 'record 1' Language 'en' Encoding 'UTF-8'
NDEF Text Record ID '' Text 'record 11' Language 'en' Encoding 'UTF-8'
NDEF Text Record ID '' Text 'record 111' Language 'en' Encoding 'UTF-8'
NDEF Uri Record ID '' Resource 'https://buspirate.com'
Setting up `ndeftool`
# create a virtual environment using built-in venv
python3 -m venv ndeftools
# change into that directory
cd ndeftools/
# activate the venv
source bin/activate
# install ndeftool library
pip install ndeftool
# Crud ... it needs input in binary from stdin
# ... no hex string parsing.
# ... xxd to the rescue ... again ...
#
# -r option decodes the hex string into bytes
# -p option outputs plain (binary in this case)
echo "4142430A" | xxd -r -p
Encoding a URI using `ndeftool` Python library
(ndeftools) ...> ndeftool uri 'https://buspirate.com' | xxd -p
d1010e55046275737069726174652e636f6d
(ndeftools) ...> ndeftool uri 'http://buspirate.com' | xxd -p
d1010e55036275737069726174652e636f6d
Note there’s only a one-bit difference between http and https … because those options are defined in the uri record type.
