PORT UA[0:1] not working as expected

[nedilson]

Hi!

Surely i´m missing something, but when trying to use UA port as digital inputs on the MCF52211CAF80 the two lower [1:0] bits (pins 8 and 7) only read 1´s (the PUAPAR and DDRUA are supposely correct). These port I/O´s appear to weak pull-down, while [3:2] are pulled-up (?!). Any suggestion?

[RichTestardi]

If you're running under the debugger, can you verify the state of the DDRUA and PUAPAR registers using View -> Registers, and using the symbolic register dump, like in the attached picture?  Yours should be 0x00 and 0x00.  To use the symbolic register dump, the Target Processor must be set to 52211 under Project Settings -> Debugger -> CF Debugger Settings.  I assume you are reading your digital inputs from the SETUA register (not the PORTUA register).

-- Rich

[nedilson]

Hi Rich! Thank you!

Yes, DDRUA=0 and PUAPAR=0; And i´m reading from SETUA. (And i checked with the debugger).

I'm confused, these two I / O's have secondary functions such as the RTC oscillator or the RX / TX from UART0, but I think it should be sufficient to configure the PUAPAR to make these GPIO´s. Am I right?

Interestingly, as I mentioned, the bits [3:2] are working properly and appear to have internal pull-up's. The two lower bits [1:0] seem to float or a very weak pull-down (i´m multiplexing 8 DTMF detectors using port UA as bus input).

Nedilson

[RichTestardi]

It seems the use of the RTC crystal on that MCU has some non-obvious implications.

Have you seen this: http://www.utasker.com/forum/index.php?topic=301.0

Mark seems to imply that MCF_CLOCK_RTCCR might essentially override the PUAPAR.

How do you have that set?

[nedilson]

Hummm... MCF_CLOCK_RTCCR=0... I´m going crazy... hehehehhehehe

[MrBean]

Weak pullups for GPIOs are normal. See MCF52211 Reference Manual page 2-6 note 2

From memory, they should be in the order of 100k to 300k.

Are you driving the UA[1:0] pins correctly, ie. are they floating because they are not driven ?

If you drive them with a eg. 3k3 resistor manually to GND/Vdd, do they then read accordingly ?

[nedilson]

Hi MrBean! Thanks!

Yes, that´s the strange thing. I expected pull-up´s on the GPIO´s (although not necessary in my circuit as the GPIO´s are driven by totem-pole outputs from 8 x HT9170´s multiplexed in time).

I´ve attached an image of the circuit to be clear, but it works as follow:

When a HT9170 has an valid DTMF digit, it sets the DV output, which "tend" to set the respective OE throug a resistor. The OE lines are tied to other GPIO port (DD) that are commonly grounded.

When I want to see if a particular HT9170 has a valid digit, I put the correspondent OE line in input mode, allowing OE to set in case of DV, driving the data lines (port UA). This was tested and the data lines are asserted normally.

When the HT9170´s are not driving the data lines I see that UA[3:2] are pulled high as expected, but UA[1:0] are weakly pulled down. This and the fact that I only read 1´s in PORTUAP/SETUA[1:0] probably indicates that UA[1:0] are not configured as GPIO´s even with PUAPAR and DDRUA correctly set.

[MrBean]

PortDD is the debug port. PST and Debug-Data.

Debugging will interfere with the steering of the OEs.

Are you sure that the 8 OEs are steered correctly ?

If you fysically disconnect the OEs and make them all low on the 9170s (thus all data lines hi-z and portDD open), then steer the UA[1:0] lines manually, do they then still read incorrect ?

[nedilson]

MrBean

Yes, I checked many times and it´s working. I will put some scope images later.

But I see only two possibilities: A defective chip (although I tested the port´s in question as outputs and it worked; I´m making a second prototipe to clear this) or a undocumented feature (this will be a nightmare!).

Thanks!

[nedilson]

Discarded the defective chip... Same problem with a new prototipe...

[sergemonnerat]

hello,

I have the same as yours and I found that if I put power on VSTBY pin it's work. It's logic because VSTBY is the power pin for the RTC...

[nedilson · Accepted solution]

Hi again sergemonnerat,

Problem solved!!!

Thank you so much!!!

[nedilson]

Hi sergemonnerat,

That really makes sense! In fact VSTBY is NOT connected in my circuit. I´ll give it a try and post the result later.

Thank you!