Hello, I am programming a PIC in assembly and am trying to think of a way to self-verify the integrity of the code shortly after power up. I would like to store the checksum as a literal in flash or store it in the EEPROM. What would a subroutine look like that can calculate the checksum of it's own hex code, including the subroutine itself that is calculating the checksum of it's own hex code...whew... almost got myself into a paradox there! Hope you know what I mean. Is there a way for a PIC to read what execution code values are being held in its own flash? Thomas
micro self-check of checksum
Started by ●September 23, 2005
Reply by ●September 23, 20052005-09-23
Thomas Magma wrote:> Hello, > I am programming a PIC in assembly and am trying to think of a way to > self-verify the integrity of the code shortly after power up. I would like > to store the checksum as a literal in flash or store it in the EEPROM. What > would a subroutine look like that can calculate the checksum of it's own hex > code, including the subroutine itself that is calculating the checksum of > it's own hex code...whew... almost got myself into a paradox there! > > Hope you know what I mean. Is there a way for a PIC to read what execution > code values are being held in its own flash?It depends on the model. Newer ones have a way to read code space. Thad
Reply by ●September 24, 20052005-09-24
On Fri, 23 Sep 2005 21:26:04 GMT, "Thomas Magma" <somewhere@overtherainbow.com> wrote in comp.arch.embedded:> Hello, > I am programming a PIC in assembly and am trying to think of a way to > self-verify the integrity of the code shortly after power up. I would like > to store the checksum as a literal in flash or store it in the EEPROM. What > would a subroutine look like that can calculate the checksum of it's own hex > code, including the subroutine itself that is calculating the checksum of > it's own hex code...whew... almost got myself into a paradox there! > > Hope you know what I mean. Is there a way for a PIC to read what execution > code values are being held in its own flash? > > ThomasI am not familiar with PICs, and somebody already pointed out that at least some PICs can't read their code space as data. But the general idea of performing a checksum on a binary image is a pretty simple one, especially if the image is in a single contiguous chunk of memory. The easiest case of all is if the last few bytes or words of that memory are not "special", that is they don't need to hold the power up start address or an interrupt vector. First you pick a checksum algorithm, which could be a simple 8 or 16 bit sum, a CRC of some size, or something like a Fletcher checksum. For simplicity, let's assume you are going to do a simple 8-bit checksum, ignoring the overflow out of the 8 bits. Here is a simple C function that would perform the sum: unsigned char checksum(const void *start, size_t count) { const unsigned char *uc = start; unsigned char sum = 0; while (count--) { sum += *uc++; } return uc; } What you do is calculate the sum of all but the last byte of the image before you program the flash. Then you put the 2's complement of that value into the last byte of the image, and program the flash from the image. At run time you call the function with the start address of the flash and the size of the flash, including the last byte. If the flash is good, the value returned will be 0. If the validation function you prove is not easily returned to 0 by one value, calculate the value minus the last byte or word or however bit the checksum value is, then store the value itself into the last byte/word. Then at run time you call the function with the start of the flash and the size of the flash minus the last byte/word holding the sum. Compare the value returned to the contents of that last byte/word, and the flash image is good if they match. -- Jack Klein Home: http://JK-Technology.Com FAQs for comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html comp.lang.c++ http://www.parashift.com/c++-faq-lite/ alt.comp.lang.learn.c-c++ http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
Reply by ●September 24, 20052005-09-24
Thomas Magma schrieb:> Hello, > I am programming a PIC in assembly and am trying to think of a way to > self-verify the integrity of the code shortly after power up. I would like > to store the checksum as a literal in flash or store it in the EEPROM. What > would a subroutine look like that can calculate the checksum of it's own hex > code, including the subroutine itself that is calculating the checksum of > it's own hex code...whew... almost got myself into a paradox there! > > Hope you know what I mean. Is there a way for a PIC to read what execution > code values are being held in its own flash?You need an PIC that can access the code space, but this feature isn't implemented in every type. For example you can use 16F877A or 18F4550 (that if used last time). On the Microchip website, there is at least one app-note (TB026), that discusses your problem (with sample code). HTH Michael
Reply by ●September 24, 20052005-09-24
> I am not familiar with PICs, and somebody already pointed out that at > least some PICs can't read their code space as data. But the general > idea of performing a checksum on a binary image is a pretty simple > one, especially if the image is in a single contiguous chunk of > memory.Now, assuming you find an error...what do you do? You have just proven the code is not trust worthy, so you cannot rely on the code to make the system safe in any way. Or in fact do anything predictably So is the test worth while? (playing devils advocate). Regards, Richard. http://www.FreeRTOS.org
Reply by ●September 24, 20052005-09-24
Richard wrote:> > I am not familiar with PICs, and somebody already pointed out that at > > least some PICs can't read their code space as data. But the general > > idea of performing a checksum on a binary image is a pretty simple > > one, especially if the image is in a single contiguous chunk of > > memory. > > Now, assuming you find an error...what do you do? You have just proven the > code is not trust worthy, so you cannot rely on the code to make the system > safe in any way. Or in fact do anything predictably So is the test worth > while? (playing devils advocate).The principle is to put all devices in a safe state, this can be accomplished by forcing a reset and by not executing the normal code after that but instead disabling all hardware and busy looping. This is based on the assumption that there exist a safe state for the system upon failure of both hardware and software for instance in the case of a power failure.
Reply by ●September 24, 20052005-09-24
On Sat, 24 Sep 2005 16:57:53 GMT, the renowned "Richard" <nospam@thanks.com> wrote:>> I am not familiar with PICs, and somebody already pointed out that at >> least some PICs can't read their code space as data. But the general >> idea of performing a checksum on a binary image is a pretty simple >> one, especially if the image is in a single contiguous chunk of >> memory. > >Now, assuming you find an error...what do you do? You have just proven the >code is not trust worthy, so you cannot rely on the code to make the system >safe in any way. Or in fact do anything predictably So is the test worth >while? (playing devils advocate). > >Regards, >Richard.The code required to do a checksum and conditionally shut things down is probably quite compact. If you can detect and deal with 99% of single bit or single byte errors, then you will have improved the situation by 100:1. Best regards, Spehro Pefhany -- "it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
Reply by ●September 24, 20052005-09-24
"Lanarcam" <lanarcam1@yahoo.fr> wrote in message news:1127582372.465810.205740@o13g2000cwo.googlegroups.com...> > Richard wrote: > > > I am not familiar with PICs, and somebody already pointed out that at > > > least some PICs can't read their code space as data. But the general > > > idea of performing a checksum on a binary image is a pretty simple > > > one, especially if the image is in a single contiguous chunk of > > > memory. > > > > Now, assuming you find an error...what do you do? You have just proventhe> > code is not trust worthy, so you cannot rely on the code to make thesystem> > safe in any way. Or in fact do anything predictably So is the testworth> > while? (playing devils advocate). > > The principle is to put all devices in a safe state, this can be > accomplished by forcing a reset and by not executing the normal code > after that but instead disabling all hardware and busy looping. > This is based on the assumption that there exist a safe state for > the system upon failure of both hardware and software for instance > in the case of a power failure.So you are relying on code you know is corrupt to put all devices into a safe state? In fact you don't even know the code is corrupt, as if it is corrupt you don't know anything for sure, etc. You cannot even rely on it to force a reset - maybe it is the decision to reset that has the corruption. As Spehro Pefhany says, its a statistics game. You can only improve the probability of safe behaviour. Regards, Richard. http://www.FreeRTOS.org
Reply by ●September 24, 20052005-09-24
On Sat, 24 Sep 2005 16:57:53 GMT, "Richard" <nospam@thanks.com> wrote in comp.arch.embedded:> > I am not familiar with PICs, and somebody already pointed out that at > > least some PICs can't read their code space as data. But the general > > idea of performing a checksum on a binary image is a pretty simple > > one, especially if the image is in a single contiguous chunk of > > memory. > > Now, assuming you find an error...what do you do? You have just proven the > code is not trust worthy, so you cannot rely on the code to make the system > safe in any way. Or in fact do anything predictably So is the test worth > while? (playing devils advocate). > > Regards, > Richard. > > http://www.FreeRTOS.orgIt depends on the nature and requirements of the system. Some of the embedded systems I work on are safety critical, high reliability systems. In cases like these, normally there is a small boot program (sometimes called a 'BIOS') that runs at reset. It sets all outputs to a safe state (usually OFF). Then it runs an integrity test on its own image, and tests any other RAM and on-board resources that do not involve any off-board functions, including the watch dog timer hardware. If any of the critical on-board hardware fails, this is considered a system integrity error and the code puts itself in a tight loop with some sort of error indication on its LEDs or 7-segment displays. If all of the above tests pass, then the boot code runs some sort of integrity validation on the flash that holds the main application. If that fails (new board or power loss while reprogramming the application, for example), the boot code retains control and enables its host communication interface (RS-485, Ethernet, CAN, USB 2.0, depending on the product) and is ready to accept a new application download attempt. If the application image in flash validates, it is launched in place or, on larger systems, copied to DRAM and started. With a watchdog timer left running, in case the application does not start correctly. On boards with larger, 32-bit processors, there's a little more back up than this. Typically on a board like this you require large amounts of copper and parts to be working correctly at all for the processor to do anything. Its clock, data and address busses, (S)DRAM controller, (S)DRAM, and external flash must all be working correctly or nearly correctly for the processor to even run its self tests. On a board like this, we always have a secondary single chip microcontroller, that runs from internal flash (used to be EPROM) and internal RAM. All it needs to run are its clock and the power supply, no external components. The micro completes its power on self tests rather quickly, and then lets the big processor come out of reset. If the main processor does not reach the point in its boot code where it communicates with the micro within a certain time, the micro puts the main processor back into reset and keeps it there, and displays an error indication. Is this sort of system absolutely fool proof? No, nothing designed by human beings can guarantee that. It is robust enough that in thousands of safety critical systems in use for a decade that it has never let a processor or other digital or power supply fault cause an injury? Most assuredly. -- Jack Klein Home: http://JK-Technology.Com FAQs for comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html comp.lang.c++ http://www.parashift.com/c++-faq-lite/ alt.comp.lang.learn.c-c++ http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
Reply by ●September 24, 20052005-09-24
"Richard" <nospam@thanks.com> wrote in message news:lAfZe.114898$G8.40537@text.news.blueyonder.co.uk...>> I am not familiar with PICs, and somebody already pointed out that at >> least some PICs can't read their code space as data. But the general >> idea of performing a checksum on a binary image is a pretty simple >> one, especially if the image is in a single contiguous chunk of >> memory. > > Now, assuming you find an error...what do you do? You have just proven > the > code is not trust worthy, so you cannot rely on the code to make the > system > safe in any way. Or in fact do anything predictably So is the test > worth > while? (playing devils advocate).My approach is to halt, and rely on the external hardware watchdog (there *is* one, right? ;)) to reset the system. The process will repeat, and essentially keep the system in hardware reset - assuming the code integrity check occurs before anything critical is done with hardware. YMMV. Steve http://www.fivetrees.com