Recently, I received a batch of Connect ME 9210 modules and these modules are factory loaded with a NET+OS 7.6 firmware image. This is causing a problem because I am programming the modules with NET+OS 7.4 firmware. After programming the 9210 modules, the module comes up with the default MAC address. It appears that the NVRAM structure of NET+OS 7.6 is different than NET+OS 7.4. Therefore, the NET+OS 7.4 firmware cannot restore the NVRAM structure (because it has no knowledge of the new NET+OS structure) and must resort to using the default MAC address.
I would like to ask Digi to stop loading the Connect ME 9210 modules with the latest NET+OS versions, because it is not compatible with older NET+OS versions. Please factory load the 9210 with the older NET+OS versions to maintain compatibility, as Digi had been doing until recently.
I have just spent the afternoon loading the manufacturing image into a connectme9210 and then, starting from this basis, loading images from V7.5.2.2 and back adn forth form V7.6.0.2 to V7.5.2.2. After seeing your massage, I got my module back to the V7.6.0.2 image and rom.bin and tried loading a 7.4.2 image.bin.
The problem I am having is that I can’t get any of these configurations to fail.
Now, I am NOT suggesting that you are not running into a problem. On the contrary, I am trying to understand what is going on in a effort to get it fixed.
So:
When your modules come up for the first time (assuming you have access to the serial dialog) what version is displayed at the top? I need the exact version including all digits and periods contained therein.
When you then load your V7.4 image, what version is displayed at the top. Again I need the exact nomenclature.
What process do you use to “program” the modules? ftp from the command line, ftp from a GUI (such as filezilla) please specify, netosprog, some other method. Please be as exact as possible.
Also what are you loading into the module? image.bin (the application), rom.bin (the bootloader) or both?
There is no serial dialog. According to the FTP greeting, the factory image is NET+OS 7.6.0.3. After loading my firmware image, the FTP greeting displays NET+OS 7.4.2.
I program the modules using FTP via windows command prompt. I enter the username “root”, password “password”. Then I type “bin” for binary transfer mode. Then I type “put rom.bin”. Once the transfer is complete, I type “quit” and the module restarts on its own with the new firmware image.
The image is a combined image of the rom (padded to 64k) and application image.
Can you answer this question: Is the NET+OS 7.6 NVRAM structure different than the NET+OS 7.4 NVRAM structure? I am attempting to debug the issue, and it appears that the checksum does not match the computed checksum.
Hello
I do not believe the size of NVRAM changed but I believe we combined a few unused fields to make a user data area.
Why are you loading a rom.bin? Do you have your own modified one?
The reason I ask, I was wondering if you could load rom.bin and image.bin seperately. That is using ftp load rom.bin. Let the board reboot and then load image.bin (also using ftp). Does the MAC address still get crunched.
The reason I ask is that I regularly upload images but I do it seperately. So I am trying to rule out whether combining them has any bearing on this issue.
Just to clarify some things, when I refer to the NVRAM structure, I really mean the devBoardParamsType structure.
My rom.bin is a combined image of the rom and application image. My rom (bootloader) is customized. I can load the rom.bin (bootloader only) separately and it does not change the MAC address because it never calls customizeReadDevBoardParams(). It’s only in the application image that I call customizeReadDevBoardParams(), which checks the devBoardParamsType structure.
The problem is fixed. The NET+OS 7.6.0.3 NVRAM structure is larger than the NET+OS 7.4.2 structure. So when customizeReadDevBoardParams() gets called, the NVRAM recovery algorithm gets executed. I had previously disabled the boardParams.c computeChecksumFromSize() condition in fear that future NVRAM structures may not be truly backward compatible (if the fields had moved to different offsets). Most of this fear was due to my earlier days of working with NET+OS 6.x and NET+OS 7.x, as the NET+OS 7.x NVRAM structure was not compatible with NET+OS 6.x. If you were to load a NET+OS 6.x image onto NET+OS 7.x, the NET+OS 6.x would not be able to recover crucial NVRAM settings. However, it’s generally accepted that newer NVRAM structures will be an extension of the current structure. After re-enabling the check, my NET+OS 7.4.2 image can recover the NVRAM settings from NET+OS 7.6.0.3.