Platform Builder: It Worked in Debug, but doesn’t in Release

A common problem that developers run into is that when they change the build from debug to release, their application or dll no longer works, or doesn’t run at all. Here are some of the causes that I can think of:

1. The application or driver wasn’t actually in the OS image. This happens a lot because of a handy feature of KITL and the CEShell, which is the Release folder. The Release folder is a folder on the device which is linked to the _FLATRELEASEDIR on your development workstation. When a dll or exe is needed by the system, it looks in the Release folder if it can’t be found in the Windows folder. So even if you didn’t add the file to your bib file, it will run – until you no longer have a Release folder. Check your ce.bib to see if your file is listed there, if not you need to add it to your bib file.

2. Unitialized variable. When you compile for debug, variables will be automatically initialized, but for optimization in a release build that is removed.

3. Timing. Remember all those debug messages that you had? They take time and slow down the boot process and may even change the order of operations.

4. Optimization. With thanks to Valter Minute for pointing this one out, the following loop will work in debug, but fail in a retail build:

MY_DEVICE_REGS* regs=(MY_DEVICE_REGS* )MmMapIoSpace or other mapping function

regs->myreg|=0x1; // set the bit

while (regs->myreg & 0x01); // wait until it has been cleared

This while loop will be optimized out because the optimizer sees no reason to for the loop to run. The solution is to add "volatile" to the definition of regs:

volatile MY_DEVICE_REGS* regs=(MY_DEVICE_REGS* )MmMapIoSpace or other mapping function

Adding volatile to the definition tells the compiler that the data pointed to by regs will change outside of the code's control. Therefore, any reference to the data should not be optimized.

It is important to test the Release build early and often.

Summary of When Things Go Wrong

posted on Friday, June 27, 2008 5:35 PM

Feedback

# re: Platform Builder: It Worked in Debug, but doesn’t in Release 6/30/2008 4:18 AM Valter Minute

I would like to point out another nasty debug/retail problem that can happen in drivers that accesses the registers of a peripheral device.
It can come from not using the "volatile" keyword to access those addresses.
if you declare a pointer as:
MY_DEVICE_REGS* regs=(MY_DEVICE_REGS* )MmMapIoSpace or other mapping function

and then do something like that:

regs->myreg|=0x1; // set the trasmission bit

while (regs->myreg & 0x01); // wait until it has been cleared

The loop will work in debug builds because the code isn't optimized and the generate machine code will load the contents of myreg in a CPU register, or it with 0x01, store it back, reload it, and it with 0x01 and jump back to reload if it's zero.
In a release build the optimizer may detect the store and reload of the value with no modifications of it and so it may skip the reload operation, leaving you with an infinite loop.
If you use "volatile" you will tell the compiler that the values of your registers may change at any time and so it will make no assumption about them, removing the optimization side effect.

# re: Platform Builder: It Worked in Debug, but doesn’t in Release 6/30/2008 9:05 AM Bruce Eitman

That is a good one Valter.

Thanks for the input.

# re: Platform Builder: It Worked in Debug, but doesn’t in Release 6/30/2008 12:51 PM Valter Minute

I like your blog entries, short, simple and focused on a specific task, just the kind of information that sometimes you can't find inside the reference.

If I can provide a little more information, I'm very happy to help :)

I read the entry you wrote about volatile and I never thought about the P<XXXX> typedefs. I don't like them and so I never used them inside my drivers, but knowing that "side-issue" of their usage and explaining it when I do training to other people will save many sleepless nights to many embedded developers!

Post Feedback

Title:
Name:
Email: (never displayed)
Url:
Comments:
Please add 1 and 1 and type the answer here: Enter the code shown above: Remember Me?

Bruce Eitman

News

Tag Cloud

Archives

Post Categories

Feedback

Post Feedback