Home/Support/Support Forum/Problems with image executing after upgrade from NET+OS 7.1 to NET+OS 7.4.2
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.

Problems with image executing after upgrade from NET+OS 7.1 to NET+OS 7.4.2

0 votes
I'm working with a DIGI Connect Me -C module and I recently upgraded my application from net+os 7.1 to 7.4.2 and it works fine when debugging on a development board from ram, but when I flashed the boot loader and image on my unit it failed to boot. All output indicated a successful download and flash write. I am wondering if there are any issues with loading both the image and boot loader as a combined ROM.bin image the first time or if I've missed something in the configuration. I know similar questions have already been asked, but I don't seem to have any issues with the flash mapping as indicated by some of the questions I've read and I would like to avoid bricking another unit. I did notice that the boot loader was moved to the top of ram in this version. Below is my size and mapping information.

Compressing image.uncompressed to image.compressed
Using LZSS Encoder/Decode (v2)

Input bytes: 1951728
Output bytes: 1113422
Compression ratio: 43%

Compressing blram.bin to blramzip.bin
Using LZSS Encoder/Decode (v2)

Input bytes: 73616
Output bytes: 37945
Compression ratio: 49%

blbootldr.dat

WriteToFlash Yes
Compressed Yes
ExecuteFromRom No
flashOffset 0x0
ramAddress 0x204000
BypassCrcCheck No
BackupAddress 0x2130000

bootldr.dat

WriteToFlash Yes
Compressed Yes
ExecuteFromRom No
flashOffset 0x10000
ramAddress 0x8004000
MaxFileSize 0x1e0000
BypassCrcCheck No
BackupAddress 0x21a4000(not using backup image).


in customize.ldr:

RAM_SIZE 8M
FLASH_START 0x2000000
FLASH_SIZE 2M
MAX_CODE_SIZE 2M
BOOTLOADER_SIZE_IN_FLASH 128K
NVRAM_FLASH_SIZE 64K
BACKUP_RECOVERY_MAX_SIZE_IN_FLASH 0
FILE_SYSTEM_SIZE 256K
APP_MAX_SIZE_IN_FLASH 1552K
SIZE_OF_BOOTLOADER_RAM_IMAGE 1M
APP_START_OFFSET_IN_FLASH 128K
BOOTLOADER_CODE_START 8M - 1M
BOOTLOADER_CODE_END (BOOTLOADER_CODE_START + SIZE_OF_BOOTLOADER_RAM_IMAGE)
related to an answer for: Digi Connect ME doesn't boot after flash
asked Jul 15, 2016 in NET+OS by cityvic New to the Community (2 points)

Please log in or register to answer this question.

1 Answer

0 votes
7.1 is old and 7.4.2 is old too, you should be on 7.5.2
and you have to ftp rom.bin than reboot, then image.bin
please make sure you are using latest version of 7.5.2 with all the updates. Try it on unit with JTAG first.
answered Jul 16, 2016 by LeonidM Veteran of the Digi Community (4,072 points)
I understand 7.4.2 is not the very latest, but it's all I have at the moment. My only purpose for upgrading is to hopefully address Issues with Ethernet lock ups due to transmit underruns or late collisions. Loading image.bin and rom.bin as a combined image worked fine for me on 7.1 and I need to have it work that way on 7.4. Is there a need to load them separately?  My current application works fine on a jtag unit, but when I flash it on my none jtag unit it does not.
Netos 7.4.2 is 5 years old as netos 7.5 was released on 15 June 2011. It is very old and there could be some unaddressed ethernet stall issues with it as well. you can combine rob.bin and image.bin in to one image on any version of netos. The question is how are you combining them.
rom.bin has to be padded to take exactly 64K. and image.bin has to start exactly on a 64K boundary, unless your bootloader is bigger. The easiest way to get a working image is to program on JTAG module rom.bin , reset, program image.bin. then make sure you module boots, then use JTAG to dump module's flash in to file and use that file renaming it to rom.bin
Per your recommendation I went ahead and upgraded to 7.5.2. This version appears to be missing the basic web server API(libhttpd.a). Do you have any idea why this was removed?
it was deprecated. Most people use Advanced Web Server as it's much more feature reach and can do exactly the same task Basic web server can do and so much more. There is no point to maintain 2 web servers.
I agree there is no point in maintaining 2 web servers, but I currently do not have time to rewrite the application. My only interest is resolving the Ethernet lockup issue. I don't see any compatible API calls in the AWS for HSSend, etc.
...