TIva PROBLEM UART2

KEVIN DE LA O said:

ROM_GPIOPinConfigure(GPIO_PD7_U2TX);
ROM_GPIOPinTypeUART(GPIO_PORTD_BASE, GPIO_PIN_7 );

// Unlock access to the commit register
HWREG(GPIO_PORTD_BASE + GPIO_O_LOCK) = GPIO_LOCK_KEY;

Note that you "GPIOPinConfigure() & GPIOPinType()" Pin D7 before you, "unlock!"  Neither has much chance of causing the desired effect - while the pin is, "locked."  After the "unlock" - such necessary "config/type" are not repeated - thus lost...

Further - you are using the internal osc - read the MCU manual to insure that the frequency accuracy is sufficient for robust UART operation over: time, temperature, part aging/variation and connection line length/loading...  (I've past reported here (shown the math) which demands 5% freq accuracy (combined, both ends) to prevent bit errors...)

cb1_mobile said:

Further - you are using the internal osc - read the MCU manual to insure that the frequency accuracy is sufficient for robust UART operation over: time, temperature, part aging/variation and connection line length/loading...  (I've past reported here (shown the math) which demands 5% freq accuracy (combined, both ends) to prevent bit errors...)

I get tighter than that

Assuming 10 bits (8 bits plus start and stop), center sampling gives 5%.

A 16x sampling clock shaves another 1/16 bit off for synchronization

3 sample majority vote at centre (usual now) shaves yet another 1/16

If you account for edge rates you have to cut that margin down again, I usually use yet another 1/16 bit.

If you use all of that, and you might be able to reduce the last, you get a margin of 5/16 bit time in 10 bits which works out substantially lower, a little over 3%

It's also possible your edge rate is slower which makes the margin even tighter.

That gives 1.5% error budget for each side assuming neither end has a systematic bias where it has already eaten more than 1/2 the error budget.  Not always a good assumption.

Robert

Knew that such a post would (often) invite your presence.  Greetings. 

Indeed I assumed 10 bits - and center sampling yielded the 5% which I listed.

Agreed that sampling clock will be an error source - unsure if ARM employs that past 3 sample vote scheme.

While clearly not your intent - you have further confirmed my stated advice, "that use of the less precise, internal oscillator - as UART clock source" - may not yield especially robust UART operation.  And - my post did target & resolve the o.p.'s "issue at hand" - and added the frequency alert as an aside...  (to be dissected by others...)

Greetings,

Actually, I did mean to support you in your advice.  I completely agree.

I have yet to see an internal RC oscillator that I would consider adequate for an asynchronous serial connection.

Not so long ago, in previous employment, we had purchased a product that assumed an internal "calibrated" RC clock was sufficient for serial communications.  Of course we only found out about that assumption after disassembling failing units. That was part a number of issues with that product and it cost us a lot to fix the problem.

I don't know if these processors use a TI or an ARM UART.  Most companies seem to use their own.  But since they haven't documented it it's probably prudent to assume at least the 3 point sampling since it is fairly common.  Similar precautions extend to the other side if it is either unknown or may be arbitrary.

I would add to your caution, just because it behaves on the test bench does not mean it works. 

Even extensive testing is unlikely to probe all the corners of the ICs timing variations.  The data sheet's min/max variations must be considered in the design even if not seen in testing.

If you only use the connection for debug on the bench you can be considerably more tolerant.

Robert

Mon ami,

I read your initial post as bit "attacking" - that read tossed to scrap bin in light of your quick/kind, follow-on detail.

Like you - in previous employ/incarnation - I too implemented a, "calibrated" (ha!) RC oscillator in the attempt to massage an early CPLD into a reduced cost UART.  (No such flash MCUs were available - back then.)  And - just as you report/guard-post - mine worked in the lab - failed quickly/miserably in the (hostile) field!

Love your well schooled/experienced comment, "Even extensive testing is unlikely to probe all the corners..."  Boy is that true - testing is far from the equal of: "Skilled, precision thought, experienced & guard-banded" design!  No amount of "testing" can rectify a design error - which may "hide" for years - and then emerge with horrendous (i.e. life-threatening) consequence!

Internet and, "look what I did" videos - too often (i.e. always) over-promote - and skimp (if that) on the necessary precautions - which time/trenches have taught you/me - really are not an option...

Thanks for writing - perhaps one day you/I may conspire...  (fire hoses, pick-axes, escape routes - at the ready...)

I've already fixed the problem, this is how the function is done

void
ConfigureUART(void)
{

//
// Enable the GPIO Peripheral used by the UART.
//
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);

//
// Enable UART0
//
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_UART1);

//
// Configure GPIO Pins for UART mode.
//
//ROM_GPIOPinConfigure(GPIO_PA0_U0RX);
ROM_GPIOPinConfigure(GPIO_PB1_U1TX); // PB1 TX
ROM_GPIOPinTypeUART(GPIO_PORTB_BASE, GPIO_PIN_1);

//
// Use the internal 16MHz oscillator as the UART clock source.
//
UARTClockSourceSet(UART1_BASE, UART_CLOCK_SYSTEM);

//
// Initialize the UART for console I/O.
//
UARTConfigSetExpClk(UART1_BASE, ROM_SysCtlClockGet(), 9600,
(UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE |
UART_CONFIG_PAR_NONE));
//UARTStdioConfig(1, 115200, SysCtlClockGet());

KEVIN DE LA O said:

I've already fixed the problem

Boy - that was FAST!  (Feb 26 - Nov 10)

Appears that you've not paid highest attention to the "two alerts" that internal oscillator is unlikely to provide the long-term frequency robustness you may require.  (we'll look forward to another post in - say - 10 more months...)