I changed to another PC and now I am getting this new error msg. I already re-installed the GHI METMF SDK but with the same result. Thanks for your support :think:
– Log –
Connecting to device…
Chipworkx found at Port#: COM3
Device will be updated automatically! DO NOT disconnect or turn off the device!
TinyBooterLoader.tcl was not found. Please re-install GHI NETMF SDK. Aborting…
Cannot update TinyBooter. Aborting…
I haven’t touched my chipworkx in a while. It is a good time to update. Let me see if i can reproduce it here.
(comment from an innocent bystander who has never seen a cwx device )
That to me seems like the folder the tinybooter file is in can’t be located.
I’ve just cracked open the update batch file. It assumes a few things.
First, the directory you run the script from should have a subdirectory called BIN where sam-ba is installed (this bit seems correct for you as I think sam-ba is whingeing about the missing tinybooter).
Second, the directory you run this from has to have the tinybooterloader.tcl file in it.
So this leads me to think you’ve copied parts of the updater but not all?
Can you tell us how you started the CMD prompt that you are using, or did you just double-click the batch file ?
Here’s how I would do this… (remember my earlier disclaimer 
)
open CMD prompt
CD
CD prog <hit TAB key to get right program files directory; mine is the “x86” one)
cd GHI
cd GHI
cd chi
cd fir
cd tin
DIR tiny*
… and check the tinybooterloader.tcl file exists
chip COM3
…and see what happens
Proman,
as I suggested before"Copy ChipworkX updater to the desktop then run it from there"
I already did it and the same error ???
So when you did that, what files did you take? The script itself assumes all those other things, make sure you copy the entire directory structure… or, try my option
PS: I’d suggest you go back to the “standard” way of dealing with this rather than the GUI updater; the complexities in file access across directories with and without admin rights may be whats throwing it astray.
I did it and neither works. I am getting this error msg:
“” bin \ sam-ba_cdc_2.9.xp VISTA.EXE “” not recognized as an internal or external command, program or batch file.
that error says you’ve not got all the files you need !
So, here goes. First up, are you on Windows 7, or earlier? x86 or x64? If you have x64 then your directory path is the same as mine - if not, then you don’t need the “(x86)” piece in the program files directory.
open your CMD prompt
do the instructions from me above, to the point where the DIR TINY* command is.
Then do a DIR, and paste the listing output into your reply. Here’s what mine shows:
C:\Program Files (x86)\GHI Electronics\GHI NETMF v4.1 SDK\ChipworkX\Firmware\Tin
yBooter Updater>dir
Volume in drive C has no label.
Volume Serial Number is AA5E-9B49
Directory of C:\Program Files (x86)\GHI Electronics\GHI NETMF v4.1 SDK\Chipwork
X\Firmware\TinyBooter Updater
01/10/11 10:08 PM <DIR> .
01/10/11 10:08 PM <DIR> ..
16/10/10 11:17 AM <DIR> bin
28/09/11 05:43 PM 2,642 ChipworkX_TinyBooter_Updater.bat
28/09/11 05:43 PM 2,101 logfile.log
28/09/11 05:43 PM 158,400 TinyBooterLoader.bin
28/09/11 05:43 PM 946 TinyBooterLoader.tcl
01/10/11 10:08 PM <DIR> USB Tinybooter Updater driver
4 File(s) 164,089 bytes
4 Dir(s) 17,184,919,552 bytes free
Then do a DIR /S, and paste the listing output into your reply. Here’s the end of mine:
Total Files Listed:
18 File(s) 2,756,972 bytes
26 Dir(s) 17,184,800,768 bytes free
Yours should be almost exactly the same ( only almost because I am using the SDK1.0.16 version, that has firmware 4.1.7.0 version, and I think 4.1.7.1 is out but i haven’t updated).
then do a DIR BIN\SAM* and check the output is something like this…
Directory of C:\Program Files (x86)\GHI Electronics\GHI NETMF v4.1 SDK\Chipwork
X\Firmware\TinyBooter Updater\bin
15/10/10 11:10 AM 2,273,410 sam-ba_cdc_2.9.xp_vista.exe
1 File(s) 2,273,410 bytes
0 Dir(s) 17,180,545,024 bytes free
that should show us you have what appears to be the right file-set available to you.
Next !
(feel free to ping me offline, email is in my profile)
Thanks Brett
It seems a file was missed in my directory. Thanks to your example I could solve it. 
Thanks a lot for your support!
pd. I could not find your email address in your profile
It’s me again with another problem… :wall:
My application is running but I need to change the IP parameters to the customer’s network. I change the IP to 192 168.23.230 MASK 255.255.248.0 and GATEWAY 192.168.23.254. As soon as I do this, my application does not start again and MFDeploy loses communication with the module. Is there any kind of IP addressing limitation?.. Should MAC address be programmed in MFDeploy? . Below the LCD msg showed after IP changes:
Chipworkx
version 4.0.3.0
Debug USB1
LCD: 480x272
IP 192.168.23.230
MAC: 00.01.02.03.04.05
Managed heap size: 59768832
Custom heap size: 1048576
You need a correct Mac address but not sure why you have problems.
First, I wonder if your program is still working, but you just can’t actually get a response via the network. Can you plug in a debug USB cable and prove the app is stoppped or not, as that will tell you the actual issue you need to take … How were you connecting to the device with MFDeploy when it stopped responding?
But I guess that your MAC address is the problem, the customer’s network is most likely treating that (invalid) MAC address as invalid and dropping it from the ARP table.
Have you considered maintaining the IP configuration via a config file (eg XML on SD card or some other way to allow you to change this at runtime without changing code or MFDeploying?
Is there any reason that you are using an old firmware?
Gus: As in MFDeploy chipworkX IP parameters are setup, the MAC here should be the MAC module?
Joe: We developed our solution based in this version and right now is working and stable. The upgrade is something we have to do in a near future.
Brett: The only connection I have is by USB. I download the firmware and our application ok. But when I change the IP parameters using MFDeploy the application does not start again and LCD remains in the state showed above. In this stage the communication with the module using MFDeploy is lost.
I remember a problem with configuration saving long time ago. The weird thing is that the problem show up only when using certain IP addresses. IP addresses with odd numbers as I remember.
Try the IP address on a blank chipwokrX (not application at all). try to ping it. if it did not work then update the firmware and set the same IP address and check if you see a difference.
I remember it as well. This was fixed in later update.
The MAC to setup in MFDeploy is the chipworkx mac…right?
yes, it is the device’s unique MAC