Your goal is to minimize the hash rate of the attacker based on the resources you have. The cracker's goal is to maximize their hash rate.
Find out what parameters work well for your hardware. Pick a few variants. (More passes with less memory, as much fast memory as possible with as many passes as that permits, as much slow memory with however many passes you can afford, and a few minor tweaks on whatever cost parameters those give you.)
Next, for each variant test how many hashes per second you can get out of a good x64 PC or server. Although you can't benefit from multi-threading for your application, the password cracker can. You should leave p=1 but for your hash rate benchmark spawn a variable number of threads. Each thread of the benchmark process should call the Argon2 library in a loop to independently hash random inputs.
How many simultaneous evaluations that can be done to maximize the hash rate depends on the cracking rig's hardware and the Argon2 parameters chosen. Obviously you get diminishing returns, but I don't know of a way to estimate the optimal number of threads.
Because you have such little memory, even if you use all 32 MiB, demand for RAM would likely not be the limiting factor on a commodity hardware cracking rig. It would most likely be RAM bandwidth or the number of available cores.
Testing on an appropriate x64 machine is probably a good enough method to reason about maximum cracking hash rates. Normal GPUs cannot handle Argon2. When an FPGA user needs large amounts of memory, I think they have the FPGA communicate with commodity hardware so most of their memory is basically the same as "normal" RAM.
I haven't read much about Argon2 ASIC cracking. If you can make multiple passes on your own hardware to make the TMTO costly, then the cracker's hash rate should suffer if they try to reduce chip area by reducing memory. I also bet that 6 MiB would be good enough to limit how much an advantage ASICs could have, but I definitely have no evidence for that.
The Argon2 paper recommends that the algorithm be used with on the order of a gigabyte of RAM. I'm not sure if the authors would recommend using much much less memory, but the algorithm is flexible enough to work with a lot less. If all you have is a few MiB, then that's the best you can do.
They also recommend using as many threads as available. It's obviously preferable to use more, but I think adding more threads on the defender's side doesn't do much more than linearly reducing the cracker's hash rate.
My guess is that using all available fast RAM and none of the slow RAM would work best for unmodified Argon2. Do you have SIMD support on your processor? If not then quickly filling much more than 6 MiB of RAM might be hard on a slow single core computer.
I really don't know enough about hardware to have much confidence in my own speculation on which method is best. There are so many factors involved in Argon2 performance and we don't have any hard numbers, so I think it's best to benchmark.