1. Home
  2. Embedded Programming
  3. DS89C450 serial problem

DS89C450 serial problem

I am having serial port communications problems. Below is the simple code in the DS89C450 MCU that I am trying to get to work properly. It is a simple routine to receive data via the serial port at 38400baud. I am trying to receive 65536 bytes. It allways drops some of the data like it is falling behind the serial stream. Most the time the 1st 1000 bytes seem fine then one is missed and the data in memory is short a byte. This happens many times after the 1st 1k bytes. I am using Visual C++

6.0 as my pc software to send data from the pc to the DS89C450. I did find that I had to buffer the ALE line to the latches for more reliability. Do I need to buffer the WR & RD also or add pull-ups on other pins? According to the data sheet the Address/Data lines dont need pull-ups if thats all there used for. My MCU circuit is very simple and uses 1-DS89C450MNL, 2-74F573 latches for address, 1-IS62C1024AL-35 Ram, 1-74HCT32 used as a buffer for ALE, 1-MAX233CPP Rs232. I have A16 tied low on Ram chip. If I insert a 1ms delay between characters sent by the pc, it works fine. But that defeats the speed-up in communications. I can verify that data is missing by dumping the memory contents with another routine in the micro to send the last 256 bytes of memory. Out of 65536 bytes there is 7 bytes missing.

------------------------------------------------------------------------------

This is the code inside the DS89C450 MCU running at 29.491mhz

pcon equ 87h ;address of PCON register scon1 equ 0c0h ;address of SCON1 register sbuf1 equ 0c1h ;address of SBUF1 register wdcon equ 0d8h ;address of WDCON register ckcon equ 8eh ;location of clock control org 0000h ljmp start

org 100h ;allways start ROM program at 0100h start: mov scon,#50h ;set serial port 0 to mode 1 with rec enabled mov tmod,#20h ;set timer 1 as auto-reload 8-bit timer mov th1,#0feh ;baud rate equals 38400b at 29.491mhz w/smod=0 mov ie,#80h ;do not enable serial interupt mov tcon,#40h ;start timer 1 setb ea ;global enable interrupts setb p3.6 ;set pull-up on WR setb p3.7 ;set pull-up on RD clr ri ;ensure that receive interupt flag is cleared clr ti

loop: jnb ri,loop mov a,sbuf clr ri cjne a,#01h,chka ;01 = get job data from pc ljmp getst chka: ljmp loop

; ; ***** Get track / sector data from PC ***** ; getst: clr p1.0 ;set RomA16 false clr p1.4 ;set RamA16 true setb p1.2 ;disable ROM clr p1.3 ;enable RAM mov r1,#00h mov dptr,#0000h getst1: mov r2,#00h getst2: jnb ri,getst1 ;wait for char from pc mov a,sbuf clr ri movx @dptr,a inc dptr djnz r2,getst2 djnz r1,getst1 ;get 65536d bytes ff x ff ljmp loop

Reply to
Ed
Loading thread data ...

At this speed and that amount of data, it seems like getting 'out of sync'. I've no expertise with DS89C450 but make sure that the oscillator is right to match rs232 timings.

Yes, but 1ms is a lot of time @38400. If you're sure you can transmit blocs of 1k without a problem, then try a 0.2ms pause (+/- 1 byte) each 1k bytes. So the receiver can sync on the startbit again.

[snip code] 
--
Kris.
Reply to
Kris Peeters

Are you sending two stop bits ? - if not, change to two stop-bits and re-test.

-jg

Reply to
Jim Granville

...

This ought to be getst2: jnb ri,getst2, right?

Jorgen

Reply to
Schjaer

Yes, I noticed that too and fixed that in the version I uploaded to MCU.

Reply to
Ed

No, you are having software design problem. Serial port is not designed for error free communications of

64K without handshaking. Breaking it down in 256 to 1K blocks with ACKs/NAKs. There are many different schemes to do so, with in sequence and out of sequence handshaking.
Reply to
linnix

That is nonsense. One of my standard test for the NMEA multiplexers I produce is to run 4Mbyte of data through the units in one continuous stream. That test runs for over two hours (running at 4800 baud) and it never fails. Not a single bit gets corrupted. The same file transferred at 38400 also runs fine. I have also made digital camera's in the past that transferred the entire image of 110kbyte in one go. No problem either. Mind you: the receiving end was a 486/66 with a tweaked serial card (crystal changed) capable of running 375kbit/s. The receive loop was interrupt driven and written in turbopascal. I did have to stop the PC's timer interrupt though....

Meindert

Reply to
Meindert Sprang

NEMA is line based, non critical format. You drop a bit and it won't affect the next line.

You are using framing protocols with less than 1K blocks. Your handshaking is just dropping error block.

Poorly designed system works sometimes as well. The OP already established that it does not work for his hardware.

Reply to
linnix

Yes, but he has low failure rates, and I think he is bitten by the fault in some 80C51's where they do not start looking for START edge until the END of the stop bit - the 'correct' place to start looking for the START is after the middle of the stop bit.

That's a HW design oops, and you can solve it by simply sending two stop bits form the PC end; without that, you can get baud creep issues, and around 1 byte in 1000, matches that type of problem.

-jg

Reply to
Jim Granville

No, but the line with the dropped it is affected. My test showed no missing lines. Besides, I sent the lines without delays between them which means that one missing bit will de-sync the receiving end forever.

stream.

fails.

Yes, but there were no dropped blocks.

Meindert

Reply to
Meindert Sprang

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.