firmware works on TM4C123Gxl but not TM4C1230

Dawen

Other Parts Discussed in Thread: TM4C123GH6PM, TM4C1230D5PM

I have a TM4C123GH6PM launch kit and developed a firmware for it. The firmware works fine including UART on launch board. then I program the same firmware onto my development board with TM4C1230D5PM, but it does not work. The programming is fine, but UART does not work. Measured power supply are all fine, but the UART TX0 voltage level is at 0.7V, RX0 is 3.3V. The power draw only 3mA. Does this looks normal? should the firmware running on TM4C123G run on TM4C1230 without change? Or there something I am missing?

over 9 years ago

0 Amit Ashara over 9 years ago

TI__Guru**** 244400 points

Hello Dawen

Since you have migrated your firmware from one design to another,

1. Schematic is required to see if there is any obvious difference between the custom board and the launchpad
2. How is the clock being configured in the firmware

TX0 voltage at 0.7V on a digital pin is indicative of a bus contention and 3mA seems too low for the device if it is active. Can you check the power rails to see if the 3.3V supply is fine on your board?

Regards
Amit

0 cb1 over 9 years ago in reply to Amit Ashara

Guru 47900 points

Hi Amit,

Poster (claims) to have checked the "power rails" - "Measured power supply are all fine, but the UART TX0 voltage level is at 0.7V, RX0 is 3.3V. The power draw only 3mA." As (some) note here - "devil in the details!"

Where has he measured that voltage? And how? If (only) at the regulator - or some convenient probe point - that's insufficient! Poster (must) measure at each/every MCU power pin - both VDD & VSS - to insure all are connected. The Analog VDD must also be properly powered - even if not used!
Are the pinouts, especially the power pins, identical between these 2 MCUs? Are ALL of the power pins handled properly? 3mA draw "screams" No!
0V7 upon TX_0 is improper - but poster does not describe "how" that was measured. If via DVM - and the UART was "in motion" such may be valid.
Can this test be repeated upon a 2nd or 3rd pcb? NEVER wise to build "just one." With multiple boards - "A-B-C" testing may be performed.
Poster indicates other portions of the MCU perform - but absent any (usable) detail. At 3mA current - we find that "hard to believe."

Again - "Unguided Posters" (often) present incomplete data - cause endless back & forth - w/this copied by hundreds of others - thus self-perpetuating...

0 Dawen over 9 years ago in reply to Amit Ashara

Prodigy 80 points

Hi Amit,

thanks for the reply. I am using internal clock as ROM_SysCtlClockSet(SYSCTL_SYSDIV_1 | SYSCTL_OSC_INT | SYSCTL_USE_OSC | SYSCTL_OSC_MAIN); I did check the power supply on each power supply pin and they shows 3.3V is fine. I'd like to share my schematics, but don't see where I can attach it.

thanks,
Dawen

0 Dawen over 9 years ago

Prodigy 80 points

Hi Amit,

Thanks for the reply. Please see my schematics from the attached. And I did measure the power on MCU power pins.

Regards,

Dawen

TM4C1230_schematics.pdf

0 Dawen over 9 years ago in reply to cb1

Prodigy 80 points

Hi,
To answer your questions, see below:
1. the power are measured on each MCU's power supply pin.
2. The two CPUs do have identical power supply pin, the difference is GPIOs.
3. I tested 3 PCBs already, they all behave the same.
4. 3mM to me, it seem the CPU is in sleep mode?

thanks,
Dawen

0 cb1_mobile over 9 years ago in reply to Dawen

Guru 117855 points

Thank you. Indeed ~3mA (may) be sleep mode - but (how then) does your code run? (you did indicate other parts of the MCU performed - just the UART was troubled.) Would assist greatly if you'd further detail "which peripherals ran - and how you tested/confirmed their correctness.

Might you comment upon your report of 0V7 (0.7V - old way) as measured @ TX_0? HOW was that measured?

0 Amit Ashara over 9 years ago in reply to Dawen

TI__Guru**** 244400 points

Hello Dawen,

The schematic looks fine but the clock function does not

ROM_SysCtlClockSet(SYSCTL_SYSDIV_1 | SYSCTL_OSC_INT | SYSCTL_USE_OSC | SYSCTL_OSC_MAIN);

