Hi at all,
we're developing the firmware on board of the RCM3700 module using
the compiler Dynamic C ver.9.52.
The the program structure has become very complex,
we use a lot of structures both in RAM and in flash and use
intensely xmem area and root area,
the program is composed by 15000 lines codes, divided in 10 custom
library files.
and so at certain point (adding others structures) the compiler
seemed not to succeed in managing our code (before we hadn't any
problem).
In way entirely random we have run time errors (we haven't any
compiler messages like warnigs or errors) as the followings:
1. array index out of bounds.
2. xmem allocation fails.
3. Run Time Error : An RST 38 occurred, but the RST 38 vector is
uninitialized.
4.the printf function make "strange" (without sense) print in the
debug window.
5. the program restart himself without a logic.
6. Reading the MAP file, there are some functions that use too much
and wrong size.
and
The program counter doesn't follow the pre-arranged sequence of
istructions.
We tried to move some functions in root and others in xmem (putting
the the suffix xmem or root before the function's or variable's
name), the result has been that the errors appeared in others
program's points.
We tried to change RCM module too, but anything changed.
We tried to use others Dynamic C ver. (9.21, 9.50), but anything
chanded.
We would be very thankful if you could give us any suggestions, and
if you could tell us if all these problems can be depend on the
compiler, and in this case if there is another compiler that can
resolve them.
Thank you for you attention
big problem with Dynamic C compiler!
Started by ●June 19, 2007
Reply by ●June 19, 20072007-06-19
You have been suffering too long.
Go visit:
http://www.softools.com
Some conversion is necessary because it is ANSI-C, but it is worth it.
-Pete
Go visit:
http://www.softools.com
Some conversion is necessary because it is ANSI-C, but it is worth it.
-Pete
Reply by ●June 19, 20072007-06-19
On Jun 19, 2007, at 2:15 AM, neweidos wrote:
> The the program structure has become very complex,
> we use a lot of structures both in RAM and in flash and use
> intensely xmem area and root area,
Something that bit me on a recent project was related to indexing a
large block of data in xmem.
Typically, you use xmem2root and root2xmem to move records in and out
of xmem. I was calculating the address like this:
xmembase + index * sizeof(RECORD)
xmembase is a long, and index is a word. That's all well and good
until you're indexing into more than 64K of memory. The
multiplication is only 16-bit, and will overflow.
My solution was to change the multiplication to:
xmembase + (index + 0L) * sizeof(RECORD)
Adding a long constant to the word promotes it to 32-bit. I guess
you could also cast it using (long). I also took the opportunity to
write wrapper functions for copying records into and out of xmem, so
there weren't any places where the calculation would come out wrong.
--
Tom Collins - t...@tomlogic.com
Certified Rabbit Semiconductor Consultant based in Napa, California
Licensable PPP packet capture library: <http://tomlogic.com/rabbit/>
> The the program structure has become very complex,
> we use a lot of structures both in RAM and in flash and use
> intensely xmem area and root area,
Something that bit me on a recent project was related to indexing a
large block of data in xmem.
Typically, you use xmem2root and root2xmem to move records in and out
of xmem. I was calculating the address like this:
xmembase + index * sizeof(RECORD)
xmembase is a long, and index is a word. That's all well and good
until you're indexing into more than 64K of memory. The
multiplication is only 16-bit, and will overflow.
My solution was to change the multiplication to:
xmembase + (index + 0L) * sizeof(RECORD)
Adding a long constant to the word promotes it to 32-bit. I guess
you could also cast it using (long). I also took the opportunity to
write wrapper functions for copying records into and out of xmem, so
there weren't any places where the calculation would come out wrong.
--
Tom Collins - t...@tomlogic.com
Certified Rabbit Semiconductor Consultant based in Napa, California
Licensable PPP packet capture library: <http://tomlogic.com/rabbit/>
Reply by ●June 19, 20072007-06-19
I have to echo Pete's recommendation. My experience was the same -
once my project became more than just a handful of modules, it became
unmanageable and subject to strange (and seemingly
random) "anomalies" that were often a result of the arcane way that
you have to deal with files/projects/libs etc in DC. I moved to
softools and have had no problems since. The conversion efforts were
minimal and a lot less painful....
Good luck to you.
Mark
once my project became more than just a handful of modules, it became
unmanageable and subject to strange (and seemingly
random) "anomalies" that were often a result of the arcane way that
you have to deal with files/projects/libs etc in DC. I moved to
softools and have had no problems since. The conversion efforts were
minimal and a lot less painful....
Good luck to you.
Mark
Reply by ●June 19, 20072007-06-19
The errors suggest that you've corrupted a pointer somewhere. Maybe
you've
gone past the end of an array. No matter how good a new compiler is, it won't
solve that problem. And moving to another compiler because some changes
to your code caused errors to show up seems a very rash move.
I suggest rolling back the changes that were made until you get to the point that
you can run without errors. Then selectively add back your changes to find what
caused the problem.
Steve
gone past the end of an array. No matter how good a new compiler is, it won't
solve that problem. And moving to another compiler because some changes
to your code caused errors to show up seems a very rash move.
I suggest rolling back the changes that were made until you get to the point that
you can run without errors. Then selectively add back your changes to find what
caused the problem.
Steve
Reply by ●June 23, 20072007-06-23
This really sounds like you're writing out of an index bounds or other
pointer writes to unintended places. I've done these on every C
compliler I've ever used. Despite all the protective stuff, I still
get a phone call in the middle of writing a function and make a dunb
mistake. C is a powerful language, and really can do a fantastic
crash! These can be a real hassle to find if you don't test early and
test often. The actual root cause may be something pretty tiny that
starts a chain reaction into a death spiral.
Try turning off some functions (comment them out) and break your big
problem into little ones.
pointer writes to unintended places. I've done these on every C
compliler I've ever used. Despite all the protective stuff, I still
get a phone call in the middle of writing a function and make a dunb
mistake. C is a powerful language, and really can do a fantastic
crash! These can be a real hassle to find if you don't test early and
test often. The actual root cause may be something pretty tiny that
starts a chain reaction into a death spiral.
Try turning off some functions (comment them out) and break your big
problem into little ones.
