NetBurner Community Forum

Hello all,

I 've got a Nburn-version problem for my Mod5213 program.
Originally, the version i used to develop my mod5213 firmware is "rel20_rc_4 "; the compiled firmware s19 file size was 400Kbytes, and could run just as expected.
Later, i upgraded the Nburn to version "Rel22_rc2", then the compiled firmware size (s19) increased to 450kbytes. and the firmware could not run correctly and would get trapped just after several lines of code executed. And the trapping was not caused by any specific lines, I mean commenting out some lines does not prevent the trapping from happenning.

BTW, my program might use upto 90% of ram based on the compiling info provided by the Eclipse.

My question is why the old version Nburn can make a executable s19 file, but the new version does not?
Anybody can help? how can i fix the problem.

Thanks.

I dont know what sort of application you are running for me to provide
more useful insight into your program, but it seems to me you are just about running out of
useful available RAM and internal FLASH memory space that the compiler has allocated for you.
For my s19 webpage application and process control of appliances the Eclipse environment reports:-

Used 188088 bytes of 491520 available flash (38.27%)
Used 728976 bytes of 8388608 available ram (8.69%)
NNDK release tag version:Rel23_rc7a [try ugrading to this version]

These days there are more programmers out there who tend to be more sloppy writing their code, and waste
valuable resources (much like spending too long in the shower, wasting precious water )
I try to be more efficient with my code, to save RAM, FLASH etc... e.g. use short int instead of int for two bytes.
Use char if you are only using a one byte variable, instead of short int/int etc...
Large HTML type files or JPEG images for websites, I prefer to use the NetBurner EFFS file system to access from external FLASH such as MMC/SD card that comes with some development kits.

Kind regards

Paul

I think Pauls comments are good. I would like to add that the .s19 file does not tell you the amount of ram and flash used. A better measure would be to report the numbers from the compile showing the number of bytes for each.

Thanks, Paul:

I did realize that my code is big, and that may be the cause of the trapping of the S19 file compiled by the newer version Nburn.
I am not sure if I can reduce the RAM usage of my code though.
However, the s19 file compiled by the older verison of Nburn runs perfectly.

I wonder, the same source code compiled by the older version Nburn i get a 400KBYTES s19 file which runs perfectly,
but i get a 450KBYTES s19 file by the newer version Nburn which does not run at all?

Anybody knows?

Thanks.

linhm,

When you do a build, what appears in the compiler output window for flash and ram usage? What are the numbers in bytes and percentage?

The following is a portion of what displayed in the console screen after compiling.(with the new version Nburn, Rel22_rc2)
....
C:\Nburn\lib\NetBurner_nn.a -Wl,--end-group -oEMM620A-v100.elf
m68k-elf-objcopy -S -Osrec EMM620A-v100.elf EMM620A-v100.s19
packcode -R "EMM620A-v100.s19" EMM620A-v100_APP.s19 0xffc04000 0xFFC3E000 -PMOD5213
Block starts at ffc04010
Block ends at ffc296cc
Block size= 149K (153276bytes)
Execution starts at ffc04010
Code check sum = 77d8453e
Code CheckSum= 77d8453e
Struct CheckSum= 330fcea0
S records output with a base address of ffc04000
S records output with a final address of ffc296cc
About to write S7...About to report

******************************Build summary ******************************
Used 153292 bytes of 237568 availible flash (64.53%)
Used 28632 bytes of 31488 availible ram (90.93%)
NNDK release tag version:Rel22_rc2
Build complete for project EMM620A-v100


THANKS.

Based on those numbers you are not exceeding the flash/ram space. Your .s19 file size has nothing to do with ram space, only flash, and your only using a little over half.

If the app is crashing with a different version and compilation, it may be due to a bug in your app that was always there, but because of the way things were arranged in ram it was not overwriting anything important. Now it is. Thats just a guess. Maybe do a test and build/run one of the examples with no modifications. If those work,then the tool set is probably ok.

rnixon has made a good point.
The updated toolset (Rel22_rc2) that you are using is probably OK, although it is still older than the one I am currently using which is Rel23_rc7a. Clearly one would verify this by reFLASHing the original s19 that came with the Mod5213.

Interesting your comment about traps.
I found that the std itoa() function only converts integers to lowercase ASCiii, so I used the function toupper()
to convert two characters.

When I used this function initially it started generating traps, by my code writing of :-

myString=toupper(myString); // NOT OK -CAUSED TRAPS at runtime, after accepting a user keyboard input.

To get rid of the traps, I used these separate lines of code which in fact cured it.


myString[0] = toupper(myString[0]); //convert lowercase first byte to uppercase ASCII -OK

myString[1]= toupper(myString[1]); //convert lowercase 2nd byte uppercase ASCII -OK

My guess with your trapping problem that there perhaps might be a rogue parameter or something passed to a function
which the compiler is accepting and not reporting warnings, therefore your program is crashing during runtime.

Thanks for your replies.
But what about dynamic variables? I do have dynamic variables used in my code.
Since the compiler does not know how much dynamic memory needed at runtime, the program still can crash even though the compiling is successful. right?
And what about the stacks?

BTW, since my program needs too much RAM, the Debug version s19 won't build. : (

I'm only guessing that you are using an interactive web function for your application, that would use make use of dynamic variables?
This particular point I found has been emphasied in the last four paragraphs of page 37
in the NetBurner Network Development Programming Guide example programming code- Rev3.3 April 18 2008.

It explains exactly what to do when you make Function Calls tags in dynamic HTML webforms etc.. i.e..

1. Automatic variables which can gobble User data space if not kept in check! -Use a global variable in lieu of.

2. HTTP stack size

3. malloc & free

Hope this helps,

Kind regards

Paul
http://www.microwebserver.net