Post by thread:[PIC] Programming unused configuration bits?

Gerhard Fiedler wrote: > How do you deal with that (when/if you have to)? It hasn't come up. Why do you need to? I have occasionally needed to verify that a PIC contained the information in a specific HEX file. For that I use my PIC_PROG program with the -V command line option. It looks up the particulars of the PIC in a data file. This information includes which config bits are relevant and which ones are not. Mismatches in the irrelevant bits are ignored. > Can I set the unused bits to 0 in the > original hex file? You can set them to anything you want in the source code. > If that's not an option, does that mean that normal hex file > comparison tools are not really that useful in this scenario? Right. > Any tricks or solutions? Yes: 1 - Don't do that. A legitimate reason for needing to do that hasn't come up yet in all the years I've been programming PICs. 2 - You can use the facilities in my PICPRG library to get used/unused bit information for any of the PICs I currently support. The data file format is documented, so you can add information for PICs not in there. Once you have this information, you write a program that reads both HEX files into memory arrays, then compares the result taking the config bit masks into account. The PIC_PROG program contains code to read a HEX file into several data arrays. There is more too this than might be immediately apparent, so you are probably better off using that code somehow. ****************************************************************** Embed Inc, Littleton Massachusetts, (978) 742-9014. #1 PIC consultant in 2004 program year. http://www.embedinc.com/products

Olin Lathrop wrote: > It hasn't come up. Why do you need to? > > I have occasionally needed to verify that a PIC contained the > information in a specific HEX file. You kind of answered your question. Just that I don't have access to the PIC, but to a hex file that contains what was in the PIC (and of course the original hex file that contains what should have been in the PIC). > For that I use my PIC_PROG program with the -V command line option. It > looks up the particulars of the PIC in a data file. This information > includes which config bits are relevant and which ones are not. > Mismatches in the irrelevant bits are ignored. This looks like what MPLAB's verify function also does (like probably every programmer's verify function). But it seems both need a programmed chip to compare against. Which I usually have, but not this time. >> Can I set the unused bits to 0 in the original hex file? > > You can set them to anything you want in the source code. That then does seem to do the trick, doesn't it? But the remainder of your message leaves me with some doubts about my interpretation of this phrase of yours... :) >> If that's not an option, does that mean that normal hex file >> comparison tools are not really that useful in this scenario? > > Right. If I understood you correctly, you just said that it's ok to set the unused bits to 0 in the hex file that is used for programming. This would allow to create hex files for programming that look identical to the ones read from a chip -- making it possible to compare them with a standard hex file comparison tool. Did you mean that I can "set them to anything [I] want" if the programming device is smart enough not to program them, or did you mean that it really doesn't make a difference whether they are set to 0 or to 1? If so, is there a good reason why most (all?) header files set them to 1? > 1 - Don't do that. Sorry... don't do what? Set the unused configuration bits to 0? Compare two hex files? > 2 - You can use the facilities in my PICPRG library to get used/unused bit > information for any of the PICs I currently support. Thanks, that sounded like an option if I had that need more often. This was the first time, and I think it won't come up so soon again -- so the need to produce a tool that does this is not that pressing, and when needed, I can always go back to bit-fiddling in my head :) I just thought that most of the (even rare) things that do come up usually came up before for someone else... and maybe I overlooked something. Thanks, Gerhard

