Debugging without ActiveSync?

Looks like there are instructions on how to do this posted at: http://blogs.msdn.com/vsdteam/archive/2005/04/28/413304.aspx

I have not tried it, but am seriously considering it..

Thus far, of all the vstudio 2005 CTP releases, the november release worked best. Ironically, this was a build that the SD team warns device users to stay away from (Why?). The biggest problem I had with this build was the repeated crashing and various other bugs. Frustrating? Yes, but it was the only build that communicated with the device in a reliable manner.

Is there a way to get Activesync 3.8 to work with the beta 2? It seems strange that beta 2 would be OK'd by the SD team when it is unusable. Maybe it is just a configuration issue.. wishful thinking?

I have one final suggestion for the project managers regarding bug tracking. Right now the bugs appear as new, confirmed, working, or closed (among others?). All the bugs regarding vstudio Beta 2 and activesync are currently affecting the build, but are being closed. A deferred status should be added to indicate that the resolution for a bug is outside of the control of development - that the app is working fine, it is someone elses problem.

Although this is in the wrong forum for more suggestions, once I get started, I have to finish. Another useful tracking field would be the target build that the bug was/will be fixed in. Knowing which builds are affected by a bug would also be useful..

Back to the topic, is there any unofficial information about the projected date for activesync 4.0 or a 4.0 beta release? Can anyone give a comment in full understanding that their response is opinion and that they will not be held accountable for any estimate that they give? (Good answers take the form of: a couple weeks, any day now, within a month. Bad answers are: Soon or Shortly.)

DamageTime at 2007-8-21 >

You'll have to bootstrap them manually just as you would a CE device.

Thanks,

Vladimir

VladimirFedorov at 2007-8-21 >

The directions are here:

http://blogs.msdn.com/vsdteam/archive/2005/04/28/413304.aspx

Thanks,

Vladimir

VladimirFedorov at 2007-8-21 >

What is happenning is that the emulator is not recognizing the idle loop in the BSP and is trying to execute it at maximum speed. The workaround is to change the idle loop in the SMDK2410 so that the emulator sees it and goes idle. The key sequence of ARM instructions that the emulator is looking for is generated by:

do {} while (!fInterruptFlag);

So here is a sample implementation of OEMIdle that will cause the emulator to behave properly.

VOID OEMIdle(DWORD idleParam)
{
extern volatile BOOL fInterruptFlag;

// Entered with interrupts disabled. Safely clear the flag.
fInterruptFlag = 0;

// Re-enable interrupts, and do nothing until one occurs.
INTERRUPTS_ON();
do {} while (!fInterruptFlag);

// Turn interrupts back off, just like when entered.
INTERRUPTS_OFF();
}

As far as getting foldersharing working - that's a fairly large change to SMDK2410 BSP. Note that using SMDK2410 is not officially supported solution.

Thanks,

Vladimir

VladimirFedorov at 2007-8-21 >