PN532 with ATMega uC

[codedawg82]

I'm trying to communicate with the PN532 breakout board (v1.3) via USART with an ATMega324PA uC. I've got the board set to UART with SEL0 off and SEL1 off and I've hooked up the FTDI portion's RXD-TXD to my ATMega USART0's TX-RX. I can see that I've powered the board successfully and I know that my TX-RX pins from my ATMega's USART are properly working as I've tested them with a custom RS232 module and a terminal program called "Termite". (If anyone needs a detailed schematic, I'll be happy to send it).

The conneciton for the PN532 requires115200 baud, 8N1, which is what I'm using for my Serial connection as well. From what I've read in the manual, http://www.adafruit.com/datasheets/pn532um.pdf when I send a Firmware command frame comprised of {0x00, 0xFF, 0x02, 0xFE, 0xD4, 0x02, 0x2A }, I get no response. Not sure why this happening. However, when I hold up a MiFare (included in the package) card and then remove it, I get response of 0x00. I'm inferring that the connection is working, but I'm not sending over the right message maybe?

My code is fairly simple and i'll spare the setups for the USART0 and USART1 connections---

Code: Select all

int main(void){
uart0_init();
uart1_init();
getFirmware(); // transmit msg for firmware to USART1 TX ---> to PN532 RX
while(1)
{
   recv_nfc_data = USART1_RX();    // receive data from PN532 TX through USART1 RX
   USART0_TX(recv_nfc_data);       // transmit recieved data to USART0 TX which is serial to PC connection
}

I do not know why I am getting no response for such a simple command frame. Can anyone help?

[adafruit_support_rick]

i'll spare the setups for the USART0 and USART1 connections---

Since this seems to be a serial comm problem, that's the most interesting part. Just provide the entire program.

What are you clocking the 324 at?

Also, please post detailed pictures of your wiring and any soldering you did.


Ah - I had a look at the datasheet, Your command frame lacks preamble and postamble bytes.

[codedawg82]

Here is the code I'm using... I will post wiring pics next. Using 0x00 for Preamble and Postamble still didnt make it work...

Code: Select all

#define MY_F_CPU 1843200UL
#define BAUD 115200
#define BAUD_NFC 115200
#define MYUBRR ((MY_F_CPU/(16UL*BAUD))-1)
#define MYUBRR_NFC ((MY_F_CPU/(16UL*BAUD_NFC))-1)

int main (void) {
DDRB |= (1<<PINB0);
      PORTB |= (1 << PINB0);

      //Setup IO pins and other defaults
      USART0_INIT();      // this goes out to the PC
      USART1_INIT();      // this goes out to the PN532 board
   
      uint8_t recv_data;
      uint8_t recv_nfc_data;

               char msg[] = { 0x00, 0x00, 0xFF, 0x02, 0xFE, 0xD4, 0x02, 0x2A, 0x00 };
      nfc_transmit(msg, sizeof(msg));
      
      while(1)
      {
         recv_nfc_data = USART1_RX();
         USART0_TX(recv_nfc_data);
                 }
}

void USART0_INIT(void) {

   // set baud rate
   UBRR0H = (MYUBRR>>8);
   UBRR0L = (MYUBRR);
   
   // Set Control and Status Register for USART0; No parity setting defaults to 0
   // 00 = Asynchronous USART (UMSELn)
   // Stop bit = 1 (USBSn)
   // Character size = 8-bit (UCSZn)
   // UCSR0A = (1<<U2X0);         // double the speed of transmission (U2Xn)
   UCSR0C = (1<<USBS0) | (1<<UCSZ00)| (1<<UCSZ01);

   // Enable Receiver and Transmitter
   UCSR0B = (1<<RXEN0) | (1<<TXEN0);
};

void USART0_TX(uint8_t myData) {
   // Wait if a byte is being transmitted
   while( !(UCSR0A & (1<<UDRE0)) );
   // Transmit data
   UDR0 = myData;
};

uint8_t USART0_RX(void) {
   // Wait until recv buffer is full
   while( !(UCSR0A & (1<<RXC0)) );
   // Return recvd data
   return UDR0;
};

void USART1_INIT(void) {

   // set baud rate
   UBRR1H = (uint8_t)(MYUBRR_NFC>>8);
   UBRR1L = (uint8_t)(MYUBRR_NFC);
   
   // Set Control and Status Register for USART0; No parity setting defaults to 0
   // 00 = Asynchronous USART (UMSELn)
   // Stop bit = 1 (USBSn)
   // double the speed of transmission (U2Xn)
   // Character size = 8-bit (UCSZn)
   // UCSR1A = (1<<U2X1);
   UCSR1C = (1<<USBS1) | (1<<UCSZ10)| (1<<UCSZ11);

   // Enable Receiver and Transmitter
   UCSR1B = (1<<RXEN1) | (1<<TXEN1);
};

void USART1_TX(uint8_t myData) {
   // Wait if a byte is being transmitted
   while( !(UCSR1A & (1<<UDRE1)) );
   // Transmit data
   UDR1 = myData;
};

uint8_t USART1_RX(void) {
   // Wait until recv buffer is full
   while( !(UCSR1A & (1<<RXC1)) );
   // Return recvd data
   return UDR1;
};

void nfc_transmit(char *byteStream, int length){
   uint8_t i;
   
   for (i = 0; i < length; i++){
      // USART0_TX(byteStream[i]);   // sends back to the serial port
      USART1_TX(byteStream[i]);
   }

}


[codedawg82]

Here you can see my connections using jumper cables and soddered male-pin headers on the pN532. I've checked these connections using my multi-meter and they are good.

UART Connections(2).jpg (226.06 KiB) Viewed 1054 times

Here you can see the selector pins, set to 00 and 00 for UART.

Mode Selector(2).jpg (211.57 KiB) Viewed 1054 times

Here you can see my connections to my ATMega324PA with Crystal of 14.7456 MHz --- the two black wires go out to the Crystal.
I've tested UART0 and UART1 with 115200 8N1 and they are working --- the test was conducted by hooking the Rx from one to the Tx of the other while UART0_TX is going to Serial connection.

Atmega Connections(2).jpg (191.15 KiB) Viewed 1054 times

[codedawg82]

In addition, I tried doing with the TX/RX pins that also have SPI as well, (aka MOSI/SOA/TX and SSEL/SCL/RX) and this still didnt return any results after sending the frame specified above. Is it possible to have a dud board?

[adafruit_support_rick]

I don't think your baud rate calculations are correct. Your MY_F_CPU constant is defined as 1.8432MHz, not 14.7456MHz. That gives you a UBRR value of 0. With U2X0 = 1, you should be using a UBRR value of 7

[ktownsend]

In addition, I tried doing with the TX/RX pins that also have SPI as well, (aka MOSI/SOA/TX and SSEL/SCL/RX) and this still didnt return any results after sending the frame specified above. Is it possible to have a dud board?

The boards are all tested before they go out, so it should be fine. It's almost certainly a SW problem, and there was a lot of effort that went into getting these chips working with the drivers. You might find some tips here on using the PN532 in UART mode: https://github.com/microbuilder/LPC1343 ... bus_uart.c ... or look at libnfc which also supports UART/HSU communication, but I'm guessing there are still some bugs to slay in your SW. Unfortunately, I can't really help myself for anything other than the supplied SPI or I2C-based drivers or on anything other than a generic Arduino since that's all I own other than ARM stuff.

[codedawg82]

I don't think your baud rate calculations are correct. Your MY_F_CPU constant is defined as 1.8432MHz, not 14.7456MHz. That gives you a UBRR value of 0. With U2X0 = 1, you should be using a UBRR value of 7

Thank you, I think after looking at this code and playing around with settings so much I was starting to lose track, but yes, this was an issue. However, it wasn't the main source of my problem because I know I had the serial connection working in the first place initially --- but again, good catch!

You might find some tips here on using the PN532 in UART mode: https://github.com/microbuilder/LPC1343 ... bus_uart.c ... or look at libnfc which also supports UART/HSU communication, but I'm guessing there are still some bugs to slay in your SW.

I think this was really what I was missing ---- In the page you linked to, there's a "pn532_bus_Wakeup(void)" method which sends a byte array called "abtWakeUp[]". This looks like a wakeup signal for the board???? I hadn't realized this was needed but I'm breaking it down here for anyone else exploring this route:

Code: Select all

{0x55,0x55,0x00,0x00,0x00, 0x00}    // Dummy Byte
{0x00,0xff,0x03,0xfd,0xd4,0x14,0x01,0x17,0x00}     // SAMConfiguration in Normal mode
{0x00,0xff,0x03,0xfd,0xd4,0x14,0x01,0x17,0x00}     // SAMConfiguration in Normal mode

The dummy byte can be sourced from the documentation in the section where it reads "HSU wake up condition.... Or send first a 0x55 dummy byte and wait for the waking up delay (Twake up time) before sending the command frame."