Hi Thorsten,

Sorry for the delay.
Did you succeeed to solve the problem ?

Looking at Raheem's problem too, I trully believe your problem is inside development board.
You wrote.....if the PC send data to the 'COMM2' on my board the RST is set automat.
I'm in doubt it really behave this way. Hence you've tried to overcome this by setting RST to high, by hand during download process. And it didn't work too.
The AT89S8252 is normally shipped with the on-chip Flash Code in the erased state (i.e. contents = FFH). If you run the blank 8252 all is doing is MOV R7, A. Not much usefull for you.
And not much movement on P1 port. When you downloaded the first program flash2.asm it was a succesfull operation. You could do this with RST state other than high level ?. The answer is NO. Thus, at that time works. What could happened then ?
Using EA (pin 31 for PDIP case) is a good idea.
Holding EA low, will force the 8252 to execute from external memory which doesn't exist in your case. This way 8252 will behave as blank device (P0 has internal pullups when configured as multiplexed low-order address/data bus).
Thus again will avoid some excitement on P1 due to the old flash2.asm
Be aware you must have nothing connected to P0 and P2 in order to use this trick.
Note, however, that if lock bit 1 is programmed , EA will be internally latched on reset, thus using EA trick is useless.
You told me you don't know if the lock bits have been programmed or not, at first download of flash2.hex. Thus I can't tell you if holding EA low will solve the problem.

Another side efects which bother you is that your mouse freeze on the PC screen during program download. If you push 8052's reset switch now, the mouse comes alive again. Don't you think that the 8052 is not held in a proper reset state ?
Because the serial programming method requires two lines, one Clock and one data you can't use only RX, TX and ground. There are plenty of output lines on RS232 interface which could be used as output and send pulses through them.
However, if your program didn't used them, and only RX, TX and ground, then your problem is the servant on the development board, the one who convert data stream from PC to target 8052 and provide RST automatic and SCK.
If the servant exists, the only reason for which mouse freeze on screen is that the PC is overwhelmed by numeruos interrupt requests from serial device. Thus some bugs in software PC which not provides a serious feedback to operators.
Though, if you know how to program threads you can avoid this easily.

Regards,
Silviu