For example, I took over a piece of code that ran on a DSP on an audio card. This code handled PCI bus transfers and I needed to change the shot size and optimize it - a lot. So, parts became Motorola DSP assembly language. I had to find a lot of tricks, using unused bits in wide registers as cycling counters, fun stuff like that. But I got it working and it became very reliable.
I've written low-level code for other DSPs, particularly code that handles audio mixing, does filtering and sample-rate conversion, and things like that.
I also have written low-level driver code for various embedded processors in C, including code that drives SPI peripherals.
One of the more interesting challenges is writing driver code that allows writing to on-chip flash memory. The code is executing right out of flash memory, but then you need to program pages from a write buffer into the same flash memory. To do this you have to jump to a function that is guaranteed to be in RAM, change the chip configuration such that the memory mapping behaves differently, write the page, put the chip configuration back to normal, and then continue executing the out of flash.
Other fun "critical" code includes bootloaders that upload a new version of the firmware, and it's interesting what they have to do, to then start executing the firmware. They have to stop interrupts including clocks, set some critical registers, and then NOT re-enable interrupts, but take a "soft reset" and launch the new program, which then will re-enable interrupts after it gets itself set up.
I really enjoy this kind of low-level stuff, which I guess makes me an outlier, but on the other hand it's been good for my career to carve out a niche doing stuff that a lot of people don't want to do.
Oh - for a slightly different definition of "critical," I've also been employed writing test code for medical devices (and found bugs in medical device firmware this way).