I am currently working on a project to implement the majority of MiFare DESFire into an Arduino UNO R3 utilizing the PN532 Shield and the Adafruit PN532 I2C library as a base for my work. I have been successful in authenticating to the card and performing some rudimentary tasks but I have encountered an issue when attempting to change the master encryption key used on the card.
Like all of the mifare classic commands already existing in the library, I make use of the pn532_packetbuffer to hold my command packet before executing sendCommandCheckAck, passing the buffer and the size of the packet as parameters. So far, most of my packets have been relatively small, at most 12 bytes, and have functioned perfectly. However, in order to change the encryption key on the DESFire card, I must send 26 bytes of data to the card directly, and adding the additional 2 bytes for the PN532 InDataExchange Command and the logical PICC number means my packetbuffer will contain 28 bytes.
Currently the code looks as follows:
Code: Select all
uint8_t Adafruit_NFCShield_I2C::mifaredesfire_ChangeKey(uint8_t keynum, uint8_t* enc_keydata, uint8_t keydatalen) {
pn532_packetbuffer[0] = PN532_COMMAND_INDATAEXCHANGE;
pn532_packetbuffer[1] = 0x01; //Select 1st logical card.
pn532_packetbuffer[2] = DESFIRE_CMD_CHANGE_KEY; //0xC4
pn532_packetbuffer[3] = 0x00; //Key number, for testing will only use the first key
memcpy(pn532_packetbuffer+4, enc_keydata, keydatalen); //incoming key data length is always 24 right now.
if(! sendCommandCheckAck(pn532_packetbuffer, 4+keydatalen)) {
return 0;
}
delay(500);
wirereaddata(pn532_packetbuffer, 32);
Serial.print("Reply from key change");
Adafruit_NFCShield_I2C::PrintHex(pn532_packetbuffer, 32);
return 1;
}
I understand this is way outside the scope of the provided libraries but I'm a bit puzzled as to why it is behaving this way, and any help would be much appreciated.
EDIT 2: Might this have something to do with the I2C frame limit of 32 bytes? I'm not particularly familiar with how this is handled though. Is a frame considered to be all data sent between beginning transmission and ending? If so, I guess it makes sense that the reader does not reply since there would be checksum information likely missing and the postamble. If this is the case, how might I solve this? Is there some form of chaining mechanism for I2C frames?