extern "C"around all of your C file includes.
quantum/serial_link/tests folder, and follow the steps below to create a similar structure.
rules.mkfile in that folder.
testlist.mkfile. Each group defined there will be a separate executable. And that's how you can support mocking out different parts. Note that it's worth adding some common prefix, just like it's done for the serial_link tests. The reason for that is that the make command allows substring filtering, so this way you can easily run a subset of the tests.
_SRCfor source files
_DEFSfor additional defines
_INCfor additional include folders
make test:all. You can also run test matching a substring by typing
make test:matchingsubstringNote that the tests are always compiled with the native compiler of your platform, so they are also run like any other program on your computer.
./build/testfolder. You should be able to run those with GDB or a similar debugger.
CONSOLE_ENABLE=yesto the tests
VARIABLE_TRACE=xto the end of you make command.
xrepresents the number of variables you want to trace, which is usually 1.
ADD_TRACED_VARIABLE, to begin the tracing. For example to trace all the layer changes, you can do this
layer_state. It tracks 4 bytes (the size of
layer_state), so any modification to the variable will be reported. By default you can not specify a size bigger than 4, but you can change it by adding
MAX_VARIABLE_TRACE_SIZE=xto the end of the make command line.
VERIFY_TRACED_VARIABLESaround the code that you think that modifies the variable. If a variable is modified it will tell you between which two
VERIFY_TRACED_VARIABLEScalls the modification happened. You can then add more calls to track it down further. I don't recommend spamming the codebase with calls. It's better to start with a few, and then keep adding them in a binary search fashion. You can also delete the ones you don't need, as each call need to store the file name and line number in the ROM, so you can run out of memory if you add too many calls.