@hwehbe
Hi Hussein,
I’m going to look into this reset function and see what I can find out for you
Can you let me know what the .dll you were looking for was
Thanks,
Tim
Hi Hussein,
Just to make sure when you were saying reset, did you mean a factory reset of the device or power cycling the device?
The DLL is HMSTPRTR.DLL, it is loaded from abcc_sys_adapt.c file line 477
make the device go back to initial state; so device reset
Hi Hussein,
After taking a look at this again, if you wanted to try and reset the application using the SDK I think you should be able to do this in APP_ProcResetRequest with the desired reset request as the arguement
These should also be useful places to look:
appl_eAbccHandlerState
APPL_RestartAbcc(),
APPL_Shutdown(), and
APPL_Reset()
Hi Tim,
the reset function melts down to function call ‘TP_ProviderSpecificCommand’ which is
TP_ProviderSpecificCommand = (TP_ProviderSpecificCommandType)GetProcAddress( locRouterDll, “TP_ProviderSpecificCommand” );
which is defined in HMSTPRTR.DLL.
Any info about this DLL?
Hi Hussein,
You’ll first want to make it so that the reset is allowed by the application. After that point you’d want to make it so that it’s issuing the ABP_RESET_POWER_ON
The Reset types can be seen here:
But the actual function that is going to be called is the APP_ProcResetRequest that will perform the reset. I can take a look and see what I can find out about the HMSTRPTR.DLL though
Hi Tim,
Thank you, wiatting for the dll. i went further with this issue, seems that the Anybus is not responding. I will elaborate more:
my host application is communicating with the module through the serial port of the module. My host send usb packages which converts to serial using ftdi chp and then fed to the anybus module. whenever i restart my application on my pc without power cycling the PCB poard which both, the ftdi and the anybus are setting on, the anybus stop responding. restart the application means closing the serial port on the ftdi and then starting it again. I am worried that the anybus has some time out or watchdog with expires and then it goes to exception state. I looked into object 1 instance 1 attribute 4 of anbus objects and i set it to zero but it didnt work. any idea?
Just to let you know, i did connect the reset pin on the module, and everything worked fine but the i thought about it and figured out that: using hard reset will bring down the network the module is setting on, it will solve my issue but it will creat a bigger issue. that is why iam looking to see why does my anybus module stop responding after restart of serial port.
Hi Hussein,
Here’s the response I got back from my colleague in Sweden:
“The HMSTPRTR.DLL is the interface DLL for the transport provider. When it receives a reset from the host application, it will send it via USB and make a hardware reset of the CompactCom. In his own implementation he must implement the functions ABCC_SYS_HWReset() and ABCC_SYS_HWReleaseReset() in abcc_adapt/abcc_sys_adapt.c. When that is done, the driver will take care of the reset.”
He was saying that it might not be a good idea to restart the serial port because it will be almost impossible to come back and communicate with the CompactCom without a new reset initialization afterward. Since you’re using the serial interface which uses a ping-pong protocol, the ping pong must continue even if there’s no change in data
Thank for your response, so helpful. Just one point to clarify; when u said the reset is sent via usb etc, how did the reset reached the module? the way i have it on my system is as follow: i have my ftdi chp with some pins that i donnt use in which i connected one of these pins to reset pin on the mosule and utilized it to gain reset control from host application. Please elaborate on the point of re-seting via usb!
Thank You
“when u said the reset is sent via usb etc, how did the reset reached the module?”
The starter kit has a micro-controller that accepts the transport provider commands which upon receipt of the reset request it toggles the appropriate GPIO that controls the M40s reset signal.
In your case you’re using an FTDI chip which isn’t going to be using the transport provider so when you receive the reset request from the application’s reset handler your application should make the appropriate API call to the FTDI to reset the CompactCom Via its GPIO interface