Recent upgrade breaks project

[stderr]

I was informed yesterday that a CodeWarrior update was available, so I followed the instructions, and am now on this version:

CodeWarrior for MCU

  Version: 10.3

  Build Id:130315

My processor is an MK10DX256ZVLQ10

When I try to build, I get a pop up window with this message:

The Processor Expert project <myproject> was NOT generated because of some error.  See the Problems view for more details.

So, when I follow the instructions and look at the Problems view, I get this:

Description	Resource	Path	Location	Type
Generator: FAILURE: at line 166: Unexpected status, please contact Freescale support. (file: Drivers\Common\DoxyGenComponentDoc.prg)	myproject		ADC0	Processor Expert Problem
Generator: FAILURE: at line 166: Unexpected status, please contact Freescale support. (file: Drivers\Common\DoxyGenComponentDoc.prg)	myproject		ADC1	Processor Expert Problem
Generator: FAILURE: at line 166: Unexpected status, please contact Freescale support. (file: Drivers\Common\DoxyGenComponentDoc.prg)	myproject		CRC	Processor Expert Problem
Generator: FAILURE: at line 166: Unexpected status, please contact Freescale support. (file: Drivers\Common\DoxyGenComponentDoc.prg)	myproject		DAC0	Processor Expert Problem
Generator: FAILURE: at line 166: Unexpected status, please contact Freescale support. (file: Drivers\Common\DoxyGenComponentDoc.prg)	myproject		DMA	Processor Expert Problem
Generator: FAILURE: at line 166: Unexpected status, please contact Freescale support. (file: Drivers\Common\DoxyGenComponentDoc.prg)	myproject		FTFL	Processor Expert Problem
Generator: FAILURE: at line 166: Unexpected status, please contact Freescale support. (file: Drivers\Common\DoxyGenComponentDoc.prg)	myproject		FTM0	Processor Expert Problem
Generator: FAILURE: at line 166: Unexpected status, please contact Freescale support. (file: Drivers\Common\DoxyGenComponentDoc.prg)	myproject		FTM1	Processor Expert Problem
Generator: FAILURE: at line 166: Unexpected status, please contact Freescale support. (file: Drivers\Common\DoxyGenComponentDoc.prg)	myproject		FTM2	Processor Expert Problem
Generator: FAILURE: at line 166: Unexpected status, please contact Freescale support. (file: Drivers\Common\DoxyGenComponentDoc.prg)	myproject		PIT	Processor Expert Problem
Generator: FAILURE: at line 166: Unexpected status, please contact Freescale support. (file: Drivers\Common\DoxyGenComponentDoc.prg)	myproject		PTB	Processor Expert Problem
Generator: FAILURE: at line 166: Unexpected status, please contact Freescale support. (file: Drivers\Common\DoxyGenComponentDoc.prg)	myproject		PTC	Processor Expert Problem
Generator: FAILURE: at line 166: Unexpected status, please contact Freescale support. (file: Drivers\Common\DoxyGenComponentDoc.prg)	myproject		PTD	Processor Expert Problem
Generator: FAILURE: at line 166: Unexpected status, please contact Freescale support. (file: Drivers\Common\DoxyGenComponentDoc.prg)	myproject		PTE	Processor Expert Problem
Generator: FAILURE: at line 166: Unexpected status, please contact Freescale support. (file: Drivers\Common\DoxyGenComponentDoc.prg)	myproject		SDHC	Processor Expert Problem
Generator: FAILURE: at line 166: Unexpected status, please contact Freescale support. (file: Drivers\Common\DoxyGenComponentDoc.prg)	myproject		SPI2	Processor Expert Problem
Generator: FAILURE: at line 166: Unexpected status, please contact Freescale support. (file: Drivers\Common\DoxyGenComponentDoc.prg)	myproject		SysTick	Processor Expert Problem
Generator: FAILURE: at line 166: Unexpected status, please contact Freescale support. (file: Drivers\Common\DoxyGenComponentDoc.prg)	myproject		UART5	Processor Expert Problem
Generator: FAILURE: at line 166: Unexpected status, please contact Freescale support. (file: Drivers\Common\DoxyGenComponentDoc.prg)	myproject		VREF	Processor Expert Problem
Generator: FAILURE: at line 166: Unexpected status, please contact Freescale support. (file: Drivers\Common\DoxyGenComponentDoc.prg)	myproject		WDOG	Processor Expert Problem
Generator: Warning: Device Initialization is obsolette and might not be supported in next release	myproject		Code Generator	Processor Expert Problem

Any ideas on how to fix this?

[BlackNight]

Does the problem persist if you do Project > Close Project and then Project > Open Project again?

