Warning - Code Warrior can destroy your MMEVS

[bigmac]

I wonder if anyone else has had a similar experience!

I have a MMEVS comprised of M68MMEVS05PFB (1994) base module, and EML08QY (2002) emulation module. This has been successfully used in conjunction with the P&E debugger program for about three years, for HC908QT/QY target devices.

I recently attempted to use the MMEVS in conjunction with the CW 5.0 debugger (used as a stand-alone utility, and not via IDE) - I had previously used the debugger only in simulation mode.

When I first selected MMEVS mode within the debugger, there was a flurry of data activity, as indicated by flashing of the LED on the MMEVS.  I was then presented with an error message that the file "firm0508.mon" did not load, or could not be found, even though this file was located in the directory specified.

All subsequent attempts to communicate with the MMEVS now fail, whether using CW or the P&E debugger. Connecting a terminal emulation program directly to the MMEVS generates nothing after power-up - I would expect some sort of "banner" message to be displayed.  It appears that the existing MMEVS firmware has been erased by CW.  No prior warning was given by the program that a firmware upgrade was needed, and that this would automatically occur.

A request to Freescale support has been less than helpful - with the response "it sounds like your firmware is corrupted or damaged", and that I would therefore need to purchase a new MMEVS - (contrived obsolescence??).

Does anyone know what steps are necessary to re-instate the original MMEVS firmware, as I would expect that this should be possible?  After this experience, I have nil confidence in using Code Warrior - what other hidden "updates" might it attempt?

Regards,
Mac

[rocco]

Hi, Mark:

A dialog that I have to acknowledge would be fine. Then I would at least know.

But I would prefer a dialog that I can also cancel. I remember situations when I've had to backup to original firmware in order to work with the original software (not with P&E products, however). This would allow me to buy a new multilink, rather than irreversibly upgrading an old one.

CodeWarrior should do this, as well.

Of course, this is Mac's and David's thread, and I can't speak for them.

Message Edited by rocco on 2006-08-23 02:09 PM

[P_EMark]

Well, thanks for your input-- I'm passing it all along to the necessary parties...

- Mark

[peg]

Hi Mac,

Not quite the same league but the first time I used my P&E USB Multilink with Codewarrior it just decided all by itself that it needed to be updated. Flashed a window up while it did so that then dissappeared by itself.

This actually caused no problems and I had none before BUT..........

If I had been asked I would have rejected the upgrade until a less dangerous (for me) time.

If I had of looked away or blinked when the update occurred I would never have known and if some problems did crop up I would never have known to blame the upgrade. I still don't know the previous version number and never took any notice before.

I have written about this before here.

Regards David

[bigmac]

Hello David,

Yes, I did recall your experience with the USB Multilink.  This is a primary reason why I have not yet tried to use Code Warrior in conjunction with my Mon08 Multilink.

Another of the questions I posed to Freescale Support, in addition to the MMEVS issue -
"I am also using a Mon08 Multilink (parallel port version) for programming purposes.  Does CW burner or debugger also require to erase its firmware, without giving any warning or choice in the matter."

I received the response -
"The multilink automatically updates its firmware. CW does not to my knowledge."

Curiouser and curiouser!

Regards,
Mac

[Alban]

Dear David and Mac,

Multilink is P&E Micro and not Freescale. I think what the person wanted to tell you is that CodeWarrior does not see the firmware update and it is internal to the P&E Micro programming DLL.

It does not address the question on MMEVS though...

Alban.

[peg]

Hi Alban,

That may well be the case, but finger pointing does nothing to alleviate the grievance!

Regards David

[Alban]

Instead of taking my message as "finger pointing" you could well take it as "check-with-P&E-Micro suggestion to go forward" ...

I'm not P&E Micro Techical Support and I don't see them here regularly !

They have a Forum on their website.

Message Edited by Alban on 2006-08-23 12:16 PM

[peg]

Hi Alban,

As this forms part of the basic Codewarrior package and escpecially as it is more of suggestion of something to be looked into rather than a bug or something I would have though pointing it out here would have been sufficient to prompt Freescale to act on this themselves in order to produce a better user experience for their product.

