|
|
View previous topic :: View next topic |
Author |
Message |
Charlie U
Joined: 09 Sep 2003 Posts: 183 Location: Somewhere under water in the Great Lakes
|
Silicon Rev of 18F452 |
Posted: Tue Apr 27, 2004 4:10 pm |
|
|
I'd love to turn off the added "nop" feature that was instituted quite a while back that overcomes a silicon problem in the 18F452. The latest revs of silicon, in theory, do not exhibit the problem. However, I can not find a list of target ids that correspond to the various silicon revs. The latest errata is for C0 parts with a target ID of 0x07. I have parts that are 0427. Are my parts older or newer?
Does anyone know where to find this information and could you please point me to it?
Thanks in advance.
Charlie |
|
|
Haplo
Joined: 06 Sep 2003 Posts: 659 Location: Sydney, Australia
|
|
Posted: Tue Apr 27, 2004 5:27 pm |
|
|
You are better off asking Microchip directly. Although I've heard they are not very helpful on questions like this... |
|
|
Charlie U
Joined: 09 Sep 2003 Posts: 183 Location: Somewhere under water in the Great Lakes
|
|
Posted: Tue Apr 27, 2004 11:15 pm |
|
|
I turned off the "nop" feature by editing the device file for the 18F452 using the device editor in PCWH, and recompiled. I lost about 300 bytes from my hex file, but the resulting code did not run at all. The first thing that normally happens with the code, is a message on the LCD display, but the display was just blank, not a good sign. I turned the feature back on and have moved on.
(Version 3.190) |
|
|
MGP
Joined: 11 Sep 2003 Posts: 57
|
|
Posted: Wed Apr 28, 2004 4:17 pm |
|
|
So Charlie... the $64 question is -- do you think the compiler is producing bad code after removing the NOP's or do you think the compiler code is fine and you still have some buggy 18F452 chips?
Just curious as I'm getting ready to do a project with the 18F452. |
|
|
Charlie U
Joined: 09 Sep 2003 Posts: 183 Location: Somewhere under water in the Great Lakes
|
|
Posted: Wed Apr 28, 2004 6:31 pm |
|
|
MGP,
The jury is still out on this one. My customer has started to standardize on the 18F452 for a few new products, and we have had some very good results with it on this first project. My next step will be to back off from compiler version 3.190 to 3.188 and see if it's any better. I also plan to call CCS and get their view on the subject. Right now, I am working with a pre-production board with a TQPF part on the board and no emulator adapter for it. I plan to resurrect the DIP prototype and try to sort out this a bit more with my emulator.
Regarding your project, I would not hesitate start a project with the 18F452. (I am starting another one tomorrow.) We have had no problems with the generated code except a strange printf problem (see my recent post in the 3.190 baseline thread) that popped up when I stupidly moved to 3.190.
Keep us posted on your progress and I'll post any results I have as I clean this project up.
Charlie |
|
|
Guest
|
|
Posted: Thu Apr 29, 2004 4:27 am |
|
|
MGP: FYI: I'm having no problem at all with the 18F452. Using 60% of RAM and ROM, and PCH 3.179.
Before 18F452 silicon revision workarounds were implemented in the compiler I had serious trouble getting the 18F452 to work, but now everything's fine.
I'd prefer leaving the NOP's in place to be sure. If you write code up to the last 300 bytes, I think you're having the wrong processor sitting on your desk. |
|
|
Ttelmah Guest
|
Re: Silicon Rev of 18F452 |
Posted: Thu Apr 29, 2004 5:30 am |
|
|
Charlie U wrote: | I'd love to turn off the added "nop" feature that was instituted quite a while back that overcomes a silicon problem in the 18F452. The latest revs of silicon, in theory, do not exhibit the problem. However, I can not find a list of target ids that correspond to the various silicon revs. The latest errata is for C0 parts with a target ID of 0x07. I have parts that are 0427. Are my parts older or newer?
Does anyone know where to find this information and could you please point me to it?
Thanks in advance.
Charlie |
The 'key', is to look at the older errata sheet, that has the NOP problem documented. Here you will see, that it says the problem applies to all silicon releases predating the 0252 release. The Microchip date codes, are 'year' (2 digits), and 'week number'. So 0252, is the 52nd 'work' week in 2002. Your 0427 examples, are actually impossible!. The problem is that these are supposedly made in week 27, of 2004, which has not come yet. The errata 'sheets' refer to particular silicon revisions, but then the individual errata entries give the year/week codes they apply to. Note also that only one of the two 'NOP' problems have been cleared (the one for long calls/jumps), but that one still remains with regards to table reads.
Double check the actual date codes for the chips you have, but you should be OK turning off the 'jump' fix. Remember though, that if you do, and the code is then loaded into older silicon, the problem can rear it's head again...
Best Wishes |
|
|
Charlie U
Joined: 09 Sep 2003 Posts: 183 Location: Somewhere under water in the Great Lakes
|
|
Posted: Thu Apr 29, 2004 6:31 am |
|
|
Ttelmah,
Thanks for the reply. The date code of the parts that I have is 0344. The target ID that I was referring to, 0427, is the one that is actually read from the chip with a programmer. I wasn't certain whether to use the date code or the target ID, since I had a problem with another vendor's parts, were they were very specific in instructing us to ignore the data code and look at the chip rev. since different final assembly facilities could have overlapping data codes and silicon revs.
I'll reread the errata and hope for the best. But this still doesn't explain why the code worked with the nops and failed without them, now that we know that the chip should not exhibit the 4000h jump problem. I did not turn off the table read nops, though.
Thanks again. |
|
|
Ttelmah Guest
|
|
Posted: Thu Apr 29, 2004 7:49 am |
|
|
Charlie U wrote: | Ttelmah,
Thanks for the reply. The date code of the parts that I have is 0344. The target ID that I was referring to, 0427, is the one that is actually read from the chip with a programmer. I wasn't certain whether to use the date code or the target ID, since I had a problem with another vendor's parts, were they were very specific in instructing us to ignore the data code and look at the chip rev. since different final assembly facilities could have overlapping data codes and silicon revs.
I'll reread the errata and hope for the best. But this still doesn't explain why the code worked with the nops and failed without them, now that we know that the chip should not exhibit the 4000h jump problem. I did not turn off the table read nops, though.
Thanks again. |
It ought to work then. I have an ICE, which does not have the nop problems, and have in the past generated code with the nop 'fix' disabled to run in this, which worked OK. It may be that the latest compiler has 'introduced' a problem with this, but I can't really see why (the same code is used in other chips that don't have the nop problem). Is it possible that there is some part of the code that is dependant on the fix bing present (for instance, when I was generating my own 'int_global' handler, I wanted to use RETFIE 1, but the compiler (at this point), did not allow this to be generated, so I added an 'offset' #ROM declaration, to generate the code, but had to remember to allow for the extra space occupied by the nop, when calculating back to get the address for this...).
I must admit I have 'worried' about the use of date codes at times, since there have been definite revision differences seen between chips from different 'fab' facilities. I had a large batch that was faulty, while a batch with the same date code from the Chinese plant, was OK....
Best Wishes |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|