Hi,

I started reading about parity, flow control and all that jazz, but I am clued out as to how to deal with dropped/corrupt serial frames. The articles say that checking parity doesn't 100% solve all the problems. I am currently using 9600, n , 8, 2.

My program uses asynchronous serial communications by bit-banging the 8085 serial port. It works fine, but I found one serial frame for one character that didn't work from the teraterm log. P (50 hex) in Press shows up blank in the Teraterm log and in Teraterm it is missing.

Any suggestions on how to correct the issue would be appreciated.
-Kei

Teraterm Log (with binary set)


Teraterm Window


8085 Assember Code

# ORG 00A3H
# DB DATA:20H,0DH,0AH,57H,65H,6CH,63H,6FH,6DH,65H,20H,74H,6FH,20H,74H,68H,65H,20H,38H,30H,38H,35H,20H,4DH,6FH,6EH,69H,74H,6FH,72H,0DH,0AH,50H,72H,65H,73H,73H,20H,68H,20H,66H,6FH,72H,20H,68H,65H,6CH,70H,0DH,0AH,3EH

# ORG 00D6H
# DB DATA:0DH,0AH,38H,30H, 38H, 35H, 20H, 4DH, 6FH, 6EH, 69H, 74H, 6FH, 72H, 20H, 48H, 65H, 6CH, 70H, 0DH, 0AH,4CH, 65H, 67H, 65H, 6EH, 64H, 3AH, 20H, 78H, 78H, 78H, 78H, 68H, 20H, 73H, 74H, 61H, 72H, 74H, 69H, 6EH, 67H, 20H, 6DH, 65H, 6DH, 6FH, 72H, 79H, 20H, 61H, 64H, 64H, 72H, 65H, 73H, 73H, 2CH, 20H, 78H, 78H, 68H, 2CH, 20H, 79H, 79H, 68H, 2CH, 20H, 7AH, 7AH, 68H, 2CH, 2EH, 2EH, 2EH, 20H, 64H, 61H, 74H, 61H, 0DH, 0AH,0DH,0AH,77H,20H,78H,78H,78H,78H,68H, 20H, 78H, 78H, 68H, 2CH, 20H, 79H, 79H, 68H, 2CH, 20H, 7AH, 7AH, 68H, 2CH, 20H, 2EH, 2EH, 2EH, 20H, 77H, 72H, 69H, 74H, 65H, 20H, 64H, 61H, 74H, 61H, 20H, 74H, 6FH, 20H, 52H, 4FH, 4DH, 0DH, 0AH,72H, 20H, 78H, 78H, 78H, 78H, 68H, 20H, 78H, 78H, 68H, 2CH, 20H, 79H, 79H, 68H, 2CH, 20H, 7AH, 7AH, 68H, 2CH, 20H, 2EH, 2EH, 2EH, 20H, 72H, 65H, 61H, 64H, 20H, 64H, 61H, 74H, 61H, 20H, 66H, 72H, 6FH, 6DH, 20H, 52H, 4FH, 4DH, 0DH, 0AH,65H, 20H,78H, 78H, 78H, 78h,68H, 20H, 20H, 20H, 20H, 20H, 20H, 20H, 20H, 20H, 20H, 20H, 20H, 20H, 20H, 20H, 20H, 20H, 20H, 20H, 20H, 65H, 78H, 65H, 63H, 75H, 74H, 65H, 73H, 20H, 74H, 68H, 65H, 20H, 70H, 72H, 6FH, 67H, 72H, 61H, 6DH, 20H, 61H, 74H, 20H, 78H, 78H, 78H, 78H, 68H, 0DH, 0AH,73H, 20H, 20H, 20H, 20H, 20H, 20H, 20H, 20H, 20H, 20H, 20H, 20H, 20H, 20H, 20H, 20H, 20H, 28H, 72H,65H,73H,65H,74H,29H, 20H, 65H, 78H, 65H, 63H, 75H, 74H, 65H, 73H, 20H, 74H, 68H, 65H, 20H, 70H, 72H, 6FH, 67H, 72H, 61H, 6DH, 20H, 61H, 74H, 20H, 30H, 30H, 30H, 30H, 68H, 0DH,0AH,3EH

# ORG 01FDH
# DB DATA:0DH,0AH,7CH,5CH,2DH,2DH,2DH,2FH,7CH,0DH,7CH,20,6FH,5F,6FH,20,7CH,0DH,20,5C,5F,5E,5F,2FH,0DH,0AH,3EH



# ORG 0000H
LXI SP,7FFFH
INITIALIZE: MVI D,00H
MVI E,33H
LXI H,00A3H

START: PUSH H
MOV C,M
CALL COUT
POP H
INX H
DCX D
PUSH PSW
MOV A, D    ; MOVE THE CONTENT OF REGISTER D INTO THE ACCUMULATOR A
ORA E       ; LOGICAL OR OPERATION WITH REGISTER E

JNZ START
POP PSW
MENU: CALL CIN
   CPI 68H                  
   JNZ DEMO
   CALL HELPPARM
   JZ START
   DEMO: CPI 64H
   JNZ RESET
   CALL DEMOPARM
   JZ START
   RESET: CPI 73H
  JNZ MENU
  JMP INITIALIZE