{Quote hidden}> >Hello, > >I just compared a generated hex file (used for programming) to a read hex >file (retrieved from a PIC). They were identical (that was good :) but in >order to verify that the configuration bits are identical, I had to do that >manually, nibble by nibble, doing some bit arithmetic in my head -- because >the hex file used for programming contains the unused configuration bits as >1, and the hex file read from the device contains the unused bits as 0. > >How do you deal with that (when/if you have to)? It seems that every header >file I've seen so far defines the unused bits as 1. And every data sheet I >can remember says "read as 0" for unused bits. So every hex file generated >for programming is different from the hex file retrieved from the device. >Can I set the unused bits to 0 in the original hex file? I seem to remember >something along the lines of "leave them alone" (which would mean "leave >them at 1"), but I can't remember where and why. > >If that's not an option, does that mean that normal hex file comparison >tools are not really that useful in this scenario? MPLAB probably >disconsiders the unused bits correctly when verifying, but that doesn't >help me much when I want to compare two hex files -- unless I first program >a chip with one file, and then verify the chip against the other file. >Seems a bit, hm, odd... :) Any tricks or solutions? Or just every now and >then some bit arithmetic? > >Thanks, >Gerhard When I need to compare a generated hex file to a read hex file, I load the generated hex file into my WARP-13 software and then save it. This will produce a hex file that is identical in size to the saved "read" hex file and, also, the software will save both hex files with the unused config bits masked to there silicon read value. I then just do a file compare in text pad. I imagine you could do this in most programmer software. BTW. Unused bits take the form of both read as "1" and read as "0" and there is no global default. Also, yes you can get the source file to produce a hex file with the unused bits masked down or up. Just use "& 0x????" and/or "| 0x????" on the end of your __config statement. Regards, Jim

Wouter van Ooijen wrote: >> If that's not an option, does that mean that normal hex file >> comparison tools are not really that useful in this scenario? > > XWisp (with a wisp628 programmer) can compare a file in its buffer to > what it reads from the chip, disregarding 'forced' bits. That's what MPLAB and Olin's programmer also can, and probably pretty much all other programmers, too. > I think (but I am not realy sure) that reading a hex file and writing it > back (to disk, no programmer needed) forces those forced bits to their > 'hardware' value. Or if not it could easily be modified to do so. How would your software know what bits to force to 0? It would have to know the chip, but the online instruction says: "When a target chip is specified XWisp will try to verify that a chip of the specified type is present by reading the chip's ID. When it does not find the specified chip the program will abort with an error message." Sounds as if this were a no-go without a programmer? Anyway, I tried this command line: p:\>xwisp.py load test.hex save test1.hex It ran "OK", but didn't produce the desired result -- the files are textually different, but describe the same content. The chip I'm using is not supported (18F6722), so I couldn't try the probably correct command line p:\>xwisp.py target 18f6722 load test.hex save test1.hex But according to the description above, this would try to locate a chip in a programmer, and having no programmer, it would fail. Correct? (Anyway, it was interesting looking at your code. Thanks :) > PS: The hex file representation for a given chip content is not unique > (line length is not fixed), so comparing with a text compare tool might > give a false indication of 'not equal'. I know. That's why I used a hex file comparison tool that is smart enough not to compare text, but the decoded binary content. > And you'd have to think about this: the erased state of a PIC flash is > all 1's. So if one hex file contains 0x3FF (14-bit core) for a certain > address, and the other hex file does not contain this address, are the > to be considered equal? There are of course a few differences like this, but they are trivial. For example, a location that is not being programmed shows up as FF in the read file, but is missing in the reference file. This is easy. I just stumbled upon the really different values in the configuration bits, until I saw that all unused bits in the reference file are one, whereas they are 0 in the read file. Thanks, Gerhard