You should be able to remove the errors in the problem view with deleting them (that would remove the markers, but not necessarily the root cause).

It might be worth a try.

[stderr]

Well, after a day of reinstalling, rebooting, reconstructing, and generally losing ground on my project schedule, I now am being told my segger j-link installation is corrupt, on a freshly created project. I can no longer enter debug mode or program this device. So far, not a big fan of freescale, and if I ever get this running again, I won't bother with any more "updates".

[BlackNight]

Hi Lawrence,

I'm trying to find out what could have caused the problem you see. Could it be that you had a debug session running while performing the update? Or were you previously debugging, and then you decided to perform the update? I'm thinking that maybe the debugger DLL's were loaded, and things were locked during the time of the update, and this might have caused what you see. Clearly, that's an issue on the updater side, but I'm wondering if this could be a szenario which caused this.

[steve_fae]

My customer is having problems with the latest install as well.  Segger is working on trying to find why my customer can't debug with the KL1x series. 

[BlackNight]

I have received the information that it is necessary to restart the Eclipse IDE *before* doing the update. Having done anything which could load the debugger engine (de.exe) or debugging DLL's is likely to cause the described problem. So doing a debugging session or even switching to the debug perspective before doing an update without restarting Eclipse before doing the update can have debugger DLL's loaded in memory, which then will lock e.g. the Segger run control libraries, which then can result in what is described here. That's what I have found out so far.

[stderr]

What I don't understand is, when I created a new project with the latest installation, the general structure of files changed. In the previous version, I ran the processor expert and it created a skeleton main.c/main.h set, and an MCUinit.c/MCUinit.h set. In the MCUinit files were the configuration of every hardware device I had selected, along with ISRs for every interrupt, and a vector table. The ISR functions were all empty, but they were defined. The new version of codewarrior created ProcessorExpert.c, and Events.c/Events.h. Looking in the Events files, there was a declaration that I had to create all my own interrupt functions, they wouldn't do it.

Thinking I should move forward with the new installation, I migrated my application into ProcessorExpert.c, and constructed ISRs in Events.c, which I had to do in order to compile the code. Then the application barfed when trying to enter debug mode.

Why did this change so dramatically? When I initially opened my application in the new version, I got the warning at the end of the list in the original post:

Generator: Warning: Device Initialization is obsolette and might not be supported in next release

The misspelling of obsolete is the actual message, not a typo on my end.

Realizing this was not going anywhere, I uninstalled codewarrior, and any Segger software I could find. I then rebooted and reinstalled the previous version of CW. Enough already. I'm not in to being a beta tester for free, and I'm not able to ask my customer to pay for the time I spent jerking around with this. At least now I'm up and running, and will ignore the "updates are available" popup window from now on.

Lastly, to answer your question about the debug session being open: of course there was a debug session open! I'm developing an application and was in the middle of working on it. I was not only _not_ cautioned against having a debug session open, but clicked the "run in background" button on the update window so I could continue working. If this was going to break the installation, or if the installation would fail if I didn't restart Eclipse before running it and make sure I had closed the debug perspective prior to relaunching, and that there was no debug session started after relaunching, why was this even allowed to run? More importantly, why wasn't this tested prior to releasing the update?

[BlackNight]

Here is what I think happened:

while you did the update running in background, Eclipse/debugger was locking some files. This caused the updater either silently to fail, or at least not reporting the problem in advance. You did not do anything wrong: the tool/updater should have catched this. And it looks like that problem has been found while testing, as the release note says something along the line 'restart eclipse before doing an update and do not use it during the update'. Clearly you have not had a chance to see that note as you were installing it directly from the updater. I saw that release note entry, and was wondering. And when I saw your post, I was thinking that this could have been your problem. So this confirms this is a real problem. As of this morning, the udpate is not available on the web anymore, so Freescale has pulled it off to avoid that others run into the exact same problem. At least my base version of 10.3 does not show that pop-up any more. This might not be a big thing, but personally I want to thank you on behalf of the community that you reported this problem. Otherwise many others would have run into the exact same issue.

As for the first point (MCUinit.c/.h): I have not used such a 'Device Initialization' Processer Expert project (I always used Processor Expert and not 'Device Initialization'): this option is not available in 10.3. As you noticed, the file names are different for the genereated source files, but the xxx_Init components ares still there and could be used with a normal Processor Expert project.

[BlackNight]

I have now done that update too on my machine. I only have the Segger J-Link on the TWR Kwikstik board (embedded J-Link), and for me this still works. Not sure if if things are different for different J-Links. It sounds to me that the J-Link USB drivers somehow are affected. Maybe there is a way that you can re-install them? I see there are drivers available inside Freescale\CodeWarrior\Drivers\Segger.