Need a simple SW method for serial Tx/Rx error detection !!!

Go To Last Post
21 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,
I need a simple method for serial Tx/Rx error detection, but not the standard "checkSum", because:
- original data: 0x21, 0x87 -> checksum = 0xa8
- if errors: 0x20, 0x88 -> checksum = 0xa8 !!!
Hmmm, this standard checksum is not very reliable.
Also, CRC implementation is too big... I'm "squeezing" a bootloader here :?
So, something small but clever must come out! :idea:

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

Last Edited: Sat. May 7, 2005 - 04:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How much code space do you have left and how many bits can you afford to tack onto your transmissions for error detection? There are lots of options out there...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A few ideas.

You could use parity....and your above method. This reduce the probabilty of an undetected error.

CRC (normally 16 bit) is sometimes refered to as checksum....so checksum doesn't always mean "the sum". What is wrong with CRC?, the algorithm takes only few lines of code, it won't require much memory . See app note on the Xmodeem protocol

Alternative use an 8 bit CRC. But do use a standard polynomial as defined by whatever standard. e.g. LRCC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

size left = 15 words...
how many bits...? hmmm, I don't know; seems to be a hardware option. (?)
well, what options do I have? :-)

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

so, suppose I use parity... what happens when an error occurs?
getchar() will fail, I suppose.

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

parity detects single bit errors in a byte.
Can't remember exactly what is even/odd parity......but the parity bit (i.e. an extra bit) will be set/clear depending upon whether the number of 1's or 0's in that byte is odd or even. The AVR can moste likely do this for you in hardware.

Still I think you will be better using CRC which is much, much more reliable. If you are writing in C...just find a CRC algorithm off the web....e.g. as in Xmodem technote. Copy and paste......it will take up very little memory.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

not sure what will happen when there is an error in getchar. Probably returns 0 or something, should be in the manual.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

look here is a CRC algorithm....don't bother with the parity:

int calcrc (char *ptr, int count)
{
   int crc=0;
   char i;
   while (--count >= 0)
   {
      crc =crc ^ (int) *ptr++ <<8;
      i=8;
      do
      {
          if(crc & 0x8000)
              crc = crc <<1 ^0x1021;
          else
              crc = crc << 1;		
       } while (--i);
   }
   return crc;
}

Do you have enough memory?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oooops, it takes more than 30 words...
I have only 15 left...
Thx anyway :-) ...
I'll see what I can do... maybe squeeze the code again :-)

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Forgot to mention (in the above code) ptr is a pointer to the first byte of the data packet e.g. 128 bytes in X modem. Count is the number of bytes i.e. 128.

e.g.

char packet [128];
int crc;
// fill he array with the data
crc =calcrc(packet, 128);

When sending the last packet you will need to pad it to 128 bytes.
And another advantage of using the Xmodem protocol for a bootloader: compare the SPM page size to the X modem packet size!

Last Edited: Sat. May 7, 2005 - 04:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How much space do you have for the bootloader and what does it do exactly?
are you sending the .bin file over the serial port?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

space = 512w
bootloader communicates with a pc (receives the bin file -> pages for the flash).
it also uses encryption, so this is taking some memory (flash)...

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Since it is a bootloader, you want it to be fast, and reliable. To make it fast, you need small overhead... no extra bytes. To make it reliable to need to make sure it all got there... every bit of every byte right way up. One total sum of the whole binary load from start to finish would be
one way to tell if it all got there. A sum would only be wrong if there were a multiple errors during dl that just happened to miraculously cancel each other out. Probability like winning the lottery... one in 65000 or something. So just send the program, then the sum, and have the loader compute the sum after the burn, and send an ack or a nack. If its bad, just start over. This is even faster than reading it back and verifiying byte by byte.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

but if it's rs232, then the probabilty of an error is quite high.......so you could end up doing quite a few read/writes before a successful load.

Another reason why I recommend X-modem.....it provides an error free end to end connection, so all you have to do is write the received data packets to flash. You can use hyperterminal to send the .bin file too....bonus!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bob... I like the way you think! :-)
sparkymark... you are right: I am using RS232.
If I'll manage to squeeze the BL a little bit, then (maybe) I'll think about using CRC-8bit instead of the standard sum that I use right now for checking... :-)
Thx U all !
BTW: HyperTerminal is NOT very good (reliable), trust me!

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

; ### crc check of single byte
crc_calcbyte:
ldi temp1, 8 ; set the counter
ldi temp2, 0x18
crc_calcbyte_:
push temp1 ; save the counter
clr temp1 ; temp to store xor flag
sbrc crcbyte, 0 ; check lsb of crcbyte
com temp1 ; set xor flag if one
sbrc valbyte, 0 ; check lsb of value
com temp1 ; set or reset xor flag if one
sbrc temp1, 0 ; check if xor flag is set
eor crcbyte, temp2 ; xor crc with 0x18
clc
sbrc temp1, 0 ; check if flag is one
sec
ror crcbyte ; shift bit into crcbyte
ror valbyte ; shift value for next bit
pop temp1 ; get counter from stack
dec temp1 ; counter--
brne crc_calcbyte_ ; do next bit
ret ; done

my crc code for the dallas crc check, you could shorten it, by removing interrupt disable stuff, and use an extra var

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

>but if it's rs232, then the probabilty of an error is quite high.......
================================
Come on Sparky..... there aint no errors in rs232... I used to edit on a vt100 terminal on a vax on a 1000 ft line at 38400 and never saw a bad character..... error rate had to be less than one bad char in billions and billions (rest in peace Carl)

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Bob, I've got quite a bit of time invested in my HyperTerminal scheme...

I've heard a lot of complaints regarding HyperTerminal. Personally, I don't see a problem with it. It's on every windows based machine and can be an extreemly handy troubleshooting tool. I suppose that once I start trying file transfers using HyperTerminal some of the less desirable issues may surface, but that's a ways off.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Come on Sparky..... there aint no errors in rs232... I used to edit on a vt100 terminal on a vax on a 1000 ft line at 38400 and never saw a bad character..... error rate had to be less than one bad char in billions and billions (rest in peace Carl)

Depends how closely you can generate the baud rate. If you use a 16Mhz crystal you can't perfectly generate 38400. Some data sheets show a table of error probability from clk frequency vs baud rate. I think (can't remember where it is right now) with a 16MHz crystal the error probability becomes significant (i.e. about 1%) above 38400.

Anyway what's wrong with Xmodem? It's simple enough, and easily fits in the bootloader space of most devices? It's standard, which IMHO is better then inventing your own protocol. The packet size is 128 bytes, i.e. very convenient since the SPM page size is either 128 or 256...

Also why does everyone dislike hyperterminal. The backscroll on hyperterminal is rubish......(i.e. unreliable garbage) but capture text to file works fine. Also, the Xmodem protocol works very well and hyperterminal is convenient to use since it comes with windows.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have kept a copy of the old Windows Terminal program that came with W3.11 and have never had any problem with it (except its max speed). There are lots of assorted comms programs available - It's horses for courses.
C.H.

C. H.
-------------------------------------------------------------------
It's only waste if you don't use it!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm using HyperTerminal at 115.2, through an FTDI virtual comport with no data loss. The AVR clock is 16 MHz, and I have no hardware, or software handshaking taking place either. I have no data loss, even what up and running for many hours at a time.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston