Thanks Fang. If the docs are going to get updated at some point, I can probably recommend a few other changes as well.
The amount of RAM listed is somewhat ambiguous. The selector table doesn't show anything in the SRAM column - there's just a note in the part description column. The data sheet, which says it applies to MK22DX128VLF5 and MK22DX256VLF5 parts, says up to 64 kB of RAM, which is incorrect - neither of those parts supports 64 kB of RAM.
Now, if someone reads that in the data sheet and skips to the system memory map in the reference manual, they might be forgiven for thinking that it has 64 kB of RAM after all because the memory map indicates a 64 kB range.
The same memory map also shows a massive 128 MB range for program flash (actual size is 256 kB) so presumably that's the maximum space allocated by the architecture. There's nothing to indicate that, or what family it applies to. No part in the Kinetis line has that much flash, but many have more the the 64 kB of RAM shown in this map, so it's hard to understand why one entry would be a theoretical maximum and one would be the actual maximum within the part family - but not specific to the listed parts. In any case, this memory map is not one a developer could use to write a linker script, and it's not entirely obvious what it's supposed to mean.
The data sheet also says "Four UART modules". Not "up to four", not "depending on package", but exactly four UARTs. The chip configuration section of the reference manual agrees. The pinouts, however, indicate that only three UARTs are bonded out on this part. I know it's not NXP's convention to list 'buried' UARTs because the MK22FN1M0AVLH12 has at least four or five on the die (I've used one for a stupid DMA trick) but it only lists three.
I understand that the documents are made with a cut-and-paste process with the goal of avoiding rewriting common sections for each part, but it's just not done very consistently and it makes for very disjointed documents. Programmers are used to writing code that uses macros and text substitution to manage that kind of redundancy, and the same thing can be done with documentation. I ported such a system from WordMARC to MS Word about 20 years ago. If I can editorialize a bit, I'd like to say that it'd probably be an improvement both for the document writers and for customers if the documents were built that way, where someone enters the chip configuration information and it flows to all of the relevant tables and text sections. Simply having each module list the actual clock sources available, for example, without having to jump to one or two other sections of the manual and match up signal names would be an improvement.
Regards,
Scott
