Test it thoroughly so they aren't constantly calling and complaining... or when they do you know it's their fault.
Seriously, if you code functionality, be it using IRQs or DMAs, make sure it works in a couple of scenarios, both simple and stressed.
Catch dumb usage with asserts(), especially if there are known limits on memory regions or alignments.
Assume they won't check error returns, be able to instrument or assert when errors are ignored in cascade failure.
Assume callbacks and pointers will be passed as NULL
If you use malloc()/free() make sure you can detect failures there, out of memory, double free, orphans.
If you have sanity checks they'll learn not to call until those are cleared.
Test the code you write. Test the QSPI, test the serial interfaces, test they all work together.
Check every pin on the schematic, understand what kind of coverage you have, and which are most critical to the teams. If need be loop back pins / uarts and check things that would be off-board or pending other development or parts.
Have Error_Handler() and HardFault_Handler() output comprehensive information so you can immediately go to source lines in your BSP and understand what might have broken, and if a new assert is required. Be in a position to bat balls immediately back over the net, not scrabble to understand the failure each time, don't be the person to blame for holding up development. You want their manager holding their feet to the fire, not yours.
Use the slack time you now don't have to triage everything in to testing a larger number of corner cases.
Run lint or other coverage / static analysis tools on your code, find the holes before others.