My car is made up of many components/sub-assemblies not actually made by the manufacturer of the car. When I have a problem with one of these I talk to the car manufacturer, not the component manufacturer, and I think most people would expect them to deal with it.

Regards David

[Alban]

Dear Peg,

I love your analogy even if I completely disagree (when I buy a house...).
My aim is to solve members problem, it doesn't matter to me if Freescale or a thrid party screwed up (I don't get paid more one way or another, it's still on my free time). My final goal is for it to work.
That's why I contacted P&E Micro and asked for their opinion.

Nevertheless, not to take anybody's defense (coz it's not my role anyway), IMHO having automatic updates does create "a better user experience for (...) product" generally speaking. (antivirus, Windows, firewall, calendars...)

We'll see if they want to put a switch/check box for developpers who want total control.

Alban.

[P_EMark]

P&E Here....

The firmware update is a tricky issue. The reason is: the latest versions of our software may require the latest version of the firmware in order to function properly. Also, please note that we only provide the firmware updates with the latest versions of our software, so said updates are only applied when they're deemed necessary.

So, the short answer is: these firmware updates are mandatory.

What would you guys think of simply keeping the dialog visible until the user acknowledged the firware update? EG, "Your firmware has been updated from X to X+1. Press OK to continue"?

Regards,
Mark

[rocco]

It's a fact of life . . . Firmware updates can fail.

I would like to know when ANY firmware update occurs, so that I am not chasing my tail, wondering what's gone wrong, on those few occasions when the update does fail.

That's all.

[peg]

---

rocco wrote:
It's a fact of life . . . Firmware updates can fail.

I would like to know when ANY firmware update occurs, so that I am not chasing my tail, wondering what's gone wrong, on those few occasions when the update does fail.

That's all.

---

Hi all,

Yes they do! I had a Windows CE terminal fail completely during an update just yesterday! The power went off during the update and there is now apparently nothing I can do except have it replaced. This was a deliberate upgrade initiated by me in this case.

I have Win XP updates completely automatic on my desktop,  but on my notebook I have them set to "ask before" or something like that.

This is EXACTLY for the same as my reason (1) for not liking fully auto updates. My desktop is "backed up" by my notebook but my notebook in the field is on its own. Only I know when it is essential that it functions normally (the next day during a large interstate commissioning for example). All the updates are done on both at present, I just pick a "safe" time to do them on the notebook.

As for reason (2), if something starts not working properly soon after an upgrade you can blame the upgrade or try to go back to the previous version etc IF YOU KNOW THAT IT HAPPENED!

As for my Multilink, I was in the middle of adding some functionality to one of our products using older standalone P&E software. I was just experimenting with Codewarrior "after hours", given the choice I would have rejected the upgrade attempt at that time.

Please Mark, if you are going to add a dialogue box can't it be before the upgrade with a button to bail out? This should be no harder to implement but would cover all possibilities. Thank you for you assistance with this.

Regards David

[P_EMark]

I'm not sure if we can provide the option to decline the firmware update. This would cause the software not to function properly and could lead to some ugly issues.

I will, however, pass the idea around internally and see if there's any middle ground on this-- though I'm fairly certain that everyone will stand firm on forcing the update.

Regards,
Mark

[colinh]

Interesting stuff.

Personally I think the PC tools should always prompt the user if they are about to update the firmware in an external device. If the user refuses to update, the PC app can always refuse to run.

I think there is also a minor issue of what is being updated. In the case of firmware embedded in a P+E Multilink cable for example I would only be mildly annoyed if a P+E PC app went and updated it (assuming it still functioned). If on the other hand the PC app went and updated something like an MMEVS or MMDS08 (which I believe are not P+E products) without warning me, and as a result caused the loss of previous capabilities in some way, my annoyance rating would be much higher. In this latter example I dont believe that P+E (or any other software vendor) should assume they "own" the system that they are about to upgrade.

[P_EMark]

I couldn't agree more-- we only update the firmware of devices for which we write the firmware (eg, P&E products...)

