GT8A Won't Erase, or Program

[admin]

Before I knock a hole in the wall from beating my head against it, I'd like to ask you guys if you can see a reason why I cannot erase or program a 9S08GT8A. I've been successful before with a GT16A and 32A but for some reason this thing won't fly.

Before my code piece, some info:
Bus clock = 1.1Mhz (and verified)
FCDIV = 5, meaning my flash clock is 1.1MHz/6, or 183KHz.
FPROT = $FF (no block protection)
Vdd = 3.3v
Part is the 42 pin SDIP (yeah, the weird one that won't fit into any socket in the world that cost less than $45)

The erase code is attached:

[tonyp]

Try starting the command by writing only FCBEF to FSTAT, and try without keeping COP happy.  Maybe one or both of these two will make things work.http://forums.freescale.com/post?board.id=8BITCOMM&message.reply_to_id=10908#" rel="nofollow" target...

[admin]

Thanks for the suggestion Tony. Unfortunately, no joy.

The changed code:

[tonyp]

I just noticed one other possibility.

Are you sure page erase is $48 and not $40?

I don't use this chip, but I think the same codes are in different chips.

[admin]

Yeah, the page erase is 0x40. What may look like a 48 in my code is due to the font, where its zero is a circle with a dot (which is what you see in my code).

[bigmac]

Hello,

Immediately after the ErasePage sub-routine exits, have you examined the value within FSTAT, to see whether an error condition is being flagged?  If so, you will need to find the cause of the error (there should be a number of possibilities listed in the datasheet).

I assume that you are not attempting to single step the stack based routine.

Regards,

Mac

[admin]

Thanks for your suggestion Mac. But yes, I've checked on that and there are no errors returned. Both error bits FPVIOL and FACERR are zero.

Also, checking a timer value before and after execution of Erase shows an execution time of 22ms, pretty much right on the money from what it should be (4000 cycles of the flash clock, which is my busclk/6). I've even tried bumping the FPDIV up & down by a few counts just to if there were any effects with a slightly different flash clock. I've called the PageErase routine 5 times in a row to see if it needed more erase time.

And something else. When I first hooked up the CyclonePro to this thing, it wouldn't erase either. Cyclone would hang at the erase step, spinning its little rotating display of wait characters. I noticed the BKGD pin had a lousy rise time so I reduced the pullup on that pin from 2k to 1k, and it started working. I've kept it at 820 ohms since then and have had no problems from that again, but it may be a clue for my problem. It still takes longer to erase than it does other parts (GT16A and GT32A), as it does briefly show the rotating wait symbols when erasing. I don't see that with a GT16A or 32A. It appears as though this part has no active high speedup pulse for the BKGD pin, and has some internal issue with erase time.

As for single-stepping through the Erase code, yes I've tried that and with no effect. What I do though, is to put a breakpoint at the JSR 0,X and after, to verify that data at $E000 is there before erase and to observe if it is gone afterwards. But I don't see why single-stepping through the Erase code is a bad thing as long as the debugger is not displaying memory in flash after each step. Why is this a no-no, if it is at all?

[bigmac]

Hello,

---

Wingsy wrote:
As for single-stepping through the Erase code, yes I've tried that and with no effect. What I do though, is to put a breakpoint at the JSR 0,X and after, to verify that data at $E000 is there before erase and to observe if it is gone afterwards. But I don't see why single-stepping through the Erase code is a bad thing as long as the debugger is not displaying memory in flash after each step. Why is this a no-no, if it is at all?

---

My concern was the following clause within the datasheet (within paragraph 4.4.5 Access errors).  One of the potential causes of an access error is the following -

• Accessing (read or write) any FLASH control register other than the write to FSTAT (to clear FCBEF and launch the command) after writing the command to FCMD.

It would seem possible that the debugger might be reading the control registers during single stepping.

Regards,

Mac

[admin]

I probably shouldn't be writing this now, cause I'm just a wee bit ticked off.

I found the problem, and I lay the blame of wasting about 5 days of my time squarely on P&E's Debugger.

Would you believe, that once you display flash memory in the Memory window, the information you see there will never change until you quit and reload the debugger. So, being the meticulous person that I am, I would always LOOK at the area to be erased before I erased it, and look again after the erase routine did its thing. Always the same, at least in the Memory window, but it really was being erased (and programmed too).

If I don't look at the memory area before it's erased, but then go look after the erase routine executes, it shows as being erased. And, if I don't look until after it has been both erased and reprogrammed, it shows what I put there.

But once I have a look, it's frozen in the Memory window until the debugger is reloaded.

Yet one more gotcha from the folks at P&E.

[JimDon]

How about you take the blame for not learning to use the product, or researching it, because it has been mentioned on this forum several times. You can blame P&E but that won't make you any wiser. Ask yourself what should I have done differently to prevent this.

If you go to "Debugging Memory Map"  select the block of memory,  click Modify/Deltails then check the box "Refresh Memory When Halting" it  will do just that.

I give you another hint - the reason I figured this out is because when I wrote my flashing code, right from the get go after I erased a block , I had code that looped thru it and checked for 0xFF then I wrote a count pattern and check that it was correctly written. So it was pretty obvious that the debugger was not re-reading flash after each step, and frankly why should it? It was told it was read only. You really don't want the debugger to re-read flash after  each single step normally do you? I'm not "meticulous" at all, but I am experienced and it seemed that checking each byte of the data was a good thing to do.

You should track down the "Great and Lengthy Flash Threads" and read them :--).

