R1861: 8051 UART send data problem

I'm testing 8051‘s UART.

I found that in I51Usart::configureA()

Code:


void I51Usart::configureA( uint8_t val ) //SCON
{
    uint8_t mode = val >> 6;
    if( mode == m_mode ) return;
    m_mode = mode;

    m_sender->enable( true );


m_mode is inited to 0xFF in UsartModule's constructor. So  it  works in the first simulation. But I51's UART will NEVER get configured ( and sender enabled)  in later simulations, since m_mode is already set to 1 and will always equal to mode. I'm not sure if only 8051 have this problem.

Another question: how to use a Serial Port Component to send data to other components? I can't watch Youtube...

It seems that the "send text" inputbox sends data to the Serial Port's Rx, not Tx.

Problem 3:
I added qDebug() in UartRx::runEvent(), and count its run time.
It seems that it's called 11 times for each dataframe( 10 sendbit() + 1 frameSent() ), which means the end bit costs two runEvent() call. Is it a bug?

P4:
I add qDebug() to UartRx::voltChange(), readBit() and rxEnd(), and UartTx::sendBit() and frameSent().

It seems that 8051 Tx's sendbit() triggered SerialPort Rx's voltChange, but the first readBit() is scheduled after Tx's frameSent().

I'm not sure where's the problem.

SerialPort's baud rate : 4800

8051's main freq is 11.059M, SCON=0x50, SMOD=0, and timer 1 in mode 2 with TH1 set to 0xFA.

It seems that when generate baud rate using timer 1, we should trigger one sendbit()/receivebit()  every 32/16 timer 1 overflow (depends on the SMOD flag bit in PCON):

m_mode is inited to 0xFF in UsartModule's constructor. So  it  works in the first simulation. But I51's UART will NEVER get configured ( and sender enabled)  in later simulations, since m_mode is already set to 1 and will always equal to mode.

Solved at Rev 1965.

Another question: how to use a Serial Port Component to send data to other components?

Serial Port is not meant to send data, just to connect to a Serial Port in your PC.

You can send data to the MCU from it's own Serial Monitor, but it does not use Rx Tx pins it sends the data directly.
Somewhere I have a Serial Terminal made as an Scripted Component, but still needs some work to make it configurable, I will try to finish it.

Problem 3:
I added qDebug() in UartRx::runEvent(), and count its run time.
It seems that it's called 11 times for each dataframe( 10 sendbit() + 1 frameSent() ), which means the end bit costs two runEvent() call. Is it a bug?

First and Last event are at period/2:
if( m_period ) Simulator::self()->addEvent( m_period/2, this ); // Shedule reception
if( m_state == usartRXEND ) Simulator::self()->addEvent( m_period/2, this );

This way sampling happens in the middle of a period.

P4:
I add qDebug() to UartRx::voltChange(), readBit() and rxEnd(), and UartTx::sendBit() and frameSent().

It seems that 8051 Tx's sendbit() triggered SerialPort Rx's voltChange, but the first readBit() is scheduled after Tx's frameSent().

I can't reproduce this.
When controlled by Timer readBit() is not sheduled, it is called (indirectly) by the Timer.

It seems that when generate baud rate using timer 1, we should trigger one sendbit()/receivebit()  every 32/16 timer 1 overflow (depends on the SMOD flag bit in PCON):

Ok, I will have a look.

Edited las post due to typos and added some information...

royqh1979 wrote:It seems that when generate baud rate using timer 1, we should trigger one sendbit()/receivebit()  every 32/16 timer 1 overflow (depends on the SMOD flag bit in PCON):

Which datasheet are you using?
Original Intel 8051 datasheet doesn't even have a PCON register.

arcachofo wrote:
Which datasheet are you using?
Original Intel 8051 datasheet doesn't even have a PCON register.

http://web.mit.edu/6.115/www/document/8051.pdf

PCON is on page 2-11.

The image I posted before is extracted from page 3-16.

UART Baudrate when driven from Timer 1 fixed at Rev 1967.

Frequently I spend several hours to understand the datasheet (if I find a correct one) and a few minutes working in the code...

I was scratching my head with this part of the formula: 2 SMOD / 32
So if SMOD = 0, then baudrate = 0 ???

Until I realized that in section "Using Timer 2 to Generate BaudRates" there is an scheme of the actual circuit for Timer 1 and I could understand how it works:



The formula could be something like: (1+SMOD)/32
If SMOD = 0 then 1/32.
If SMOD = 1 then 2/32 = 1/16.

Or even better just explain how UART Mode 1 actually works:
- UART clock works at 1/16 Timer1 overflow.
- SMOD = 0 adds an 1/2 divider.
- SMOD = 1 bypass the 1/2 divider.


The datasheet I have don't even have a PCON register and UART always work at 1/32 Timer 1 overflow:

arcachofo wrote:UART Baudrate when driven from Timer 1 fixed at Rev 1967.

Frequently I spend several hours to understand the datasheet (if I find a correct one) and a few minutes working in the code...

I was scratching my head with this part of the formula: 2 SMOD / 32

The formula could be something like: (1+SMOD)/32
If SMOD = 0 then 1/32.
If SMOD = 1 then 2/32 = 1/16.

Or even better just explain how UART Mode 1 actually works:
- UART clock works at 1/16 Timer1 overflow.
- SMOD = 0 adds an 1/2 divider.
- SMOD = 1 bypass the 1/2 divider.

Yeah, I was also wondering how this formula works for a while, until I realized that SMOD is a superscipt and what it means is power(2,SMOD)...

It seems that in R1967 SMOD is not checked? and 1/32 part is not implemented?

And one more thing, runEvent() will run 11 times to receive a 10bit dataframe. This could be a problem for a timer driven UART.

Yeah, I was also wondering how this formula works for a while, until I realized that SMOD is a superscipt and what it means is power(2,SMOD)...

Yes, that makes sense.

It seems that in R1967 SMOD is not checked? and 1/32 part is not implemented?

No, still trying to make it work without SMOD.
There is something very wrong when I run the debugger...

And one more thing, runEvent() will run 11 times to receive a 10bit dataframe. This could be a problem for a timer driven UART.

10 readBit() + 1 rxEnd(), I don't see a problem here by now.
And using 2 8051 is working for me.
But I'm still having problems with baudrate.

There is something very wrong when I run the debugger...

My fault, I don't know why but this is correct in Asem-51:

Code:

    MOV P3, #255
    MOV SCON, #40H ; UART mode 1, receiver disabled
    MOV TMOD, #20H ; Timer 1 in mode 2
    MOV TH1, #253 ; Reload value in TH1 to generate a baud rate of 9600
    SETB TR1        ; start Timer 1

But this is not correct:

Code:

    MOV P3, #FFH
    MOV SCON, #40H ; UART mode 1, receiver disabled
    MOV TMOD, #20H ; Timer 1 in mode 2
    MOV TH1, #FDH ; Reload value in TH1 to generate a baud rate of 9600
    SETB TR1        ; start Timer 1

Now baudrate is generated correctly, but SMOD is not implemented yet.

SMOD working at Rev 1968.

Now we can start to see this issue (and any other):

And one more thing, runEvent() will run 11 times to receive a 10bit dataframe. This could be a problem for a timer driven UART.

R1868 problem:
if PCON is not set in the mcu program, m_smodval will not get initialized.
Then the real bauds of 8051 UART would be ramdom.

arcachofo wrote:
10 readBit() + 1 rxEnd(), I don't see a problem here by now.
And using 2 8051 is working for me.
But I'm still having problems with baudrate.

Yes, I've tried and both can work. I'm wondering why. But I see no reason to wait some time to process rxEnd(), since the start of next receive don't depend on it.

Patch for R1868.
Issues tries to fix:
- if PCON is not set in the mcu program, m_smodval will not get initialized.
Then the real bauds of 8051 UART would be ramdom.
- sender/receiver not correctly reset if the mcu is hard reset. After hard reset ( not restart the circuit) , the mcu may not correctly send out bits.

Yes, I've tried and both can work. I'm wondering why. But I see no reason to wait some time to process rxEnd(), since the start of next receive don't depend on it.

Ok, solved at Rev 1970.

- if PCON is not set in the mcu program, m_smodval will not get initialized.
Then the real bauds of 8051 UART would be ramdom.

Yes, m_smodval should be initialized just in case.
Solved at Rev 1969.

- sender/receiver not correctly reset if the mcu is hard reset. After hard reset ( not restart the circuit) , the mcu may not correctly send out bits.

This should not be a problem.
At reset all registers are written to it's reset value which will disable and set m_state = usartSTOPPED.

arcachofo wrote:

- sender/receiver not correctly reset if the mcu is hard reset. After hard reset ( not restart the circuit) , the mcu may not correctly send out bits.

This should not be a problem.
At reset all registers are written to it's reset value which will disable and set m_state = usartSTOPPED.

Nop. In R1964 reset the whole ram with 0 will not trigger registers watch.
The reason is that:
SCON is 0x98 and SBUF 0x99. If fill ram with 0 trigger watch, then
SCON will trigger UART sender enable(), and then SBUF will trigger a send.

Code:


void DataSpace::initialize()
{
    for( uint i=0; i<m_dataMem.size(); i++ ) m_dataMem[i]=0;

    for( QString regName : m_regInfo.keys() )  // Set Registers Reset Values
    {
        regInfo_t regInfo = m_regInfo.value(regName);
        if( regInfo.resetVal != 0 )
        {
            writeReg( regInfo.address, regInfo.resetVal, false );
            m_dataMem[regInfo.address] = regInfo.resetVal;
        }
    }
}


It seems that this break something?

Then a suggestion: add a prop "noinit" to SBUF.
And only writeReg for registers that don't have this prop.

Maybe I didn't understand correctly, but this seems another problem:

SCON will trigger UART sender enable(), and then SBUF will trigger a send.

As I understand this will happen even with your patch and requires some other solution.

Or am I missing something?

arcachofo wrote:Maybe I didn't understand correctly, but this seems another problem:

SCON will trigger UART sender enable(), and then SBUF will trigger a send.

As I understand this will happen even with your patch and requires some other solution.

Or am I missing something?

In the current version, only registers that has a non-zero value will trigger watch.

So my suggestion now is add a "noninit" prop and only registers that has the prop don't trigger watch.

In the current version, only registers that has a non-zero value will trigger watch.

Yes I was missing that:

Code:

if( regInfo.resetVal != 0 )

Seems that we need to revert R1964 and find some other solution.

The original cause of this problem is that 8051 UART Tx is enabled from the beginning.
Let me think a bit and see if there is some other solution instead adding a new property for all registers.

arcachofo wrote:

In the current version, only registers that has a non-zero value will trigger watch.

Yes I was missing that:

Code:

if( regInfo.resetVal != 0 )

Seems that we need to revert R1964 and find some other solution.

The original cause of this problem is that 8051 UART Tx is enabled from the beginning.
Let me think a bit and see if there is some other solution instead adding a new property for all registers.

en...Sorry but Let me return to the origin problem: Reset mcu (not the circuit) won't reset the sender.

in UartTX::enable, reenable it won't reset m_state to usartSTOPPED or usartIDLE... So the mcu will send what's left in the last run immediately after reset and timer 1 is enabled.

So we need to do a reset manually, or remove the test "if( enabled == m_enabled ) return;" ?

Code:


void UartTx::enable( uint8_t en )
{
    bool enabled = en > 0;
    if( enabled == m_enabled ) return;
    m_enabled = enabled;
    m_runHardware = m_ioPin->isConnected();//   ->connector();

    if( enabled ){
        m_state = usartIDLE;
        m_ioPin->setOutState( true );
    }
    else m_state = usartSTOPPED;
}


Think that R1964 will be reverted.
That change could indeed cause some other problems in other places.

So I think we need a solution that doesn't enable the sender at reset but later... or something like that.

Check R1973:
Sender is enabled at first write to SBUF.

Not sure if there is still some other issue, but this fixes the wrong byte sent at reset.