And, we here at P&E are also embedded systems developers-- so we share the same annoyances and pet peeves as far as maintaining control over our development systems, etc (trust me, on my Windows systems, auto-update is certainly set to "off"). As I said, we only provide automatic firmware updates with software updates -- because the updated software simply requires the interface to have the updated firmware.

Not to beat a dead horse or anything.... :smileyhappy:

Regards,
Mark

[colinh]

Mark

Apologies for any slight towards P+E - when I went back over the thread I see that we diverted from the real facts of the issue at about the second post.

Colin

[P_EMark]

No need for an apology-- though this particular issue may have involved Freescale, it's still an issue (how to handle firmware updates) that can affect all tool vendors.

I found this especially interesting, because there was some internal debate here at P&E before we settled on the automatic firmware update mechanism. Many of the same points that have been brought up in this forum were brought up in P&E's discussion's as well.

Anyways... here's hoping for an oscillator problem :smileywink:

Regards,
Mark

[bigmac]

Hello all,

On my original MMEVS issue, I did not think that P&E was involved, since I was not using the P&E debug software when the fault occurred - but please correct me if I am wrong.

1. My MMEVS is a Motorola product that I would assume would now be supported by Freescale.
2. I was attempting to use the hiwave.exe debugger, supplied as part of Code Warrior 5.0 for HC08 devices.  This version was supplied by Freescale.
3. Also included in the Code Warrior package was the file firm0508.mon which seems to contain S19 format code.
4. When I tried to commence my first MMEVS debug session using hiwave.exe, the program "bombed out" because it either could not load or could not find the file firm0508.mon.  This would seem to me clearly a case where the firmware update process failed.
5. I have not been able to communicate with the MMEVS by any method since the attempted update, so I must assume that the firmware is now erased.

With these facts it would be reasonable to assume that my problem is due to a malfunction of a Freescale program.  Yet in a subsequent service request to Freescale, I was informed that I would need to purchase a new MMEVS since the existing unit was faulty (probably 1000 - 1500 AUD for a new base module).  I consider this response to be totally unreasonable, and will not be doing so.  This will certainly inhibit my future product development using 908Q series devices.

This leaves me with a bad taste with respect to Code Warrior, especially since I had previously used P&E assembler and debugger without any problems, and since I have no need of C for these low end devices.

Regards,
Mac

Message Edited by bigmac on 2006-08-29 02:54 AM

[rocco]

Hi, Mac:

This may be a long-shot, but I just finished troubleshooting a problem with one of my MMEVS systems.

I use a version of the Hiware debugger that came with MCUez. I don't know how much of the Hiwave debugger is descended from the MCUez debugger, but they look the same.

The problem was that the oscillator on my target board stopped working (broken pin on the target adapter). The MMEVS was jumpered for an external clock.

When I tried to start the debugger, it would hang. When I tried to cancel out, I got the message:

Firmware file 'firm0508.mon' not loaded or not found in directory '\\Sausage\Programs\MCUez\prog'

I get the same message if the target board is not connected or un-powered, or when the clock-select jumper is mis-placed. So this message can mean many things, unrelated to the real problem.

If all else fails, there is a company that will swap out either your platform board or your emulation module with a repaired one for $150 (last time I used them, 3 years ago).

[bigmac]

Hello Rocco,

Thank you for responding.

The message you describe is the one I received (but obviously with a different path to suit my installation).  However, I do not get to test your theory since I now have zero communications with the platform board, and I cannot get past the dialog asking me to select a different serial port.  Connecting a terminal emulator to the MMEVS produces no output from the MMEVS on power-up.

This problem is even more frustrating since I had ordered an upgraded emulation module (that has now arrived) to handle the QB devices as well.  So this expensive unused piece of hardware is now about as useful as **bleep** on a bull - in the Australian vernacular.

Regards,
Mac

The acceptable word filter seem a tad over-sensitive - the "bleep" replaced a shorter word meaning "mammary glands" - I wonder if this will also be bleeped.

Message Edited by bigmac on 2006-08-29 01:49 PM