Error in MK22DX256VLF5 reference manual and data sheet

[scottm]

Both the reference manual and the data sheet for the MK22DX256VLF5 list pin 33 as I2S0_TXD1 (for MUX alt 6), but every other source indicates that the part has only one I2S transmit line.  Here's the page in the reference manual.

This nearly bit me - I was porting a project from another K22 part with two I2S transmitters and used that table to verify that it did have a second TXD, because it was the quickest place to find the information.  Thankfully that second TXD didn't turn out to be needed on this board.

I've gotten so frustrated with the documentation that I've started compiling my own quick reference for each part I use.  Rather than flipping through three sections of the manual every time I need to figure out what the clock sources for a particular module are, for example, I'm taking a little longer to write it up in the most concise format I can.

If someone else has already started a project like this, I'd love to see it.  If I get one part's quick reference completed, I'll share it in case anyone else finds it useful, and to use as a template for other parts.

Scott

[miduo]

Hello,

Well, you are right. There has only one TX data line and it's I2S0_TXD0, the same goes for the RX data line. The information on the pinout table of the reference manual and datasheet that showing I2S0_RXD1 and I2S0_TXD1 is wrong. Sorry for the confusion. This typo has been reported and hope it will been corrected soon.

[scottm]

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

[miduo]

Hello, Scott

Thanks for your valuable points. Really appreciated! I will make them awarded by document team.