And btw it's freescales debugger.

[admin]

Yeah, I knew I should have cooled off before I lashed out at P&E. I'll take most of the blame for not seeing that refresh-memory-after-halt button in the dialog that allows me to change the memory map. But it still has eroded my opinion just a bit more of the entire IDE. It's the most non-intuitive software I've ever seen. Options to set this & that located all over the place, dialogs that don't fit in the window, assembler options that must be set by typing in the option - and nowhere except via telephone do you learn what that is, telling me "Windows NT" detected when I'm using XP, messages that scroll off the screen so fast that it's impossible to read, windows that don't scroll properly (Memory window), breakpoints left behind after removing them, randomly losing network connections (OK, that's a Windows problem I guess), and on and on. That's just off the top of my head. I've got a project to get done, and don't have the time, nor do I want to, become an IDE expert in order to use it. Perhaps I'm just using the wrong tools.

We're way off topic now. Over & out.

[JimDon]

It;s really not as off topic as you might think, because it is the Zen of this discipline we are discussing and I think it is good that you have expressed your frustration with it.

There isn't one of here who has not been in the same position as you found yourself. As I indicated, I had a similar experience, but came to a different conclusion - that the tool did a pretty reasonable thing, and that the configuration was not too hard to find.

As for "intuitive software", I have to ask what the heck does that mean? I would maintain that humans are very poor at this to begin with. Case in point - as far as I know, we are the only species that after 4 millions years has to learn how to properly mate. If you doubt this, go an Amazon and see how books on the subject there are. Now, you would think if anything were to be intuitive, surely it would be that. My third marriage has lasted 20 years, so I guess I finally found the right dialog and checked the correct options.

I am not saying it is perfect, and I can name at least 2 outright bugs and 10 things I'd like changed, all in  many all it works very well. Whats more, as per you own experience at least there was a phone number you could call (whether you are a paying customer or not ).

If you happen to find a better tool for this, please let us know. I'm sure we would all use it instead.

[admin]

OK, you've enticed me to add one more comment.

I'm not saying this to be offensive, really, but if you don't know what intuitive software is then you've been using Windows software way too long. It really does exist, and just like your marriage, when you find it you'll know it.

[JimDon]

I don't find that offensive at all. It a healthy discussion. Ok, so you resorted to indirect name calling instead of making a valid point, but at least you were polite (you dirty Windows user :--).

The point is one man's intuitive is an other mans WTF. Put a Windows user on a Mac and you will see what I mean. The times I have used a Mac, mostly to configure things, I found the Darwin Shell more to my likening, because I have used Unix and to me the shell was "intuitive".  'ls' to see files, ifconfig to see the network, vi to edit a file - just type a command and there you go. Now thats intuitive. To me the Mac interface was not intuitive. One button? How can you drive with only one button? I am being facetious to a point, but there is some truth to what I say. (The part about the shell and me is 100% true).

Not that Windows is easy to use, but it is all what you are used to. To be honest, MS needs a kick in the pants, because they really do not seem to care about the user (and I think they got just that). I make a good living off the fact that Windows has problems, but would prefer not to. Can 500 million user be wrong ? - yes they can. Just shows you how right you mother was when you said "But mom, everyone else is doing it" and she said "I don't care what everyone else is doing - your not".

[peg]

Hi Wings,

Hiwave/P&E debugger does this. It thinks, hey this is flash it won't change unless I do it, so why should I update it.
Double clicking on one of the displayed bytes will update just that byte, which may be somewhat useful.

Laying the blame at P&E may be misguided though as the standalone P&E product does not exhibit this behaviour. It updates the memory window after every step and after every run. This however has the downside that it prevents single stepping flash burning/erase code with flash displayed in the memory window. (The flash accesses of the debugger disturb the burn/erase) Makes for an easy way to test your error handling though.