Remember my question earlier about delay speed?

Are you really, really sure that your delay will make a significant delay.

Best is to use the timer to keep track of the delay time.

But if you don't, and decide to still go ahead with a busy loop written in C, then you should at least spend more time trying to make your delay more optimization-proof.

At least make the loop variable volatile, and make the loop call another, non-static, function.

void dummy_function(unsigned);

void stupid_sw_only_delay_that_will_hurt_someone(unsigned steps) {
    volatile unsigned i;
    for (; steps; steps--) {
        for (i = 0; i < 20000; i++) {
            dummy_function(i);
        }
    }
}

void dummy_function(unsigned i) {
}

Yes - a very silly software only delay. Not recommended. Will change delay time depending on used compiler, compiler version, optimization settings, time of day or if the moon is full or not. In short - a delay that will hurt you. But at least a slightly better delay than the one you have. The above delay can still fail badly if the compiler has good global optimization, in which case it notices that dummy_function() really is a dummy function. And the language standard isn't 100% clear about the meaning of a volatile auto variable so the compiler just might eat everything.

You have been warned.

But flickering diodes is the expected result of a insufficient delay.

And you did not return with information about what delay the simulator suggested you got.