EK-TM4C1294XL: Setup two EKs

I too hope that the vendor can & will respond.

Perhaps in the future - you may note the requirement for, "Only Vendor Response!" - which would have "saved" my time/effort in your behalf!    It is notable that ALL of my points were dismissed (minus any thanks)  - it is expected that vendor will ask for (similar) clarification...     Your post "begs" for a clear diagram - which may add (some) "very required" clarity...

Let the record show that (newly) introduced "handshaking" (reportedly) works fine - yet there is NO clear confirmation of (normal) UART Data-Transfer Success!     (i.e. Krazy-Making)

KISS - like "LIKE" (both banned here) directs you to employ simple "8 Bit UART Mode" - insure that works well - prior to entering the "9 Bit Swamp."     (which some (promise) to drain...)

My friend - you (suddenly - and w/out explanation) used the word "handshaking" - always & only (earlier) you wrote,

"I have not seen the uart outputs"
and
"the only byte I see on PuTTY is the transmitted byte."

Thus - should we not question your NEW use of  "handshaking" which was unexplained?       (and most usually - denotes a single bit which toggles to confirm operation.)

Did you mean - instead - to write that you NOW are able to "see" the RX UART's transmitted byte?     Or - is it just the "LEDs" which are responding - and STILL no UART_RX transfer?      That's not at all clear - and has caused my (proper) comment. 

Priya Nadathur70 said:

I used 8 bit mode.

Good that - follows "KISS" - surely your best path to success.    (and was suggested by myself & others)

Priya Nadathur70 said:

I transmitted 0x50 and acknowledged with 0x05.

Now this is good news - yet you described this (first time, byte transmit SUCCESS) as "handshaking!"     (technically it is - but was too vague to be useful and "broke from your past UART BYTE" descripitions.)

It is hard enough to "diagnose tech issues remotely" - introducing brand new terms (i.e. handshaking) - minus (any) explanation - is NOT in your best interest...

The fact that "8 Bit Mode is working" (as was suspected) now provides (some) confidence in your interconnects & (programming of both MCUs) - and should "set the stage" for your "9 bit exercise."

As I see it - you are best advised to (for now) abandon any thought of UART_RX "responding" to UART_TX" - instead simply have UART_RX (continually) output chars. @ 1Hz (first in 8 bit mode to confirm the code change) and once that's been confirmed - only then "Switch to 9 Bit Mode" - and determine if PuTTY recognizes such data...     This is a perfect illustration of "KISS" (one step at a time) which best speeds & insures your project's success!

cb1_mobile said:

- only then "Switch to 9 Bit Mode" - and determine if PuTTY recognizes such data...    

Does Putty deal well with 9 bit data? We've had indication in the past here that it does not and most terminal emulators don't.

Robert

It is STILL URGED - independent of PuTTY's performance - that you NOT, "Hold the 9 Bit Mode HOSTAGE" to a, "Command-Response" type of operation.

As earlier advised - enabling the UART_RX device to simply, "Continually Output - at ~1Hz" (via a change to your existing "UART_RX" program) eliminates any such "hostage holding!"     As always - such complies w/"KISS" - which proves always helpful and speeds/eases your path to success...   (even though - and especially though - this powerful "KISS" technique is never mentioned - nor promoted - here!)    And users - left to their "unguided, overly broad instincts" continue to flounder...

For now - have your "UART_RX" continually output "9 Bits" - with NO DEPENDENCE upon RECEIVING DATA from your UART_TX!     Note that you "MUST CHANGE YOUR CODE SO THAT UART_RX CONTINUALLY OUTPUTS A CHAR - WITH NO OTHER CONDITIONS!    (I do not know how to make that more clear!)

