For the final, definitive answer to this question, jump straight down to the section below titled “Final answer to my question“.

UPDATE 30 Oct. 2018: I was accidentally referencing the (slightly) wrong documents (but which said the exact same thing), so I’ve fixed them in my answer here. See “Notes about the 30 Oct. 2018 changes” at bottom of this answer for details.

I definitely don’t understand every word here, but the ARM v7-M Architecture Reference Manual (Online source; PDF file direct download) (NOT the Technical Reference Manual [TRM], since it doesn’t discuss atomicity) validates my assumptions:

So…I think my 7 assumptions at the bottom of my question are all correct. [30 Oct. 2018: Yes, that is correct. See below for details.]

---

UPDATE 29 Oct. 2018:

One more little tidbit:

Richard Barry, FreeRTOS founder, expert, and core developer, states in tasks.c…

/* A critical section is not required because the variables are of type BaseType_t. */

…when reading an “unsigned long” (4-byte) volatile variable on STM32. This means that he, at least, is 100% sure 4-byte reads and writes are atomic on STM32. He doesn’t mention smaller-byte reads, but for 4-byte reads he is conclusively sure. I have to assume that 4-byte variables being the native processor width, and also, word-aligned, is critical to this being true.

From tasks.c, lines 2173-2178 in FreeRTOS v9.0.0, for instance:

UBaseType_t uxTaskGetNumberOfTasks( void )
{
    /* A critical section is not required because the variables are of type
    BaseType_t. */
    return uxCurrentNumberOfTasks;
}

He uses this exact phrase of…

/* A critical section is not required because the variables are of type BaseType_t. */

…in two different locations in this file.

Final answer to my question: all types <= 4 bytes (all bolded types in the list of 9 rows below) are atomic.

Furthermore, upon closer inspection of the TRM on p141 as shown in my screenshot above, the key sentences I’d like to point out are:

In ARMv7-M, the single-copy atomic processor accesses are:
• all byte accesses.
• all halfword accesses to halfword-aligned locations.
• all word accesses to word-aligned locations.

And, per this link, the following is true for “basic data types implemented in ARM C and C++” (ie: on STM32):

1. bool/_Bool is “byte-aligned” (1-byte-aligned)
2. int8_t/uint8_t is “byte-aligned” (1-byte-aligned)
3. int16_t/uint16_t is “halfword-aligned” (2-byte-aligned)
4. int32_t/uint32_t is “word-aligned” (4-byte-aligned)
5. int64_t/uint64_t is “doubleword-aligned” (8-byte-aligned) <– NOT GUARANTEED ATOMIC
6. float is “word-aligned” (4-byte-aligned)
7. double is “doubleword-aligned” (8-byte-aligned) <– NOT GUARANTEED ATOMIC
8. long double is “doubleword-aligned” (8-byte-aligned) <– NOT GUARANTEED ATOMIC
9. all pointers are “word-aligned” (4-byte-aligned)

This means that I now have and understand the evidence I need to conclusively state that all bolded rows just above have automatic atomic read and write access (but NOT increment/decrement of course, which is multiple operations). This is the final answer to my question. The only exception to this atomicity might be in packed structs I think, in which case these otherwise-naturally-aligned data types may not be naturally aligned.

Also note that when reading the Technical Reference Manual, “single-copy atomicity” apparently just means “single-core-CPU atomicity”, or “atomicity on a single-CPU-core architecture.” This is in contrast to “multi-copy atomicity”, which refers to a “mutliprocessing system”, or multi-core-CPU architecture. Wikipedia states “multiprocessing is the use of two or more central processing units (CPUs) within a single computer system” (https://en.wikipedia.org/wiki/Multiprocessing).

My architecture in question, STM32F767ZI (with ARM Cortex-M7 core), is a single-core architecture, so apparently “single-copy atomicity”, as I’ve quoted above from the TRM, applies.

Further Reading:

• ARM: Is writing/reading from int atomic?
• What is the difference between atomic / volatile / synchronized?
• Can variables inside packed structures be read atomically?

Notes about the 30 Oct. 2018 changes:

• I had this reference: ARMv7 TRM (Technical Reference Manual). However, this is wrong in 2 ways: 1) This isn’t a TRM at all! The TRM is a short (~200 pgs) Technical Reference Manual. This, however, is the “Architecture Reference Manual”, NOT the TRM. It is a much longer and more generic document, as Architecture reference manuals are on the order of ~1000~2000 pgs it turns out. 2) This is for the ARMv7-A and ARMv7-R processors, but the manual I need for the STM32 mcu in question is for the ARMv7-M processor.
• Here is the correct link to the ARM Cortex-M7 Processor Technical Reference Manual. Online: https://developer.arm.com/docs/ddi0489/latest. PDF: https://static.docs.arm.com/ddi0489/d/DDI0489D_cortex_m7_trm.pdf.
• The correct TRM just above, on p99 (5-36) says, “For more
  information on atomicity, see the ARM®v7-M Architecture Reference Manual.” So, here is that manual. Online download link: https://developer.arm.com/products/architecture/cpu-architecture/m-profile/docs/ddi0403/latest/armv7-m-architecture-reference-manual. PDF: https://static.docs.arm.com/ddi0489/d/DDI0489D_cortex_m7_trm.pdf. It discusses atomicity on p79-80 (A3-79 to A3-80).

To create atomic access guards (usually by turning off interrupts when reads and writes are not atomic) see:

1. [my Q&A] What are the various ways to disable and re-enable interrupts in STM32 microcontrollers in order to implement atomic access guards?
2. My doAtomicRead() func here which can do atomic reads withOUT turning off interrupts