gb3213
Posts: 3
Joined: Sun Feb 11, 2018 6:01 am

[SOLVED] RPi3: why does use of the Mini-UART deactivate GPIO19?

Sun Feb 11, 2018 6:23 am

I'm following along with Stanford's new CS140e course and noticed something peculiar I cannot explain.

My kernel boots up and sets up GPIOs 16, 5, 6, 13, 19, 26 referring to pinouts 36, 29, 31, 33, 35, 37 as shown here:

Image

I have connected 6 LEDs to the pins. During bootup, I let each of them blink 3 times (via FSELx -> Output, then Set/Clear). Works as expected.

Then I enable the Mini-UART, which is connected to a CP2102 to pins 4-10 (GPIO14/15 and 3.3V/GND). I then enter a mini-shell loop where I can issue commands to toggle the 6 GPIOs. This works as expected, except...

... that once I enable the Mini-UART, I can no longer toggle GPIO19. It stays off. I can still toggle all other 5.

Moreover, if I reinitialize all 6 GPIOs (by resetting their FSELx to the Output function), the Mini-UART ceases to function. (This is somewhat consistent with the manual, which recommends setting up the GPIOs before the mini-UART. Though it wasn't clear to me to which GPIOs they are referring - all of them or just GPIO14/15's Alt5 function which is needed for the mini-UART).

Is there a known conflict between using the mini-UART and GPIO19?
What, if anything, is known about the initialization order of the mini-UART vs GPIOs?
Last edited by gb3213 on Mon Feb 12, 2018 1:47 pm, edited 1 time in total.

gb3213
Posts: 3
Joined: Sun Feb 11, 2018 6:01 am

Re: RPi3: why does use of the Mini-UART deactivate GPIO19?

Sun Feb 11, 2018 8:53 pm

ps: in fact, when I dump the content of the FSEL registers after enabling the Mini-UART, I see that GPIO 19 entered the Input function (000).

Code: Select all

         10 987 654 321 098 765 432 109 876 543 210
       0b00 000 000 000 000 000 000 000 000 000 000
             9   8   7   6   5   4   3   2   1   0
FSEL0: 0b00 000 000 000 001 001 000 000 000 000 000   0x              000 Input 
FSEL1: 0b00 000 000 000 001 010 010 001 000 000 000   1x              001 Output
FSEL2: 0b00 000 000 000 001 000 000 000 000 000 000   2x
FSEL3: 0b00 000 000 000 000 000 000 000 000 000 000   3x
FSEL4: 0b00 111 111 000 000 000 000 100 100 100 100   4x
FSEL5: 0b00 000 000 000 000 000 000 111 111 111 111   5x

gb3213
Posts: 3
Joined: Sun Feb 11, 2018 6:01 am

Re: RPi3: why does use of the Mini-UART deactivate GPIO19?

Mon Feb 12, 2018 5:09 am

I did further experimentation. If instead of using GPIOs 5, 6, 13, 16, 19, and 26 (with 19 being disabled once I activate the Mini-UART) I use GPIOs 5, 6, 12, 13, 16, 26 then GPIO 16 flips to Input when I activate the Mini-UART.

However, if I use GPIOs 5, 6, 12, 13, 21, 26 everything works as expected....

Ok, this can't be the RPI's fault. Both 16 and 19 being wiped but 21 not can't be an accident - this reeks like a problem in my code that sets FSEL1.

Double-checking found nothing. Being a Rust newbie, I then looked at the assembly code...

Bummer. I had written 0xb111 instead of 0b111 when setting FSEL. This clobbered the entries for 16/19 but not for 21.

Code: Select all

-        let old = self.registers.FSEL[regidx].read() & !(0xb111 << regshift);
+        let old = self.registers.FSEL[regidx].read() & !(0b111 << regshift);
If only the Rustaceans has listened to the designers of C (not GCC) who had rejected binary constants due to "lack of precedent and sufficient utility."

Sorry about posting. Nothing to see here, no weird hidden hardware thingy going on. Problem between keyboard and chair. The RPI3's Mini-UART and the other GPIOs (at least 5, 6, 13, 16, 19, 26, 12, and 21) can be safely used simultaneously if you don't prefix your binary constants with 0x.

Return to “Bare metal, Assembly language”

Who is online

Users browsing this forum: No registered users and 3 guests