This "frees" UART_RX from unwanted complexity - at this early stage. You simply seek to output "9 Bit UART" - which can be viewed on a scope (for sure) and iirc - (sometimes) upon a serial terminal. (we've done such - I cannot recall which terminal, though)

It is HARD to know how you fail to characterize the earlier writing, (in bold) "Continually Output - at ~1Hz" as "beyond plain English."

Remember that not all bytes are received in 9-bit mode

'123 Manual said:

13.3.7 9-Bit UART Mode

The UART provides a 9-bit mode that is enabled with the 9BITEN bit in the UART9BITADDR register. This feature is useful in a multi-drop configuration of the UART where a single master connected to multiple slaves can communicate with a particular slave through its address or set of addresses along with a qualifier for an address byte. All the slaves check for the address qualifier in the place of the parity bit and, if set, then compare the byte received with the preprogrammed address. If the address matches, then it receives or sends further data. If the address does not match, it drops the address byte and any subsequent data bytes. If the UART is in 9-bit mode, then the receiver operates with no parity mode. The address can be predefined to match with the received byte and it can be configured with the UART9BITADDR register. The matching can be extended to a set of addresses using the address mask in the UART9BITAMASK register. By default, the UART9BITAMASK is 0xFF, meaning that only the specified address is matched.

When not finding a match, the rest of the data bytes with the 9th bit cleared are dropped. If a match is found, then an interrupt is generated to the NVIC for further action. The subsequent data bytes with the cleared 9th bit are stored in the FIFO. Software can mask this interrupt in case μDMA and/or FIFO operations are enabled for this instance and processor intervention is not required. All the send transactions with 9-bit mode are data bytes and the 9th bit is cleared. Software can override the 9th bit to be set (to indicate address) by overriding the parity settings to sticky parity with odd parity enabled for a particular byte. To match the transmission time with correct parity settings, the address byte can be transmitted as a single then a burst transfer. The Transmit FIFO does not hold the address/data bit, hence software should take care of enabling the address bit appropriately.

Robert

Priya Nadathur70 said:

I also have a 1 second periodic timer on EK2 independently transmitting byte 0x10b. No activity at all on U5Tx, just a high voltage level on the scope.

This appears to be your acceptance of my suggestion - "Generate 9 Bit UART Output - WITHOUT ANY DEPENDENCY AT ALL - ESPECIALLY "DATA RECEIPT!"     Is this the case?

Note that "0x10b" does NOT require 9 bits - might this compromise 9 Bit output?   (doubtful - but can be quickly tested/resolved.)

I would quickly switch to 8 Bit UART Output - and see if the scope (then) reveals "normal" UART Output.    If so - do report...

Priya Nadathur70 said:

I also have a 1 second periodic timer on EK2 independently transmitting byte 0x10b. No activity at all on U5Tx, just a high voltage level on the scope.

Why would you expect any? That does not match the address you set.

You do realize that the ninth bit is only used for addresses don't you?

Robert

cb1_mobile said:

Note that "0x10b" does NOT require 9 bits

that's 100001011 in binary. I count nine bits. In fact, I rather suspect having the ninth bit set is at least part of the issue.

Robert

Priya Nadathur70 said:

In MDB, I understand when master transmits to peripheral, the ninth bit indicates its an address byte.

Yes, that's typical for a nine bit protocol.

Priya Nadathur70 said:

Dropping the 9th bit in 0x143, I thought 0xa1 will be the address

Um, if you drop the ninth bit in 0x143 you get 0x43. But the concept of dropping the ninth bit makes little sense. You add the address bit to the output via a particular TIVAWare function IIRC.

However, that's also not what you claimed. You clamed you were sending 0x10B. So what are you actually sending? And at this point probably at least as important, how are you sending?

Robert

Priya Nadathur70 said:

I am sending this from the timer interrupt handler function using UartCharPut.

How? We need to see an example of your code. UartCharPut won't be able to send 9 bit 'characters' since the UART doesn't support that (almost no UART does).

Priya Nadathur70 said:

MDB says LSB indicates address bit. I dropped bit 0 to get A1 as the peripheral address.

That's wrong in almost every respect on the hardware.

The ninth bit is the parity bit.

The UART send the bits in order from LSB to MSB followed by the parity bit.

If MDB reverses these bits, which seems a very odd thing to do, then you will not be able to use the TM4Cs nine bit HW support but will need to created your own in SW. My suspicion is you've mis-interpreted something*.

Robert

* In fact a quick peruse of the standard also indicates you've read it wrong. The address bit (mode bit) is not the lsb. See section 2.1 of version 4

LSB       --->                        MSB

Start 0 1 2 3 4 5 6 7 Mode Stop

Priya Nadathur70 said:

Yes, I realized the MDB doc shows the LSB on the left.

Did you also note that the mode bit was in the MSB position?

Priya Nadathur70 said:

Does this mean I can't use the TIVA 9 bit uart APIs for MDB?

No, it means you've confused yourself.

Priya Nadathur70 said:

Only the Stellaris seems to have APIs for software 9 bit uart.

It would be shocking if they didn't work in the same fashion.

Priya Nadathur70 said:

It seems complicated to write a 9 bit software uart, isn't it?

You do need to have a clearer picture of what is happening than you appear to have currently.

First stop thinking of 9 bit mode as using a 9 bit value. It doesn't. It uses an 8 bit value plus an additional flag bit. The setting of this bit determines if the 8 bit value is a data bit or an address bit. This bit is managed separately from the data and the TIVA APIs reflect that with a separate call to send an eight bit data byte with the flag bit set.

Robert

Robert,

To clarify with a numeric example:

This is byte 0x43. From EK1, I am transmitting x43. I see this on the scope. In 9 bit mode

the duration on the scope would be 11 bits long. The address sent from UART9BitAddrSet

and UART9BitAddrSend APIs are both 0x43. From EK2, I want to transmit 0x21 to see the response

clearly on the scope. I am still not seeing anything sent from EK2, though x43 is being received by EK2.

What am I missing?

Thanks,

Priya

Priya Nadathur70 said:

From EK2, I want to transmit 0x21 to see the response

clearly on the scope. I am still not seeing anything sent from EK2

What are you doing to do this? You still haven't presented your code for this.

Robert

Use the past code </> option. The result is far more readable.

Let's start with the interrupt routine

void
 UARTIntHandler(void)
 {
 uint32_t ui32Status;

 //
 // Get the interrrupt status.
 //
 ui32Status = UARTIntStatus(UART5_BASE, true);

 //

 //
 // Clear the asserted interrupts.
 //
 UARTIntClear(UART5_BASE, ui32Status);

 // Receive uart char
 while(ROM_UARTCharsAvail(UART5_BASE))
 {
 //
 // Read the next character from the UART and write it back to the UART.
 //

 UARTCharGet(UART5_BASE);

 }
 // Blink the LED to show a character transfer is occuring.
 //
 GPIOPinWrite(GPIO_PORTN_BASE, GPIO_PIN_0, GPIO_PIN_0);

 //
 // Delay for 1 millisecond. Each SysCtlDelay is about 3 clocks.
 //
 SysCtlDelay(g_ui32SysClock / (1000 * 3));

 //
 // Turn off the LED
 //
 GPIOPinWrite(GPIO_PORTN_BASE, GPIO_PIN_0, 0);
 }

Breaking out pieces for comment.

This

 // Get the interrrupt status.
 //
 ui32Status = UARTIntStatus(UART5_BASE, true);

 //

 //
 // Clear the asserted interrupts.
 //
 UARTIntClear(UART5_BASE, ui32Status);

is good provided you properly deal with the status result later. The problem is you don't

 // Receive uart char
 while(ROM_UARTCharsAvail(UART5_BASE))
 {
 //
 // Read the next character from the UART and write it back to the UART.
 //

 UARTCharGet(UART5_BASE);

 }

And here's the problem, you never deal with the other interrupts. Specifically you never deal with the 9-bit match receive interrupt. This, despite the fact that you enabled it.

And this:

 //
 // Delay for 1 millisecond. Each SysCtlDelay is about 3 clocks.
 //
 SysCtlDelay(g_ui32SysClock / (1000 * 3));

is a big no-no

Robert

I changed the LED blinking code to toggle without any delays. This made both EKs transmit correctly on timer interrupts. However receive uart in 9 bit mode is not working with either EK.

Here is the updated code for EK2.

I appreciate the code review and feedback.

Thanks,

Priya

uint32_t g_ui32SysClock;

unsigned char txcomplete = 0;
unsigned char timerComplete = 0;
uint8_t TrxBuffer[1] = {0x21};
uint8_t i = 0;
void UARTSend(const uint8_t *pui8Buffer, uint32_t ui32Count);
void Timer3IntHandler(void);

//*****************************************************************************
//
// The error routine that is called if the driver library encounters an error.
//
//*****************************************************************************
#ifdef DEBUG
void
__error__(char *pcFilename, uint32_t ui32Line)
{
}
#endif

//*****************************************************************************
//
// Send a string to the UART.
//
//*****************************************************************************
void
UARTSend(const uint8_t *pui8Buffer, uint32_t ui32Count)
{
    //
    // Loop while there are more characters to send.
    //

    while(ui32Count--)
    {
        //
        // Write the next character to the UART.

        UARTCharPut(UART5_BASE, *pui8Buffer++);
//        UARTprintf("%x ", TrxBuffer[i++]);

    }
}

void Timer3IntHandler(void)
{
    // Clear the timer interrupt
    TimerIntClear(TIMER3_BASE, TIMER_TIMA_TIMEOUT);

    // Blink the LED to show a character transfer is occuring.

    if(GPIOPinRead(GPIO_PORTN_BASE, GPIO_PIN_1))
            {
                GPIOPinWrite(GPIO_PORTN_BASE, GPIO_PIN_1, 0);
            }
    else
            {
                GPIOPinWrite(GPIO_PORTN_BASE, GPIO_PIN_1, 2);
            }

    UARTSend(TrxBuffer, 1);
    i = 0;

    timerComplete = 1;

}

//*****************************************************************************
//
// The UART interrupt handler.
//
//*****************************************************************************
void
UARTIntHandler(void)
{
    uint32_t ui32Status;

    //
    // Get the interrrupt status.
    //
    ui32Status = UARTIntStatus(UART5_BASE, true);
    uint8_t interrupt_type = (uint8_t) ((ui32Status & 0x1000) >> 12);

    //

    //
    // Clear the asserted interrupts.
    //
    UARTIntClear(UART5_BASE, ui32Status);

    if (interrupt_type == 1){
        // Receive uart char
             while(UARTCharsAvail(UART5_BASE))
             {
                 //
                 // Read the next character from the UART and write it back to the UART.
                 //

                 UARTCharGet(UART5_BASE);
             }

    if(GPIOPinRead(GPIO_PORTN_BASE, GPIO_PIN_1))
        {
            GPIOPinWrite(GPIO_PORTN_BASE, GPIO_PIN_1, 0);
        }
    else
        {
            GPIOPinWrite(GPIO_PORTN_BASE, GPIO_PIN_1, 2);
        }
    }

}

//*****************************************************************************
//
// This example demonstrates how to send a string of data to the UART.
//
//*****************************************************************************
int
main(void)
{
    uint32_t ui32Period;

    //
    // Set the clocking to run directly from the crystal at 120MHz.
    //
    g_ui32SysClock = MAP_SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ |
                                             SYSCTL_OSC_MAIN |
                                             SYSCTL_USE_PLL |
                                             SYSCTL_CFG_VCO_480), 120000000);
    //
    // Enable the GPIO port that is used for the on-board LED.
    //
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPION);
    //
    // Enable the GPIO pins for the LED (PN0).
    //
    GPIOPinTypeGPIOOutput(GPIO_PORTN_BASE, GPIO_PIN_0|GPIO_PIN_1);

    //
    // Enable the peripherals used by this example.
    //
    SysCtlPeripheralEnable(SYSCTL_PERIPH_UART5);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOC);

    SysCtlPeripheralEnable(SYSCTL_PERIPH_UART0);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);

    //
    // Enable processor interrupts.
    //
    IntMasterEnable();

        SysCtlPeripheralEnable(SYSCTL_PERIPH_TIMER3);
