Closed DominusDRR closed 1 year ago
Hello @DominusDRR !
This notification can be triggered because VEN switches back to a voltage level higher than 1.1V
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.
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:
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
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.
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.
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]
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
And approximately in 4 ms above the notification (The image is in two parts since the frame is very long)
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
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).
Where 0xB1 0xAB 0x20 0x00, would be the program counter where said assert has occurred
Is this something serious, something good, something unimportant?