"In Extended Palette and Texture Image/Palette modes, VRAM is not mapped to CPU address space, and can be accessed only by the display controller (so, to initialize or change the memory, it should be temporarily switched to Plain-CPU mode).
All VRAM (and Palette, and OAM) can be written to only in 16bit and 32bit units (STRH, STR opcodes), 8bit writes are ignored (by STRB opcode). The only exception is "Plain <ARM7>-CPU Access" mode: The ARM7 CPU can use STRB to write to VRAM (the reason for this special feature is that, in GBA mode, two 128K VRAM blocks are used to emulate the GBA's 256K Work RAM)."
I can not say I have ever observed this on the DS but I usually tackle it from the file format side rather than the 3d debugging side (mainly as debugging of the DS' 3d systems is pretty limited).
In practice this would probably take the form of seeing the various VRAMCNT registers have the relevant bits set low to put it in CPU mode, doing whatever needs doing and then having the bits set back.
Considered from within the whole vblank/hblank and 3d system almost running in parallel I am not sure how it would look at low level or from a higher level workflow diagram approach but I am not expecting any real weirdness.