//        TimerConfigure(TIMER3_BASE, TIMER_CFG_ONE_SHOT);
        TimerConfigure(TIMER3_BASE, TIMER_CFG_PERIODIC);

        ui32Period = g_ui32SysClock/2; // 1 ms one shot timer

//        ui32Period = 5*g_ui32SysClock;
        TimerLoadSet(TIMER3_BASE, TIMER_A, ui32Period-1);

        IntEnable(INT_TIMER3A);
        TimerIntEnable(TIMER3_BASE, TIMER_TIMA_TIMEOUT);
        IntMasterEnable();

        TimerEnable(TIMER3_BASE, TIMER_A);

    //
    // Set GPIO A0 and A1 as UART pins.
    //
    GPIOPinConfigure(GPIO_PC6_U5RX);
    GPIOPinConfigure(GPIO_PC7_U5TX);
    GPIOPinTypeUART(GPIO_PORTC_BASE, GPIO_PIN_6 | GPIO_PIN_7);

    //
    // Configure the UART for 9600, 8-N-1 operation.
    //
    UARTConfigSetExpClk(UART5_BASE, g_ui32SysClock, 9600,
                            (UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE |
                             UART_CONFIG_PAR_NONE));

    GPIOPinConfigure(GPIO_PA0_U0RX);
    GPIOPinConfigure(GPIO_PA1_U0TX);
    GPIOPinTypeUART(GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1);

    UARTStdioConfig(0, 9600, g_ui32SysClock);

    UART9BitAddrSet(UART5_BASE, 0x43, 0xFF);
    UART9BitEnable(UART5_BASE);

    UARTFIFODisable(UART5_BASE);

    //
    // Enable the UART interrupt.
    //
    IntEnable(INT_UART5);
    UARTIntEnable(UART5_BASE, UART_INT_RX | UART_INT_RT | UART_INT_9BIT);