It should be either Internal Oscillator or Main Oscillator

ROM_SysCtlClockSet(SYSCTL_SYSDIV_1 | SYSCTL_USE_OSC | SYSCTL_OSC_MAIN);

OR

ROM_SysCtlClockSet(SYSCTL_SYSDIV_1 | SYSCTL_OSC_INT | SYSCTL_USE_OSC);

If you remove the Sleep function and instead put a while(1) loop then does the UART TX pin show 3.3V when in Idle State?

Regards
Amit

0 cb1 over 9 years ago in reply to Amit Ashara

Guru 47900 points

Hi Amit,

Suspect that it would be even (more) useful if you could advise, "How the MCU (usually) responds to an "illegal" SysCtlClockSet() command."
And - should such, "conflicting parameters" pass w/out notice? (as appears the case, here...) Merci.

0 Amit Ashara over 9 years ago in reply to cb1

TI__Guru**** 244400 points

Hello cb1-

I think I know what may be happening. The Main Oscillator crystal value is not being mentioned here causing the device to use 4MHz (the lowest encoded value) which may be making the PLL go out of region and device to stop execution.

Regards
Amit

0 Robert Adsett over 9 years ago in reply to Dawen

Guru 27665 points

Note that if you are using the internal clock and checking the UART by connecting to a serial terminal you may well not have a valid test.

Robert

0 cb1 over 9 years ago in reply to Robert Adsett

Guru 47900 points

Bonjour Robert,

Might you (of all here) be "defaming" famed PIOSC? Didn't you/I analyze - and determine that (in general) its accuracy was sufficient if (reasonable accuracy) existed @ the remote, UART side?

Could "confluence" of oscillators have (invaded) this space. (sorry folks - that's WAY inside...)

0 Robert Adsett over 9 years ago in reply to cb1

Guru 27665 points

I might indeed. There's enough caveats that I'd check the actual signal before assuming the baud rate must be correct.

Particularly at higher baud rates PC UARTs are known for high inaccuracies. Add in variation over time, temperature and voltage of the high accuracy internal oscillator. Top it off with a plethora of app notes from various manufacturers of such devices on how to repair/update factory calibrations.

That might be enough to make be a tad suspicious of the frequency, but maybe I'm just the paranoid type.

Robert

0 cb1 over 9 years ago in reply to Robert Adsett

Guru 47900 points

Robert Adsett said:
but maybe I'm just the paranoid type.

"MAYBE??? Maybe??" (even the always "PC" Amit's eyes' (likely) rolled back on that one...)

0 Amit Ashara over 9 years ago in reply to cb1

TI__Guru**** 244400 points

Hello cb1

Robert's point is valid. PIOSC variation will affect UART Baud Rates over PVT variation. So it is important that the system clock be MOSC and the UART be working from System Clock.

Regards
Amit

0 cb1 over 9 years ago in reply to Amit Ashara

Guru 47900 points

Hi Amit,

While friend Robert's UART comment may prove valid - his "questioning" of paranoia - escapes any doubt. He (was, remains & is) - case closed!

0 Dawen over 9 years ago in reply to cb1

Prodigy 80 points

Hi Amit/CB1/Robert,

Thanks all for your inputs. I did try both clock settings , but it seems do not make a difference. In my code, I do not have a sleep, and I do have while loop. I re-measured the power, the RX0 is 3.2V, the TX0 is 0.4V now. And I have to make a correction that 3mA is from my 12V power supply, so technically speaking, the actual current on 3.3V should be around 12mA.

regards,
Dawen

0 Amit Ashara over 9 years ago in reply to Dawen

TI__Guru**** 244400 points

Hello Dawen

That cannot be..

Input Power = 12V*3mA = 36mW
Output Power = 3.3V*12mA = 39.6mW

Where is that you are measuring the RX and TX voltage. On the RS232 cable out or on the Digital Side (between transceiver and TM4C)

Did you try removing the transceiver and check if the TX is 3.3V?

Regards
Amit

0 cb1 over 9 years ago in reply to Dawen

Guru 47900 points

And - it would be more useful - if you described the tool (i.e. DVM, Scope) used to measure the voltage @ MCU's TX.

0 Robert Adsett over 9 years ago in reply to Amit Ashara

Guru 27665 points

Close enough for a back of the envelope calculation I think, Amit.

Dawen, what do you see on the Tx pin. DC or a waveform? And as Amit says you should measure on the IC pin rather than have a transceiver complicate measurements.

Robert

0 cb1 over 9 years ago in reply to Robert Adsett

Guru 47900 points

Mes Amis,

Does it not make sense for poster to perform the exact same tests - as presented here - but upon his "WORKING" Controller?

Ideally he may then present results as: Controller "A" (working) in one column - Controller "B" (failing) side-by-side, next column!

Beauty of this procedure is the "exposure" of any/all measurement weaknesses...

0 Robert Adsett over 9 years ago in reply to cb1

Guru 27665 points

Yes, absolutely.

Robert

0 Dawen over 9 years ago

Prodigy 80 points

Hi Amit,

I measured the MCU pin PA1/U0TX to GND with voltage meter. Same as measuring PA0/U0RX. Did try to remove the transceiver and result is the same.

Thanks,

Dawen

0 cb1 over 9 years ago in reply to Dawen

Guru 47900 points

Should "voltage meter" be all that you have you cannot properly "measure" UART_TX during its (transmitting). (signal transitions too fast for your meter to respond - a scope is far preferred.)

One test - w/in the capability of your meter - would be to switch UART_TX to a simple, GPIO Output - and then (slowly) toggle it. The full 3V3 voltage span should then reveal - even upon a voltmeter. (provided you toggle at 1Hz or lesser frequency.)

0 Amit Ashara over 9 years ago in reply to Dawen

TI__Guru**** 244400 points

Hello Dawen,

Can you please share the GPIO Configuration of the Port A?

Regards
Amit

0 Dawen over 9 years ago

Prodigy 80 points

Hi Amit,

The followings are the code for uart 0 configuration:

void

ConfigureUART(void)

{

// Enable the GPIO Peripheral used by the UART.

ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);

// Enable UART0

ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_UART0);

