I tried using the virtual com port by using usart2 of the nucleo mentioned DATASHEET I configured the peripheral as shown but nothing appears on the serial screen. used gdb to assert the register values I found the following:

  • the TXE flag is never cleared after a write to TDR even tried to force clear it by writing '1' to TCCF (bit 7 in ICR), ICR shows TCCF=0 when read after (i.e. as if no write happened to the TCCF) and the TXE flag isn't cleared either
  • The TDR register always has the initial value that I gave it (I think it should be cleared after every transmission) -which makes me think the peripheral isn't working at all and I don't have an oscilloscope to verify the pins are sending the data...

EDIT: after changing the clock to HSI16 mhz clock and the BRR value corresponding to the clock the TXE in ISR now gets updated upon writing to TDR but never sets again and the code hangs in the wait loop... EDIT2: The HSI clock just needed to be set from the RCC_CR register it's working probably now


.syntax unified

.include "stm32l432kc.inc"

.type RESET_HANDLER, %function

    @first Enable clock for the GPIO pins used for the uart
    ldr     r1, =RCC_AHB2ENR
    ldr     r0, [r1]
    orr     r0, #(1 << 0)
    str     r0, [r1]

    @configure the pins for usart peripheral 
    @set the PA2, PA3 to alternate function mode 7 for the USART2 (writing 01 into each pin)
    ldr     r1, =GPIOA_MODER
    ldr     r0, [r1]
    orr     r0, #(5 << 5)       @setting the highest bit of each pin together
    str     r0, [r1]
    ldr     r2, =(5 << 4)       @clearing the lowest bit of each pin together  
    mvn     r2, r2
    and     r0, r2
    str     r0, [r1]

    @next put value 7 in the alternate function reg 
    ldr     r1, =GPIOA_AFRL
    ldr     r0, [r1]
    orr     r0, #(7 << 8)
    orr     r0, #(7 << 12)
    str     r0, [r1]

    @seoncdly configure the USART2 peripheral
    @enable the clock for USART2 peripheral
    ldr     r1, =RCC_APB1ENR1
    ldr     r0, [r1]
    orr     r0, #(1 << 17)
    str     r0, [r1]

    @choose sysclk for usart2
    ldr     r1, =RCC_CCIPR
    ldr     r0, [r1]
    orr     r0, #(1 << 3)
    str     r0, [r1]

    @load the baud rate of 9600 to BRR
    ldr     r1, =USART2_BRR
    ldr     r0, =0x683
    str     r0, [r1]

    @enable the transmission block and usart peripheral 
    ldr     r1, =USART2_CR1
    ldr     r0, =(1 << 3)
    str     r0, [r1]
    orr     r0, #(1 << 0)
    str     r0, [r1]

    @transmit ones indefinitely
    ldr     r1, =USART2_ICR
    ldr     r0, =(1 << 7)
    str     r0, [r1]

    ldr     r1, =USART2_TDR
    ldr     r0, =49
    ldr     r2, =USART2_ISR
    str     r0, [r1]
        ldr     r4, [r2]
        mov     r3, #(1 << 7)
        ands    r3, r4
        beq     wait
        b       INF_LOOP

  • 2
    \$\begingroup\$ Your code seems to assume the MCU runs at 72 MHz. Why? There is no indication to change the default clocks. \$\endgroup\$
    – Justme
    Commented Feb 9, 2022 at 13:29
  • \$\begingroup\$ @Justme I just came from an arduino background so don't really understand what you mean what part of my code assumed that and why does it matter ? \$\endgroup\$ Commented Feb 9, 2022 at 13:58
  • 2
    \$\begingroup\$ It matters when you "@load the baud rate of 9600 to BRR". The value you load into the BRR to get a particular baud rate depends on the clock frequency you're supplying to the UART module. 0x1D4C is 7500. 9600 x 7500 is 72MHz, so if your clock is not 72MHz then you need a different BRR value. \$\endgroup\$
    – brhans
    Commented Feb 9, 2022 at 14:06
  • \$\begingroup\$ YUP, that was it the BRR value was invalid and after changing to HSI needed to enable it first thanks! \$\endgroup\$ Commented Feb 9, 2022 at 15:13
  • 2
    \$\begingroup\$ Also in case you do clock the system clock that high, I believe you need to fiddle with wait state settings. \$\endgroup\$
    – Lundin
    Commented Feb 9, 2022 at 15:24

1 Answer 1


Problem is that baud rate setting value assumes a system clock of 72 MHz but system clock is not set to 72 MHz.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.