ElectronicCats / ElectronicCats-PN7150

Arduino library for I2C access to the PN7150 RFID/Near Field Communication chip
MIT License
33 stars 15 forks source link

Internal Assert issue #40

Closed DominusDRR closed 1 year ago

DominusDRR commented 2 years ago

Hi.

I've gotten to the StartDiscover function, in which I broadcast the following frame from the DH to the NFC:

0x21 0x03 0x09 0x04 0x00 0x01 0x02 0x01 0x01 0x01 0x06 0x01 (Star Discovery)

The NFC answers me appropriately:

0x41 0x03 0x01 0x00 (RF_DISCOVER_RSP)

After a moment I get a notice of CORE Reset:

0x60 0x00 0x06 0xA0 0x00 0xB1 0xAB 0x20 0x00

According to the datasheets, this happens because an internal assert has occurred (I don't really know what that is).

image

Where 0xB1 0xAB 0x20 0x00, would be the program counter where said assert has occurred

image

Is this something serious, something good, something unimportant?

Eric286 commented 2 years ago

Hello @DominusDRR !

This notification can be triggered because VEN switches back to a voltage level higher than 1.1V

image

The chip is reset when VEN is switched back to a voltage level higher than 1.1V and sends a notification with the CORE_RESET_NTF

"Is this something serious, something good, something unimportant?"

-It depends on whether this notification is useful to you or not, if not, it would be something unimportant.

PN7150 answers/notifications toward the host controller are asynchronous and they can be triggered by an external event (e.g. detection of a card in the RF field).

Have a nice day! Kind regards! Electronic Cats Support Team.

DominusDRR commented 2 years ago

Hello.

It seems to me that you are confusing the hardware reset with the software reset:

The soft reset y happens at the end of ConfigureSettings when the following frame is sent:

image

This problem is also reported on the NXP forum, but unlike my case, I get a correct response to the start discovery command and the bytes after 0xA0 are different.

https://community.nxp.com/t5/NFC/How-to-solve-NFC-PN7150-Internal-Assert-issue/m-p/1266795

Eric286 commented 2 years ago

Hello @DominusDRR!

You're right, I was confused about this.

CORE RESET NTF is only delivered by PN7150 in the event of an internal reboot caused by a code execution stalemate, a clock management problem, memory corruption, or an overheating condition.

DominusDRR commented 2 years ago

So far, I see this frame:

0x21 0x03 0x09 0x04 0x00 0x01 0x02 0x01 0x01 0x01 0x06 0x01

Which is equivalent to everything the StartDiscovery() function does.

It is what causes the problem.

Eric286 commented 2 years ago

Dear @DominusDRR!

0x21 0x03 0x09 0x04 0x00 0x01 0x02 0x01 0x01 0x01 0x06 0x01 it is a Control Packet - Command Message, and it is an RF DISCOVER CMD according to the NCI spec.

Please see the following for more information.

Configuration N° 1 RF Technology and Mode = {Std} NFC_A_PASSIVE_POLL_MODE [0x00] Discovery Frequency = RF Technology and Mode will be executed in every discovery period [0x01]

Configuration N° 2 RF Technology and Mode = {Std} NFC_F_PASSIVE_POLL_MODE [0x02] Discovery Frequency = RF Technology and Mode will be executed in every discovery period [0x01]

Configuration N° 3 RF Technology and Mode = {Std} NFC_B_PASSIVE_POLL_MODE [0x01] Discovery Frequency = RF Technology and Mode will be executed in every discovery period [0x01]

Configuration N° 4 RF Technology and Mode = {Std} NFC_15693_PASSIVE_POLL_MODE (RFU) [0x06] Discovery Frequency = RF Technology and Mode will be executed in every discovery period [0x01]

DominusDRR commented 2 years ago

Hi

I'm following the example called ISO14443-3A_read_block, where the mode is 1.

uint8_t mode = 1; // modes: 1 = Reader/ Writer

The problem occurs when Discovery Start is issued

nfc.StartDiscovery(mode); //NCI Discovery, mode = 0x01:

You get this answer

image

And approximately in 4 ms above the notification (The image is in two parts since the frame is very long)

image

DominusDRR commented 1 year ago

Hi

It seems that I discovered the error.

I began to analyze each one of the frames that the DH sends and the PN7150 responds until I reach the clock configuration (NXP_CLK_CONF)

I was configuring as PLL

uint8_t NxpNci_CLK_CONF[] = { 0x20, 0x02, 0x09, 0x02, /* CORE_SET_CONFIG_CMD */ 0xA0, 0x03, 0x01, 0x11, /* CLOCK_SEL_CFG */ 0xA0, 0x04, 0x01, 0x01 /* CLOCK_TO_CFG */ };

But my hardware uses a 27.12MHz crystal and the setting must be Xtal

uint8_t NxpNci_CLK_CONF[] = { 0x20, 0x02, 0x05, 0x01, /* CORE_SET_CONFIG_CMD */ 0xA0, 0x03, 0x01, 0x08 /* CLOCK_SEL_CFG */ };

I thought that this mistake was not going to solve the problem, but after correcting it and checking just in case the error was repeated, to my surprise, it works fine. It even responded to the first detection of the tag. (WaitForDiscoveryNotification

I continue with the tests of the rest of the code