Olin Lathrop wrote: >> If I understood you correctly, you just said that it's ok to set the >> unused bits to 0 in the hex file that is used for programming. > > No I said that it was possible, which is what you asked. Well... I kind of knew that it was possible :) > I didn't say it was a good idea. This is what I have somewhere in the back of my head. But so far I haven't seen/read/heard a reason for why not. > Not necessarily. You are making the assumption that unused bits are read > back as 0, but I don't think that is always correct. It doesn't seem to be always correct, but it is for the chip I'm working with in this case. IMO the value for those unused bits in the hex file should match whatever the chip's datasheet says they read back; that would be the easiest -- unless there is a reason for them to be 1. I couldn't find such a reason in the datasheets, but I'm not a programming expert. That's why I asked here -- where plenty of programming experts are. >> If so, is there a good reason why most (all?) header files set them to >> 1? > > Yes. For one thing this is how the predefined symbols work. This is a bit recursive: "the predefined symbols set the unused bits to 1 because that's how they work." My question is whether there's a reason besides the used programming technique for these bits to be defined to 1 -- or whether the programming technique is simply arbitrarily (and then IMO not well) chosen. > There are other reasons I do this too. I get the feeling you're playing "hide and seek" with me :) Those "other reasons" is what I asked for in my first message. I'm just trying to figure out two things: 1- What are the reasons why Microchip's "official" header files define the unused bits to values that sometimes (more often than not) do not match the values those bits have when read from the chip? This technique results in hex files that are necessarily different (when decoded into binary, and of course assuming that the chip is not write protected) when read back from the chip. So far I don't see the advantage. You indicate the specific way the symbols are defined in the header files as a reason. I beg to differ... AFAIK, the config bits are set through either config or __config assembler directives in MPASM. Both are assembler directives, and the assembler could very well use masks to set the unused "read as 0" bits to 0. They chose not to that. I wonder whether there's a reason other than "just didn't care". 2- Can it do any damage to the chip when a not used configuration bit is set to 0 in the hex file that is used to program the chip? That's the obvious question when the above remains unanswered. You said you didn't say it was a good idea, but you didn't say it was a bad idea either. I know that I'd have to maintain on my own the appropriate bit masks, but that's a different problem -- one that I have everything on my hand to decide whether it's worth it or not. >> Sorry... don't do what? > > Try to compare a HEX file for programming with one read back from a > chip. This is guaranteed to fail in some cases, like when code > protection is enabled. Well, yes, of course. Give a little bit more credit, please :) I know that I can't compare the hex file generated from what I've read back from a write-protected chip with the hex file I used for programming. I didn't try to do that. In what other cases is it guaranteed to fail? So far, there are only two things I can see: the unused configuration bits that are "read as 0" (they are 1 in the programming file, and 0 in the read file), and any unused memory locations (they may be missing in the programming file, and are set to FF in the read file). The latter is trivial to spot and pretty obvious (and could easily be solved by filling all unused locations with FF in the programming hex file for comparison purposes), the former is strange and so far the only reason I see for it are Microchip headers that do not reflect the "read" bit values from the datasheets. I'm trying to see a better reason, but is there anything to see? Gerhard

