I was finally able to get this pairing to work. A clue that helped me was getting the LPC824 example working, which didn't work unless I had the board directly mounted on top (no extra cable length attached between boards), which seems like a drive strength issue for the MCUXpresso boards.
Understanding that, I reconfigure my MCXN Xpresso board to have the same pinout that aligns with the arduino headers that connect to the OM27160A1EVK. Once I did that, I placed the OM27160A1EVK board directly on top of the Xpresso board using J1 through J4. I then, just soldered pins on top of the OM27160A1EVK I2C and IRQ signals to probe with a logic analyzer.
Another caveat that I noticed is that the program only seems to work when debug output (NCI_DEBUG) is enabled. For some reason, a time delay is needed between a buffer read and when it is being accessed for comparison. Otherwise, I get failures when the NCI library is comparing the received data to the expected response bytes. My assumption is that the debug adds extra time between read/write and buffer access, allowing the buffer to make the correct data available in memory.
The specific design that I'm working on should be tolerant of a small delay in reads, but this seems like a flaw for the MCXN236.
I was finally able to get this pairing to work. A clue that helped me was getting the LPC824 example working, which didn't work unless I had the board directly mounted on top (no extra cable length attached between boards), which seems like a drive strength issue for the MCUXpresso boards.
Understanding that, I reconfigure my MCXN Xpresso board to have the same pinout that aligns with the arduino headers that connect to the OM27160A1EVK. Once I did that, I placed the OM27160A1EVK board directly on top of the Xpresso board using J1 through J4. I then, just soldered pins on top of the OM27160A1EVK I2C and IRQ signals to probe with a logic analyzer.
Another caveat that I noticed is that the program only seems to work when debug output (NCI_DEBUG) is enabled. For some reason, a time delay is needed between a buffer read and when it is being accessed for comparison. Otherwise, I get failures when the NCI library is comparing the received data to the expected response bytes. My assumption is that the debug adds extra time between read/write and buffer access, allowing the buffer to make the correct data available in memory.
The specific design that I'm working on should be tolerant of a small delay in reads, but this seems like a flaw for the MCXN236.
@KaiLi ,
In the case when it starts discovery and then enters an infinity loop, I see that the SCL and SDA lines get out of sync and there is a repeated pattern of read 0x7F with NACK
This screenshot above shows the bursts of data that occurs in the infinite loop in ~500ms intervals.
This screenshot above shows the repeated ~15ms burst of data that occurs every ~500ms.
Screenshot above shows the data within that burst in a zoomed in view. It also shows SDA and SCL getting out of sync and the IRQ signal toggling.
Thanks for sharing the expected data from the example. I was able to modify the TML file enough to confirm the results of the NxpNci_CheckDevPres() function. I seem to get that data back fine, but then fail on the next command of NxpNci_HostTransceive(). It returns with no data. Initially, I thought that I needed a longer wait period for the data to be ready and IRQ to generate, but the IRQ signal remains low indefinitely after sending the NCICoreInit_2_0 (0x20, 0x01, 0x02, 0x00, 0x00) command.
Also, sometimes I notice that the data seems buffered or delayed from the PN7160. This seems to occur when the system comes up with the IRQ already high. I expect that the reset toggle on the VEN pin should set the IRQ back low, but it doesn't always do so.
Here is the data transaction that I'm getting.
I have to note here that I had to modify the tml_Receive() function to get this to work this far. And the system still only seems to work when using non-blocking I2C transfer functions.
Here's the code snippet for the receive function that I modified:
void tml_Receive(uint8_t *pBuffer, uint16_t BufferLen, uint16_t *pBytes, uint16_t timeout) {
PRINTF("\n\r*** New Read Triggered! ***\n\r");
//clear out buffer
memset(pBuffer,0x00,BufferLen*sizeof(uint8_t));
//Sleep(300);
tml_WaitForRx(timeout*10); //currently discarding error
Status ret = tml_Rx(pBuffer, BufferLen, pBytes);
PRINTF("\n\rtml_Rx status: %i, buffer length: %i\n\r", ret, *pBytes);
PRINT_BUF("\n\r***Current Buffer Content: ", pBuffer, *pBytes);
if ((GPIO_PinRead(BOARD_NXPNCI_IRQ_GPIO, BOARD_NXPNCI_IRQ_PIN) == 1)) {
PRINTF("\n\r*** IRQ still asserted! More data to read... ***\n\r");
PRINT_BUF("\n\r**BEFORE RETRY*** NCI << ", pBuffer, *pBytes);
if (ret == SUCCESS) {
PRINTF("\n\r*** Attempting to read remaining data. ***\n\r");
if(INTF_READ(&pBuffer[*pBytes], pBuffer[2]) == kStatus_Success)
{
*pBytes = *pBytes + ((pBuffer[2] + 3) - *pBytes);
}
else
{
PRINTF("\n\r*** Failed to read additional bytes ***\n\r");
}
}
else {
PRINTF("\n\r*** tml_Rx Failed initial read. Attempting to retry read with INTF_READ. ***\n\r");
if(INTF_READ(&pBuffer[*pBytes], pBuffer[2]) == kStatus_Success)
{
*pBytes = pBuffer[2] + 3;
}
else
{
PRINTF("\n\r*** Failed to read additional bytes ***\n\r");
}
}
PRINT_BUF("**AFTER RETRY*** NCI << ", pBuffer, *pBytes);
}
PRINTF("\n\rtml_Rx status: %i, buffer length: %i\n\r", ret, *pBytes);
PRINT_BUF("\n\r***Current Buffer Content: ", pBuffer, *pBytes);
}
Please also see log attached with some debug output.
Here's an updated, formatted image of the code snippet.
Hello @KaiLi,
Thanks for the quick reply. I understand that there is an issue with the I2C communication. I just can't figure out what exactly is wrong. I've switch from using FLEXIO_I2C to use LPI2C via LP_Flexcomm, but I get the same results. When using the blocking transfer function, transmission aborts due to shifter error status flags. When using nonblocking transfer functions, I can see the data being transmitted out, but I get no reply form the PN7160.
I see that the data being transmitted is being acknowledged by the PN7160 device, but I'm not getting a response when trying to receive. The User Manual documentation for PN7160 says to wait for the IRQ pin to go high before requesting data. I see it go high, but it's in the middle of the data transfer. There is a function tml_Rx() in the NXPNCI Library that waits for this pin to go high but fails due to timeout. The pin only remains high for about 160ns, and seems to coincide with a glitch in the clock signal. So, the function aborts before attempting to read due to missing the interrupt. This occurs while sending the NCICoreReset command. Is this command expected to return any data?
Also, I assume that the fact that I'm getting ACKs back from the PN7160 means that it's alive, but how do I confirm that it's not in standby mode? I read that if the device is in standby mode, it will not respond
Here is the data that I've captured on a logic analyzer using the non-blocking transfer functions:
I realized that I didn't have the logic analyzer grounded. So, once I sync'd the grounds, I no longer see the glitch. So, I'm back to seeing data transmitted with ACK on each byte, but no IRQ or data generated by the PN7160.
So, my question still stands on how to ensure that the PN7160 is not in standby mode.
Feedback on the OM27160 devkit: It would be nice to have some LEDs to know status of the HW (i.e. RX/TX data being received/sent and an indicator for standby vs active mode). Right now, there is no way to tell what mode it's in and the WUP_REQ pin that is suggested for forcing the PN7160 out of standby is a NC according to the schematics.
