topic Re: cyclone pro algorithm...reply urgent in Classic/Legacy CodeWarrior

cyclone pro algorithm...

Deepak1 — Sat, 01 Dec 2007 17:31:14 GMT

Dear sir,
Here i am using MC68HC908JK8 device,And device programmer is cyclone pro.
(stand alone programmer).But while choosing Algorithm I found two algorithm options
these are,

908_jk8_highspeed.08P

908_jk8.08P
So which algorithm i have to select.And what is the difference between two.

Re: cyclone pro algorithm...

CrasyCat — Mon, 03 Dec 2007 18:43:41 GMT

Hello

If you are using the standalone programmer, then it is more a question for P&E.

You can try to ask your question on their forum.

Check http://www.pemicro.com/ and click on the link Forum.

CrasyCat

Re: cyclone pro algorithm...

peg — Thu, 06 Dec 2007 13:41:26 GMT

Hi Deepak,

One is high speed the other is normal speed.

Use the high speed one unless you have a problem with it or have too much time on your hands.

cyclone pro algorithm...reply urgent

Deepak1 — Tue, 11 Dec 2007 12:04:19 GMT

Thanks for replying,

you mean to say is,

Highspeed ==> the programming of device is very fast.

Also you are telling i have choose highspeed option else it will be problem.

then what is the use of other.

I am asking bcz we have faced some problems by choosing normal speed..

we have started our mask production with highspeed option after your suggestion.But while programming the standalone programmer is taking 25sec to programme the device.And the code size is only 4.9k. Is there another way to decrease the time.

Re: cyclone pro algorithm...reply urgent

peg — Tue, 11 Dec 2007 12:31:32 GMT

Hi,
There was a time when there was no high speed versions.
Then they (P&E) brought out high speed versions alongside the normal speed ones.
I have never had any issues with the high speed ones and use then exclusively.
I can only imagine they continue to offer the "normal" speed ones for compatability and in case you encounter any issues with the high speed one.
The programming time you quote seems to be about what I would expect from a normal speed algo.
It is significantly faster with the high speed one.

Re: cyclone pro algorithm...reply urgent

bigmac — Tue, 11 Dec 2007 18:36:06 GMT

Hello,

I wonder what is the difference between "normal" and "high speed" programming, and why programming may not be as fast as the devices will permit. Examination of the programming algorithm within the data sheet suggests that the programming of a flash row should take about 1 millisecond (assuming 32 byte row). Therefore, the total programming time for 5K of code should amount to about 160 ms.

I realize this does not include any time for serial communications to the device, but there still seems a wide disparity between 160 ms and 25 seconds. I wonder what is actually happening during the other 24.8 seconds?

Regards,

Mac

Message Edited by bigmac on 2007-12-11 09:37 PM

Re: cyclone pro algorithm...reply urgent

peg — Tue, 11 Dec 2007 19:16:17 GMT

Hi Mac,

I have often wondered this myself. The actual burn time should be very quick and also not able to be changed much anyway.
The time quoted is from pressing the PM command until it reports it is finished.
First a range check is performed on the s19 to make sure it is all within the flash as specified in the "algorithm".
They also have to move the data a block at a time into the device and also verify the burn.
Perhaps most (all?) of the speed improvement is within all of this "overhead" stuff.

Re: cyclone pro algorithm...reply urgent

Deepak1 — Wed, 12 Dec 2007 14:10:05 GMT

Dear all,

I am performing these steps while programming the device with stand alone programmer,

choose algorithm

Specify S- record

Erease module,

Blank check module,

program module,

verify module,

verify checksum

Also those space are not in use are filled with 0x83.

Because of this it is taking 25 sec time ?

Re: cyclone pro algorithm...reply urgent

bigmac — Wed, 12 Dec 2007 14:59:50 GMT

Hello,

I presume that only the "program module" step is affected by the algorithm chosen. It is a little misleading to include all the other steps withihn the "programming time", all of which I assume require to be manually activated one by one.

Selecting the algorithm and S-record should only need to be done once, prior to programming the first device of the batch. If you are erasing each device, you don't really need to do a blank check afterwards. Additionally, I am uncertain whether the programming algorithm also provides automatic verification. It is possible that it may.

Regards,

Mac

Re: cyclone pro algorithm...reply urgent

Deepak1 — Wed, 12 Dec 2007 17:06:18 GMT

Dear sir,

After ur reply,Once again i saw programming of device using stand alone prog. carefully. I observed one point is "verify module" is taking more time than the "program module".

Re: cyclone pro algorithm...reply urgent

peg — Wed, 12 Dec 2007 17:41:03 GMT

Gentlemen,

The 08p file is really a configuration file for the P&E programmer.
Within this setup file is some code that is loaded into RAM.
Within this code is different routines which assist in carrying out different functions, one of which is programming the flash.
Most of the file is setting up parameters and defining part specific commands etc.
I have forgotten all the details for MON08 stuff now but for instance in the S08 files there is a little programme that carries out the blank check this replaces the chips blank check indication because it doesn't work on an unsecured device as it can not be truly blank. It is a little piece of code that confirm every byte of flash, except the security byte is indeed $FF.
The device in question here does indeed do a verify whenever it does a programme. If you look in the file it is written ther quite clearly.

Re: cyclone pro algorithm...reply urgent

Lundin — Fri, 14 Dec 2007 21:01:50 GMT

The main part of the time lost is the time it takes for the Cyclone to reset the device by power on/off, wait for the needed reset time and for the HC08 to startup, enter monitor mode, do something, then cut the power again, enter some other mode etc etc. I wouldn't blame the tool manufacturer for the slow programming time, but rather the HC08 architecture with the "evil" monitor-mode (unsafe, error-prone, unsecure, slow, confusing).