How to not load RAM buffers with the debugger (CodeWarrior 7.1, ColdFire MCF5253)

[blawson]

I'm using CodeWarrior 7.1 with the P&E Multilink Debugger on a ColdFire MCF5253.

In my project I have a very large RAM buffer which is used as scratch space and is initialized as needed at runtime.  Loading this buffer through the debugger takes a very long time, so I'd like to avoid doing that if at all possible.

In the "CF Debugger Settings" panel I un-checked the boxes for "Uninitialized Data", but the buffer is still being loaded through the debugger.  Does anyone know how to tell the debugger to not load this buffer?  Do I need to do something in the linker file to mark this memory as "uninitialized"?  The memory is declared as "static uint8 buffer[SIZE]".

Any advice is appreciated.

--Bill

[J2MEJediMaster]

Take a look at the memory map listing and see what section your buffer is in. Is it the .bss section? If so, the debugger is going to try to initialize that section (even if it's zero filled) when it loads. You might try removing the static declaration on buffer[], which is directs the compiler place it into that specific section. This is probably one of those compiler questions where CompilerGuru knows the correct answer.

---Tom

[blawson]

My buffer does get linked into .bss by default.  I tried creating a new section for it (called .uninitialized).  The link map shows that the buffer is correctly placed in .uninitialized, but the buffer is still being loaded by the debugger.

I assume that the buffer is still being loaded by the debugger because my code takes more than 6 minutes to load.  If I change the size of the buffer to 1 byte, the code loads in less than 1 minute.  I assume once the debugger correctly ignores the buffer the code should take <1 minute to load.

Please let me know if there's any more information I should provide.

--Bill

[Quandtum]

Did this issue come to a solution?  If so, what was it?  I have the same issue and would like to speed the debug load times.

[blawson]

I opened a support ticket for this, and the resolution boiled down to, "Yup, that's a bug.  Sorry."

--Bill

[Quandtum]

Thanks for the response.  That's rather unfortunate (especially when using very large RAM buffers), it really impedes the work process.  Will have to figure something else out.  Thanks again.