DS tracing is a bit different to other systems by virtue of the filesystem, though you can still make it happen.
Anyway there are three main choices for a debugging emulator (probably a better search term than tracer, though most around here will know what you are talking about) on the DS
Has some very simple options like run to line. Have it if you want but no$gba is better.
desmume does have a few light options and the ability to attach to a debugger, also a pretty nice cheat search these days.
no$gba used to be paid but now is free. It is your classic graphical debugger with the breakpoints, CPU data, tile viewers... and a few more advanced things as well.https://problemkaputt.de/gba-dev.htm
Some will flank it with crystaltile2 which has a nice disassembler, decompression tools and support for some of the more advanced formats no$gba supports.
While melonds is becoming some people's favourite playing emulator it has next to nothing as far as debugging at this point. I don't think any of the tool assisted speedrun (TAS) folks have anything of great note here among their mods -- for many systems they are often some of the better debuggers if you can twist them to your ends (ROM hacking and speedrunning are a bit different, even if they both care about memory and knowing what a system is doing).
Tracing then, as in finding a piece of data in the ROM, works a bit differently to the GBA and older things. The DS has a file system and the ROM itself is not visible in memory. Fortunately however the DS has a fairly simple protocol (albeit encrypted a bit, said encryption has long been known/broken though).http://problemkaputt.de/gbatek.htm#dscartridgeprotocol
Command B7 is what you want to be looking at here.
Once you have an address you will want to relate it back to the file within the ROM. Again crystaltile2 comes in handy here as it will tell you what file a give selection in the various windows it has will correspond to, and its file viewer will also allow you to double click to go to it. Don't know about the likes of tinke and MKDS course modifier. If push comes to shove then you can go manual as well or scan through a printout from ndstool (it think it has the option to print locations of files within the ROM).
On top of this the DS has long had archive formats (you might have met NARC/CARC already, there are hundreds more and it is nothing unusual to see a non nintendo game do something completely custom) and compression was cheap and easy to use with notable gains so devs used it loads of the time. Some games also load absolutely everything as an overlay (or in the ARM9 binary), and overlays in general are fun to work with.
I tend not to find DS games doing any modification to files beyond decompression but things like shifts or having to run a mask to get rid of an indicator bit (the NARC format when indicating a subdirectory is a good example of this) are not unheard of.
As well as general archives then there are also the file formats you likely are already familiar with (or soon will be) so you can often have several layers of pointers and size values to cut through/modify if you increase or decrease file sizes or change location. They are usually nothing major, and actually quite nice to work with as far as pointers go (big three being from the start of the file, from the start of the section or relative to the pointer itself).