Add pre-default-start-trap feature

[bjoernQ]

In esp-hal we offer the "flip-link" feature.

When SP moves below RAM an exception is raised but we need a way to check that situation and move SP into RAM again before further processing.

One way would be to define our own _default_start_trap - another way would be to have a way to execute custom code before _default_start_trap which this PR implements.

Not sure if this is the best way to do it but it's simple and should work good enough.

This should be the last missing step to use riscv-rt in esp-hal. (see esp-rs/esp-hal#2390)

Let me know if you want me to change anything

[romancardenas]

LGTM! Could you include a sample example in the docs to illustrate how to implement the new routine?

[bjoernQ]

I tried to come up with a more or less interesting and realistic example - but it might not be brief enough, let me know if I should reduce it to a minimum

[romancardenas]

Usually, we just include an empty implementation with a comment like // your code goes here, just to avoid too long/complex examples.

[bjoernQ]

Usually, we just include an empty implementation with a comment like // your code goes here, just to avoid too long/complex examples.

Makes sense - will change it 👍

[romancardenas]

LGTM! A few comments:

• should the docs explicitly say that the new symbol must be in the .trap.start section?

• currently, the new symbol is only used in direct mode and in exceptions with vectored mode. Do you need this to be included in the _continue_trap symbol for vectored interrupts?

[bjoernQ]

Thanks for the quick reply!

should the docs explicitly say that the new symbol must be in the .trap.start section?

It's probably worth to add a recommendation to avoid people running into linker errors later. I will add that 👍

currently, the new symbol is only used in direct mode and in exceptions with vectored mode. Do you need this to be included in the _continue_trap symbol for vectored interrupts?

For me at least it's only needed for exceptions (in vectored mode). I guess having it for everything in direct mode is fine but I can't think of a case where I need it for vectored interrupts. Should I note this in the docs? (i.e. that it won't get called for vectored interrupts)

[romancardenas]

Sounds good to me. Let's document everything and leave it as it is

[romancardenas]

LGTM! Thanks