//    ROM_UARTIntEnable(UART5_BASE, UART_INT_RX | UART_INT_RT);
//    ROM_UARTIntEnable(UART5_BASE, UART_INT_TX | UART_TXINT_MODE_EOT | UART_INT_9BIT);
//    ROM_UARTIntEnable(UART5_BASE,UART_INT_TX|UART_TXINT_MODE_EOT | UART_INT_9BIT | UART_INT_RX|UART_INT_RT);

//    UARTSend(TrxBuffer, 1);

//    while(!(txcomplete));
    while(1);
}

Use the past code </> option. The result is far more readable.

Priya Nadathur70 said:

I changed the LED blinking code to toggle without any delays. This made both EKs transmit correctly on timer interrupts. However receive uart in 9 bit mode is not working with either EK.

Remember this?

 // Receive uart char
 while(ROM_UARTCharsAvail(UART5_BASE))
 {
 //
 // Read the next character from the UART and write it back to the UART.
 //

 UARTCharGet(UART5_BASE);

 }

And here's the problem, you never deal with the other interrupts. Specifically you never deal with the 9-bit match receive interrupt. This, despite the fact that you enabled it.

You still haven't dealt with it.

Robert

I did this to receive on the 9 bit uart interrupt. Let me know if I should be doing something else:

void

UARTIntHandler(void)

{

    uint32_t ui32Status;

    //

    // Get the interrrupt status.

    //

    ui32Status = UARTIntStatus(UART5_BASE, true);

    uint8_t interrupt_type = (uint8_t) ((ui32Status & 0x1000) >> 12);

    //

    //

    // Clear the asserted interrupts.

    //

    UARTIntClear(UART5_BASE, ui32Status);

    if (interrupt_type == 1){

        // Receive uart char

             while(UARTCharsAvail(UART5_BASE))

             {

                 //

                 // Read the next character from the UART and write it back to the UART.

                 //

                 UARTCharGet(UART5_BASE);

             }

I've been asked to amplify.

Consider the following question:

• What do you do when you receive any interrupt other than the one you are masking?
  • How do you detect it?
  • How do you respond to its occurrence?
    • Relatedly what do you expect from it?
  • How do you clear it?

Related question:

• What to expect when the UART receives a 9 bit 'character'?
  • What does the manual say?

Robert