// Configure GPIO Pins for UART mode.

ROM_GPIOPinConfigure(GPIO_PA0_U0RX);

ROM_GPIOPinConfigure(GPIO_PA1_U0TX);

ROM_GPIOPinTypeUART(GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1);

// Use the internal 16MHz oscillator as the UART clock source.

UARTClockSourceSet(UART0_BASE, UART_CLOCK_PIOSC);

// Initialize the UART for console I/O.

UARTStdioConfig(0, 115200, 16000000);

}

Please also be aware that same code works fine on launchpad, and the TX0 are measured at 3.3V with same meter.

Regards,

Dawen

0 Dawen over 9 years ago

Prodigy 80 points

Hi CB1,

Your assumption is true if the TX is transmitting data. Your suggestion would be a good test, I’ll try that tomorrow.

Thanks,

Dawen

0 Amit Ashara over 9 years ago in reply to Dawen

TI__Guru**** 244400 points

Hello Dawen,

Please visually check for any short with adjacent pins or traces that may have shorted, or any cold solder!

Regards
Amit

0 Robert Adsett over 9 years ago in reply to cb1

Guru 27665 points

cb1- said:
a scope is far preferred

necessary

You need to check not only transitions but the levels.

Robert

0 cb1 over 9 years ago in reply to Robert Adsett

Guru 47900 points

Robert Adsett said:

cb1-

a scope is far preferred

Friend Robert - my words - dispatched - the shame!... ... (w/a knife carved from cold steel.)

Cb1 firm's crack hound sees my scowl - heads to "next work-station" for safety/solace.

(no hounds were harmed during this posting) Human heart - carved to the bone - makes no such claim.

0 Robert Adsett over 9 years ago in reply to cb1

Guru 27665 points

I just figured you were being shy and reserved.

Robert

0 cb1_mobile over 9 years ago in reply to Robert Adsett

Guru 117855 points

Indeed - that IS "normal personna." (sometimes)

I'd avoid any "barking" & doorbell...

Arm-based microcontrollers

Arm-based microcontrollers forum

firmware works on TM4C123Gxl but not TM4C1230