HLT

COUT:
   DI
   MVI B,0B    ; NUMBER OF OUTPUT BITS
   XRA A    ; CLEAR CARRY FOR START BIT

   CO1: MVI A,80    ; SET THE SDE FLAG
   RAR    ; SHIFT CARRY INTO SOD FLAG
   CMC    ; AND INVERT CARRY. WHY? (SERIAL IS INVERTED?)
   SIM    ; OUTPUT DATA BIT
   LXI H,0112    ; LOAD THE TIME DELAY FOR ONE BIT WIDTH

   CO2: DCR L    ; WAIT FOR BIT TIME
   JNZ CO2
   DCR H
   JNZ CO2
   STC    ; SHIFT IN STOP BIT(S)
   MOV A,C    ; GET CHAR TO SEND
   RAR    ; LSB INTO CARRY
   MOV C,A    ; STORE ROTATED DATA
   DCR B
   JNZ CO1    ; SEND NEXT BIT
   EI
   LXI H,3FFF    ; WAIT A WHILE BEFORE SENDING THE CHARACTER AGAIN

   CHILL: DCR L
   JNZ CHILL
   DCR H
   JNZ CHILL
RET

CIN:
   DI
   PUSH B
   MVI B,09        ; LOOP COUNT IS NUMBER OF BITS TO BE READ MINUS ONE
   CI1: RIM                     ; DOES NOT INCLUDE STOP BITS
   ORA A
   JM CI1
   LXI H,0109H      ; DELAY A HALF BIT TIME TO GET TO THE MIDDLE OF THE START BIT
   CI2: DCR L
   JNZ CI2
   DCR H
   JNZ CI2
   CI3: LXI H,0112H       ; DELAY TO THE MIDDLE OF THE NEXT DATA BIT
   CI4: DCR L
   JNZ CI4
   DCR H
   JNZ CI4

   RIM                     ; READ THE NEXT DATA BIT
   RAL                     ; SHIFT THE DATA BIT INTO THE CARRY FLAG
   DCR B               ; EXIT IF ALL OF THE BITS HAVE BEEN READ
   JZ CI5
   MOV A,C             ; CHARACTER IN PROGRESS INTO A
   RAR                     ; SHIFT THE DATA BIT FROM CARRY INTO THE MSB
   MOV C,A             ; STORE THE CHARACTER BACK INTO C
   JMP CI3             ; GET THE NEXT BIT

   CI5: MOV A,C             ; RETURN THE CHARACTER IN A
   POP B
   EI
RET

HELPPARM:
   LXI H,00D6H
   MVI D, 01H
   MVI E, 27H
RET

DEMOPARM:
   LXI H,01FDH
   MVI D, 00H
   MVI E, 21H
RET

 

Why do some of your values for your constants have the 'H' suffix and some don't? That may or may not be the issue, but it's sloppy programming at the very least.

 

Thanks, WBahn, I will add the H's but they were missing in the CAT pic, not the welcome phrase.

Andrew.

 

Thanks, WBahn, I will add the H's. I has asked chatgpt to put the H's for me...

Can chatgpt find the solution to framing errors too?

 

Seems to happen after the CR/LF characters. For a simple test, swap those 2 sentences around to see if it is the 50 that is messed up, or the position of the sentences. If it is a coding issue, then the second (other) sentence will get its first character dropped. If it is related to the "50" character, then something in the code is trapping with that specific character.
Or, try a different second sentence, one without the 50 ("P") to diagnose where the problem is.

Most framing errors are due to incorrect baud clock rate, sometimes just a few clock cycles off may cause the problem. Or, some error in character formation with start/stop bits.

 

Seems to happen after the CR/LF characters. For a simple test, swap those 2 sentences around to see if it is the 50 that is messed up, or the position of the sentences. If it is a coding issue, then the second (other) sentence will get its first character dropped. If it is related to the "50" character, then something in the code is trapping with that specific character.
Or, try a different second sentence, one without the 50 ("P") to diagnose where the problem is.

Most framing errors are due to incorrect baud clock rate, sometimes just a few clock cycles off may cause the problem. Or, some error in character formation with start/stop bits.

Hi All, thanks for all your suggestions, but I did some investigation and it seems to happen in random places after re-writing the NVRAM that I use. For instance after trying 2400 baud instead of 9600 in my program, the "P" in "Press" is back but the "i" in starting is missing - checking the Teraterm logs with binary output gives that the "i" was interpreted as a FFh (incorrect ASCII value). I went back to 9600 baud and this still occurs. I checked the NVRAM contents and they are correct. This leads me to believe that there are no coding errors and they are just framing errors. I have tried other monitors, for example: MON85 Dave Dunfields Diagnostic Monitor – SBC-85 and they work fine, with the exception of the first character being incorrect after pressing the hardware reset button, which also occurs with my circuit, so I think the solution is to just make CIN and COUT more robust. As a work-around I just put a space (20h) character as my first character in the welcome message and let it become corrupted after pressing the hardware reset button.

Sagor you had mentioned errors. Also, Intel's AP-29 8085 Serial I/O Lines Application Note does give the error rates for each baud rate on Page 7, Table 1 and the error rate is higher as the BAUD rate increases: .

- Kei