Hi,
I am evaluating an PN7150 dongle for possible future use. I compiled the code in Visual Studio, and ran into these issues:
1) When starting the application the first time, it seems to communicate well with the dongle. However, if I quit/stop the application, and restart it, it will hang forever. I have to pull out and reinsert the dongle in order to make it talk again. My guess is that this may be caused by the onboard MCU or I2C going into some state, and doesn't reset. Note that I get this issue with the precompiled NXP-NCI_Windows_example.exe that follows the example zip package.
2) The library/API itself leaks memory. That is, several alloc()'ed objects never gets free()'d. For example, I tracked this one down in tml_hid.c:
void tml_hid_Disconnect(void){
/* I2C_Reset(mDriverHandle);
I2C_CancelAllRequest(mDriverHandle);
I2C_Close(mDriverHandle);
Sleep(2000);*/
}
For some reason those I2C-functions are commented away, which will prevent several memory chunks to be free'd.
Is this code meant to be used in production, or is there some other SDK or library avaliable ? If not, I will have to clean this up or write new code from scratch.
- Oyvind
Thanks jeremygeslin. After testing the code I see that the issue upon restarting the application seems solved (hang reported by oyvindi). However, it still doesn't correctly addresses resets of the device. When plugging the dongle out and back in - the library continues to wait for discovery, and the only way to overcome it is to restart the application.
The cleanup code is till commented (in tml_hid_Disconnect()), hence not sure if the cleanup is done correctly.
The problem still exists with the modified example above. The dongle hangs after a few restarts, especially when waiting for 20 - 30s between shutdown and restart. Only unplugging and re-plugging helps. I ran the exe from the zip for testing.
Any chance that NXP investigates and fixes the bug?
Thanks,
Peter
Same problem here, did you find any solution?
No, unfortunately not
I've tried to build an updated firmware for the dongle based on the LPCSIO example form LPCOpen for LPC11U68. While I was able to connect, the same problem still exists.
As others have already reported, the problem doesn't exist with Linux hosts. The next thing that comes to mind is capturing USB traffic and comparing Linux vs. Windows, but I don't have experience with reverse engineering USB traffic.
I confirm the current software implementation doesn't support hot unplug/replug of the USB dongle.
We don't have any plan to update the library in order to support this.
However, in case it could help, please find attached fix for the detection of USB dongle removal leading to kill the running application. Then with appropriate batch file (also provided as example) you can manage restarting the application when the device is back.
There's a lot of code in the library - not easy to identify the API vs the driver, which makes it hard to integrate the code into other application.
There are still leaks in this application, and possibly also memory corruption. The elaborate use of statics and infinite waits essentially hangs and not clean up correctly, practical allowing to use it only as standalone application restarted each time a device is switched on or off or plugged back in.
I'm seeing the same issue.
Any other alternative for an API to the dongle ?
We have issue on the code, on the elektronika web sites is wrote that this dongle is capable to write,read tag, and p2p communication, but no support from MIKROELEKTRONIKA, no support from NXP that say try with forum, not found any documentation for programming and the sample is'nt usable. I require if any people can help us to edit the sample or to have documentation. All vendor have an sdk, NXP don't^?????