Help me Plz!Debugging RAM version of build,produces rt output,Bin version does not!

Gurus, I have worked in Lots of RTOS projects for consumer electronics applications.I have encountered the following problem in couple of instances and till now not able to track the reason behind it,because each time my solution varies.Given below is my brief of the problem:

We have a consumer electronics appliance in which when the Target boots up and puts a logo screen,when the user presses a key in the remote,the target crashes.This happens in the ROM version of build. When we debug it in RAM version,it never happens.I am clueless what could be possible reason for this. My little knowledge of RTOS says that this should be due to some timing implications which when we step through debugger in RAM version makes it work and since ROM version is non debuggable,we dont get required delay for it to work.Is this understanding correct? I am wondering how experts around here have solved these sorts of problems where a RAM version when debugged works and ROM version of same software fails!

In another case I encountered similar problem and traced the route cause for an first enum parameter which was initialised to 1 instead of zero and when we set the initial param to zero,it worked.I was clue less how this made the Debugged RAM version work and fail in ROM version.

It would be helpful if anyone can share their experience on how they tackle such problems and whats the best way to debug such problems. Advanced thanks to all your replys and looking farward for your pearls of wisdom, Regards, s.subbarayan

Reply to
ssubbarayan
Loading thread data ...

Given the minimal amount of information you give, it's pretty much guaranteed that nobody else can have more of a clue than you do.

[...]

And why would that be? There's no particularly strict reason ROM builds of a program should be non-debuggable. They may well be

*harder* to debug than RAM builds, because some of the usual techniques (e.g. run-time code modifications) aren't immediately applicable to ROM programs. But it's not generally impossible.

Or, to put it more provocatively: if your project and CPU is fat enough that investing in an RTOS makes sense, how come you don't have JTAG debugging?

And how is that ROM build actually different from the RAM build? The one special case you mentioned hints that you didn't understand your tools well enough to turn on all needed options for them to support a feature of the standardized language like static initializers.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

Probably, or even some variable that should be in RAM actually being in ROM or not waiting for hardware correctly, not intialising ports correctly (including serial ones), that happens to work in RAM versions.

RAM based debugger does things that are not done without debugger.

Use a scope/logic analyser to see what happens when, or toggle LED, or even send messages to a serial port.

Sounds more like you have RAM based variables that your code assumes are zeroed, but your startup code does not initialise them to zero. This could easily be the difference between your RAM based debugger and ROM version.

Your scenarios suggest that you have spent time in hosted Application Programming and transferred to embedded programming, without understanding the differences.

Without knowing if these are all on the same RTOS, or host processor anything other than the above general hand waving.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Click to see the full signature
Reply to
Paul Carpenter

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.