Checksum Fail

[SeeCwriter]

We are in the process of moving an application from the MOD5234 to the MOD5441X. Most of it is going pretty well, but there seems to be an issue with the number printf() statements used. If a lot of printf() statements are used in a function, the program will build without error but when it boots we get a "Error Checksum Fail". Reduce the number of printf()'s and the error goes away. We never saw this on the MOD5234. We are using NNDK v2.6.6.6. But, we just started using the current version. Prior to last week we were using whatever the current release was in 2009, v2.4.?.

Does this seem like a compiler bug or that the new compiler has revealed a latent bug in our application? I'm not sure what we can do but keep printf()'s down.

Steve

[dciliske]

Are you building with 2.6.6 or 2.6.7? 2.6.6 should not be used due to a major TCP bug. (My apologies about this). Do you have any other device connected to the FlexBus of the MOD5441X? A checksum failure is normally associated with the bootup sequence of the parallel flash not owning the bus. The MOD5234 would fail to boot at all in this instance, whereas the MOD5441X first boots into the monitor using a separate onboard serial flash.

I doubt that the printfs themselves are to blame, but possibly the overall flash size.

-Dan

[SeeCwriter]

Yes I was using v2.6.6. I wasn't aware of the problem. This may be the wrong place to post this, but I did download v2.6.7, and installed it after uninstalling v2.6.6. And when I tried to rebuild the system libraries, I get the following error:

c:\nburn\system>make clean
c:\nburn/make/root.mak:201: c:\nburn//make/ldflags.mak: No such file or directory
make: *** No rule to make target 'c:\nburn//make/ldflags.mak'. Stop.

Steve

[dciliske]

Hmm... somehow you don't have a default platform selected. That should not be possible to do... Try selecting a project with a platform selected for build then rebuilding the library. Worst comes to worst you can rebuild on the command line via:

Code: Select all

cd %NBROOT%\system
make clean
make debug
make

This is of course assuming a windows pc; if UNIX, switch the '\' for a '/'.

-Dan

[SeeCwriter]

I am on a Windows system, Win7. I did open the IDE, selected an example project, did a Clean, then a Build, and it all worked. Then I closed the IDE, opened a command prompt, navigated to C:\nburn\system and entered "make clean", I get the same error as before. My project uses SNMP so I need to rebuild the system libraries for that. But so far nada.

My co-worker is also having a heck of a time trying to get his program to run under v2.6.7. It runs fine when compiled with v2.4. He thinks there is an uninitialized pointer in the NB code. But I will start another thread for this issue.

Steve

[seulater]

I ran into this several times on a MOD5213. Sounds just like what you are describing.
I found that if I power the module down then backup that took care of it. Resetting it did not work, only a power cycle helped.

[SeeCwriter]

Regarding the makefile, the problem appears to be that no platform is being set in makefile root.mak when running on the c:\nburn\system directory. I'm not sure what the platform is supposed to be, but it appears that the value of DEFPLATFORM is not being initialized. Where does that parameter get set? Or maybe more importantly, why isn't it being initialized to a default state?

Steve

[SeeCwriter]

OK, I'm a little slow. DEFPLATFORM is an environment variable. It used to be set but somehow became unset. So I manually set it. "make clean" still failed, but for different reasons. Now I see that SNMP was not installed in v2.6.7. It gets installed with v2.6.6. So what gives? I have what I believe is a valid license. At least v2.6.6 and before thinks it's valid.

Steve

[dciliske]

um.. try reinstalling with the SNMP key? The only reason I can think that SNMP wouldn't be installed is if you didn't enter the key at install time.

[rnixon]

You need to include your keycodes for all the s/w you have. If you don't enter the keycode for snmp, then the system will not know to install it.

Regarding the printf issue, I would check all the items you are printing out. Maybe the ones that cause the issue are accessing external memory and there could be a timing issue or other h/w incompatibility in your design that is not an issue on the earlier module. As with all these types of things, the most important information is: exactly what printf and parameters cause the issue? Need to narrow it down by commenting them out and uncommenting a few at a time until you know which ones are the issue.