Jan-Erik Soderholm wrote: >> I know. That's why I used a hex file comparison tool that is >> smart enough not to compare text, but the decoded binary content. > > And you are sying that now ?? :-) > > You have given the impression that you where using som generic > "file/text-compare" tool, and most of the replies so far have also > assumed so. I may have given the impression (it's hard to control impressions), but I didn't say so. And I don't think the previous responders did think that (but that's something they would have to confirm or deny, of course). I also think that I did not give the impression, considering what I wrote in my first post. > That should have been told in the *first* post. Let's see... I'm citing (">>>>") from my first post: >>>> I just compared a generated hex file (used for programming) to a read >>>> hex file (retrieved from a PIC). They were identical (that was good >>>> :) [...] Given that I said they were "identical", it's already much more probable that I did /not/ use a text comparison tool, because it's unlikely that any two hex files generated by different means are textually identical. There are just too many possibilities to "say the same thing" in Intel Hex Format. But even without considering probabilities... Later in my first message, when explaining the issue this post was about, I wrote: >>>> If that's not an option, does that mean that normal hex file >>>> comparison tools are not really that useful in this scenario? Here I am explicitly talking about a "hex file comparison tool" (the exact same term I used again in the message you responded to with "And you are saying that now?"). This should have given the necessary context, even though it was not the first phrase in the message, and even though I didn't write about what type of tool I used every time I talked about comparing hex files. Don't you think so? > And then, *if* you are using a true HEX-file compare tool, what does it > matter if the programming software change the physical layout of the HEX > file from what (e.g.) MPLAB produce ? Your compare tool should take care > of that, not ? I'm not sure you read my first message. The issue is that many unused configuration bits are /read/ as 0 (as stated in the datasheet and as can easily be verified by reading such a chip), yet the Microchip header files /define/ them as 1. The consequence of this is that any hex file created from assembling sources using the standard Microchip tool chain (and most others) contains these bits with the value 1, whereas any hex file generated from reading a device contains these bits with the value 0. {Quote hidden}> This part of a post from you doesn't make sens then : > >> I don't think that many programmer softwares will alter the hex file in >> such a way just by loading and saving. This seems to be unusual (even >> though useful in this specific case). This also means that pretty much >> every generated standard PIC hex file loaded and stored back to disk by >> your programmer is different in content from the one generated by the >> assembler/compiler. > > Now, what is a "standard PIC hex file " ??? In this context (should be clear when you put the citation back into the thread context), a "standard PIC hex file" is an Intel hex file containing a program for a Microchip PIC, assembled and linked using standard Microchip tools and header files, with the processor's configuration bits defined in standard Microchip manner in the source files. > And what do you mean with "different in content" ? They have the same > *logical* content, not ? No, they don't -- if by "logical" you mean the binary image content of the decoded hex file. That's the whole point of my original post (and every post of mine in this thread since then). The unused configuration bits that are defined as "read as 0" in the datasheet (and it seems that they are the majority of the unused configuration bits) have a value of 1 in the hex file generated with standard Microchip tools and headers (and pretty much all other tools when using the header files that come with them), whereas they have a value of 0 in any hex file generated from reading a device with MPLAB/ICD2. (Maybe not in hex files generated from reading a device with other tools. It seems some PIC programmers set those locations to 1 when storing hex files -- which is, IMO, backwards. In general, I expect a hex file to contain what the programmer actually reads from the device. Let's say a rare chip defect shows itself by making that such a "read as 0" bit reads as 1... A hex file masked in such a way would not show this.) > That they might be different *physical* shouldn't matter for your > hex-file-compare tool, right ? If by "physical" you mean "textual" like in "any given binary image can be represented by a close to infinite number of different hex files", yes, it shouldn't matter -- if they were "logically" the same. But they aren't. Try it... read a chip for which you have the hex file that you programmed into it, use a hex file comparison tool (maybe http://www.fairdell.com/hexcmp/), and you'll find the following differences: 1- All locations that are not being programmed are missing in the original file, but are set to FF in the read file. Not surprising, obvious, and no problem: easy to recognize and therefore easy to ignore during comparison. 2- The configuration bits (at address 0x30'00'00). They will be different if your chip has any unused configuration bits specified as "read as 0". This I didn't expect (even though a careful comparison of the chip header files with the datasheet would of course have revealed this). The difference here is caused by Microchip's way to define the value of unused bits with their tools and headers: always 1, independently of the value these bits have when read. I find this odd, given that they don't give a reason for that, at least not to my knowledge, in either the datasheets or programming specs. Now here comes in the reason for my original post: I'm not really an expert in programming issues, and I may have easily overlooked some spec. So I figured maybe someone knows why it may be necessary to not send programming commands that have a value of 0 for these unused configuration bits. But nobody seems to know; the most concrete information so far was "I didn't say it was a good idea", with the only reason being that the header files are what they are :) My practical, immediate need is long gone; I have compared the configuration bits by mentally applying masks for the unused bits. But I generally don't like inconsistencies, and if there's one, I like to know why it's there. In this case, it just seems that nobody seems to know why Microchip made their tools and headers generate hex files that are necessarily (and "logically") different from hex files their tools generate when reading a device. Even if it is bad to try to program those bits to 0, I expect that any (decent) programmer software is aware of this and sets them to 1, even if the hex file has them set to 0. (For the verification, they need to have that "knowledge" built-in anyway.) From the feedback three programmer manufacturer gave me, it seems that this is (usually) the case. So not even that would be a good reason not to set the unused bits to their actual read value in the programming hex file. Thanks, Gerhard

Gerhard Fiedler wrote: >> Yes. For one thing this is how the predefined symbols work. > > This is a bit recursive: "the predefined symbols set the unused bits to > 1 because that's how they work." Perhaps, but you don't get to change that. The predefined symbols are ANDed together instead of ORed specifically so that unused bits stay at the default erased state of 1 instead of making them all 0. So if you want to use the predefined symbols you end up leaving unused bits 1. > My question is whether there's a reason > besides the used programming technique for these bits to be defined to > 1 -- or whether the programming technique is simply arbitrarily (and > then IMO not well) chosen. I don't know for sure, but it seems Microchip went to some trouble to make the symbols with unused bits 1 making you AND instead of OR them. The natural way would have been to set the unused bits to 0 and make symbols that need to be ORed together. I have always taken this to mean someone thought about it and chose the unusual approach because there was a good reason to do so. I've never heard a clear explanation as to why from Microchip, but I can guess at some possible reasons: 1 - There might be undocumented bits to set various test modes. 2 - It makes it more likely that a single HEX file is compatible between members of a subfamily. Some newer members of a subfamily might have some extra features, and these would default to the old way when the associated config bits are left at 1. 3 - Using AND masks allows you to specify only the features you care about because the remaining ones will have their bits set to 1, which generally means they default to off or the harmless state. I've got real work to get on with, so I don't want to be a test pilot and see whether I really can get away with setting unused bits to 0. I do assume it is safe to set the unused bits to the value they would be read back from a totally erased chip. Note that I'm not assuming all unused bits would be 0, and I'm pretty sure I remember some 18F or maybe 30F cases where some unused bits are read back as 1. Setting those to 0 is probably a bad idea. Also this has never been an issue for me. I like Jim's idea if it ever does come up. His programmer software can save a copy of a HEX file in the same format as his readback program would produce. That's a nice touch that had not occurred to me before. Since you have this problem for a single PIC, why not write a custom compare program that reads in both HEX files and applies the valid bits mask before comparing them? HEX files are easy to read. I have general purpose HEX file reading and writing routines in my STUFF library to make it even easier. My programmer software is layered on these. ****************************************************************** Embed Inc, Littleton Massachusetts, (978) 742-9014. #1 PIC consultant in 2004 program year. http://www.embedinc.com/products

Olin Lathrop wrote: > Perhaps, but you don't get to change that. The predefined symbols are > ANDed together instead of ORed specifically so that unused bits stay at > the default erased state of 1 instead of making them all 0. So if you > want to use the predefined symbols you end up leaving unused bits 1. That's correct -- but I could rather easily change that in my software (HiTech C) -- using, of course, some symbols of my own. I'm pretty sure it would be just as easy in MPASM; for example, by defining a mask for each config byte that sets the unused "read as 0" type bits to 0 and anding it with the other masks. > 1 - There might be undocumented bits to set various test modes. I've seen datasheets (not PICs) where unused bits are described with "leave alone", "don't assume anything" or the like. In the PIC datasheets I'm looking at (e.g. 18F6722), I only see "unimplemented, read as 0". But of course you're right -- I'm just saying that it would not be nice of Microchip to do that and not leave a hint about it in the datasheet. > 2 - It makes it more likely that a single HEX file is compatible between > members of a subfamily. Some newer members of a subfamily might have some > extra features, and these would default to the old way when the associated > config bits are left at 1. That's a point, in some cases. OTOH, a number of config bits default to 0, so this might just as well bite you. A review is necessary in any case. > 3 - Using AND masks allows you to specify only the features you care about > because the remaining ones will have their bits set to 1, which generally > means they default to off or the harmless state. Whether to use AND or OR masks (default 1 or default 0) has nothing to do with the state of the unused bits. They could be set to their read state in either case. > I do assume it is safe to set the unused bits to the value they would be > read back from a totally erased chip. Note that I'm not assuming all > unused bits would be 0, and I'm pretty sure I remember some 18F or maybe > 30F cases where some unused bits are read back as 1. Setting those to 0 > is probably a bad idea. I agree on that; that's why I usually wrote about "read as 0" type unused bits. For the "read as 1" type unused bits it obviously doesn't make much sense to set them to 0 :) > I like Jim's idea if it ever does come up. His programmer software can > save a copy of a HEX file in the same format as his readback program > would produce. That's a nice touch that had not occurred to me before. Yes, that's a nice if somewhat rarely needed feature. It probably would require you to store one more data set: you'd need not only the unused bit masks, but also the information about the read state of each of the unused bits (0 or 1). > Since you have this problem for a single PIC, why not write a custom > compare program that reads in both HEX files and applies the valid bits > mask before comparing them? Thanks for the offer, and thanks for publishing your work. Since I'm working mostly in C, I don't use your assembly libraries, and since for this issue my need is already gone, I won't use your hex libraries. But I appreciate nevertheless that you publish them. As I wrote in another email, I don't have to compare hex files a lot. I just found this fact a bit odd and strangely unexplained, and wanted to understand better what is going on here. Thanks for sharing your thoughts, Gerhard