This is a really tricky thing to debug. You message says that the problem occurred at an instruction at ROM address 5497, but finding that instruction is difficult because the line numbers in the Pong.asm file don't match up with ROM addresses because labels don't require ROM locations.
Two things that I suggest are that you have your VM translator write the source VM lines into the ASM output as comments so that it makes it easier to find what the associated VM command is when you find the failing ASM command. See this post for an example. Note that I also put a filename comment in the ASM when I start processing a file so that I know which VM file contained the crashing code.
To find the actual failing instruction, you may want to have your assembler generate a listing file that shows the ROM address for every instruction in the program. See this post about my listing file.
For what it's worth, in my translation of Pong, 5497 is in Memory.alloc() in Memory.vm
There is any way to execute and test single files?
There is no easy way to deal with testing individual files in a high-level application like Pong, especially in the case of the OS .vm files where you don't have the Jack source code.
You don't need to use your VM translator to complete chapters 9-12. All of the project tests expect that you are using the VMEmulator.
Once you have written your own Jack compiler and OS, it is quite a thrill to run your game in the CPU emulator, compiled with your compiler and translated along with your OS using your VM translator!
I recommend that you precede to chapter 9 and come back to debug your VM translator after chapter 12. You will have OS source available and you can have your compiler write the Jack source into the VM it generates, and those source comments will be carried through to the ASM listing file. With my toolset, the listing file ends up looking like this, which is a great aid in debugging.