Detailed programming reference for specific boards?

[PhilBrown]

Are there register programming references for specific boards?

Its really confusing when there are a whole bunch of "STM32" cpus, that i would think should share common register offsets, but STM32F4 has completely different offsets from STM32L4, for example.

(I'm mostly interested in the GPIO, for led and button)

So far, the best I've been able to do, is try to reverse-engineer the combined headers.

But there are so many layers, its confusing.

I'm trying to write assembly, so using the headers as-is, is not possible.

My specific products of interest are

• Nucleo-ST32F401RE
• Nucleo-ST32L476 (VG?)

[PhilBrown]

Seems like i managed to dig up a certain amount of the information myself, in an odd turn of google search trails.

Random factoid: it doesnt help that STM CHANGED its reference manual numbering.

"RM0090" used to be

"STM32F40x, STM32F41x, STM32F42x, STM32F43x advanced ARM-based 32-bit MCUs"

but at some point they changed it to be

STM32F405/415, STM32F407/417, STM32F427/437 and STM32F429/439 advanced Arm®-based 32-bit MCUs

Now the relevant documentation is

RM0368

STM32F401xB/C and STM32F401xD/E advanced Arm®-based 32-bit MCUs

It would still be nice to find a nucleo-board-specific reference though

[KnarfB]

There is nothing board specific with the MMIO register offsets. Your primary source should be the vendor websites for the chip and the board. You find the board schematics on the board site under CAD ressources for LED and button wiring, and the chip info in the data sheet and reference manual.

hth

KnarfB

[waclawek.jan]

> at some point they changed it

I'm not sure it's relevant to complain about a change which happened almost a decade ago. ST initially did not plan to make the lower-end 'F4 such as the 'F401, the naming/nyumbering scheme then collided when they did.

The Nucleo is barely more than just expansion of all the target mcu's pins. So, you refer to the usual "trinity" (RM/DS/ES) of the target chip, plus, as KnarfB said, the UM and schematics of the Nucleo board (to be found on Nucleo board's own webfolder).

Assembler is quite unusual to be used in conjunction with the 32-bitters, and there are good reasons for that (inhuman constraints mainly in constants, large number of registers again with constraints in usage, complex timing), hence there's no direct support. You may want to start with the usual C programming, perhaps moving to asm for fractions to be fine-tuned.

JW

[PhilBrown]

Could anyone possibly give me more specific details on where to find the board specific stuff?

The Nucleo is made by STM, but their own website for it,

https://www.st.com/en/evaluation-tools/nucleo-f401re.html#documentation

has literally ZERO documents specific to the board.

It references a few nucleo general docs, but the "data brief" doesnt have the programming level info

{ie: pin specifics, especially for the builtins like the lights and buttons}

where am i supposed to look?

[KnarfB]

The user manual contains more UM1724 STM32 Nucleo-64 boards (MB1136)

and the board schematics are under https://www.st.com/en/evaluation-tools/nucleo-f401re.html#cad-resources, mind the corrrect board revision of your board.

Programming at the register level is in the reference manual of the chip.

Electrical characteristics of the chip are in the chip data sheet.

> (I'm mostly interested in the GPIO, for led and button)

There are many web tutorials and videos on that. You just have to find out where the user LED and button are connected (schematics or user manual).

An unofficial but illustrative site: https://os.mbed.com/platforms/ST-Nucleo-F401RE/

hth

KnarfB

[PhilBrown]

Thanks for the references.

Its unfortunate that there are button examples for other boards out there, but not for this one specifically, that I've found.

I have theoretical code, but it isnt working. I was hoping that the pin info I had gleaned elsewhere was wrong, so was looking for other places. But mbed.com does also say C13 is the button pin.

Which sadly leaves me with no recourse but to share my ugly code :\

https://github.com/ppbrown/arm_stm32_blink/blob/try-button/blink_stm32f4.s

I have OUTPUT to led working.

But when I use the same methods to try enabling and reading the userbutton...

I get nothing from INPUT.

Might anyone have suggestions what I'm doing wrong?

[Tesla DeLorean]

ST partitions things, the same IC's are used on the Nucleo boards, are used everywhere else. The functionality of the chips is described in the Reference Manuals (RM), the Data Manual (DM) cover performance at pin/device level where the bond-out of the same IC is constrained by the pin count of the different package. Only a subset of functionality can be escaped on any specific device.

The User Manuals for the assorted Nucleo boards typically cover a whole group of related board designs. These provide pin maps and details of solder bridges, default, LEDs and UARTs are covered here. The UM used to have schematics, but as the boards have expanded and changed over the years the schematics are now separate files, usually in "CAD Resources" rather than "Documentation" tabs. One board is designed to support multiple chips, and the default options allow for the most common usage, whilst facilitating alternate usage. This often impacts the usage of Arduino shields, how those might be wired, and how limited resources like UART might be wired. See NUCLEO-64 typically share Arduino D0/D1 pins with those used by the ST-LINK's VCP UART.

The schematics are a good point of reference, there are also Include files as part of the CubeF4 packages for various boards, via BSP Board Support Package.

Historically one might use AWK, or other scripting, to process .SVD files or Compiler Pre-Processor output to extract defines, structures and details in export them in a form suitable for assemblers. ie use EQU, create .INC files, etc. Modern assemblers can frequently just pull include files.

The market tends to focus on what the bulk of customers are using, so the compilers and include files will get all the attention.

Between the DM and RM you should be able to get the base addresses of all the peripherals, and register offsets within each of these instances. For the processor cores either the ARM TRM or ST Programming Manuals (PM) should cover the Cortex-M, along with resources like Joseph Yiu's books on the more practical side.

[waclawek.jan]

> Might anyone have suggestions what I'm doing wrong?

May I suggest a way how do you find it out yourself? Try to run this under debugger, and read out and check/post relevant registers' content.

JW

PS How do you do the vector table? Is stack pointer OK?

[waclawek.jan]

Also, one wonders, how exactly do you distinguish between "works" and "not works", and whether you are aware of bouncy buttons.

JW