One possible explanation is that the default application, pre-programmed into the flash of a Connect module is based NET+OS 6.0. You are loading an application based on 6.3, which knows ho to convert a 6.0 NVRAM params structure into a 6.3 version. Once converted the 6.3 application, unless APP_USE_NVRAM (re: appconf.h) is set to 0, writes the converted params to NVRAM. Because the 6.3 application has not been written to flash, if/when the module reboots the 6.0 application is executed and because 6.0 does not know how to convert a 6.3 params structure the application will reset the unit to defaults.
Solution: build and load a 6.3 applicaiton, perhaps nafptapp, and load the image.bin file into flash, thus eliminating the need for the application to convert the NVRAM data.
I certainly do see this as well. To date I have not found any way in which to change the size of the GDBTK window, as a default. Resizing has been the solution, thus far. I can tell you that our next release of NET+OS, version 7.0, will ship with an a Eclipse based development IDE, entitle Digi ESP. No more GDBTK, easier to use, etc. Based on previous experience with graphical UI development , this problem would seem to be a repainting issue. One would have to get the GDBTK source and debug it.
It is best to exit and rerun GDBTK, there is no other solution for this issue. Digi ESP (NET+OS 7.0) will not have this problem loading and reloading an application, via the debugger, without restarting the IDE, is possible.
I have looked into this issue, as well. I have not come across any setting which can disable this. The best one could do, at this point, would be to edit the gsbtk.ini (stored in your $HOME directory, and delete he contents of the [session] section.
NET+OS 7.0 has been released and is currently shipping in our ConnectCore Wi-9C development kits. Any customer interested in obtaining a copy of NET+OS 7.0 should contact Digi support (see the phone/e-mail information below) or your Digi Sales representative. First, however, I encourage you to continue reading the remainder of this post.
To answer your question:
Are there going to possible challenges in porting a pre-7.0 application to 7.0, most certainly. The amount of effort will depend, entirely, upon the individual application being ported.
As an example, I have just completed porting the Digi Weather Station Demo from 6.0 to 6.3 & 7.0. Porting the application from 6.0 to 6.3 was mostly an exercise in eliminating all of those errors and warnings generated when one fails to prototype a function, declares a variable that is never uses, etc. The effort in porting from 6.3 to 7.0 took me about 6 hours. This will most certainly vary depending on the complexity of the application and whether one has made special modifications to the BSP. The time it took me to port this application is certainly not an accurate gauge of how long your effort may be; the APIs in use, amount of modification to the BSP, etc. will have be factors.
There have been a number of APIs that have been deprecated and subsequently superceded. Some APIs have simply been removed. The attached WhatsNew.txt file (shipped with 7.0) provides additional information regarding these changes.
At this present time 7.0 is primarily focused on new development opportunities, specifically in respects to the ConnectCore Wi-9C. This is, by no means, to say that current development kit customer are not welcome to upgrade. We want to control the availabilty of 7.0, however, so that there is an clear opportunity for us to make you aware of the potential challenges involved.
So we just call to get the new IDE, etc. - it works with the existing JTAG hardware and dev boards?
I think I will have to ping my rep, as I’ve just started my development and the only porting issues I see from the whatsnew.txt are some minor changes to sockets. I gather the FLASH file system, FTP server, etc. didn’t change?
How about the stability of the new TCP stack? I gather it was changed to support IPV6…