-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cpu: centralized startup code for cortexm CPUs #3155
cpu: centralized startup code for cortexm CPUs #3155
Conversation
#endif | ||
|
||
/** | ||
* @brief Use this macro to make interrupt functions over writable with the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/over writable/overridable/
@haukepetersen I will try to port this to k60, and possibly kw2x during next week, if time permits. |
fixed spelling |
@haukepetersen @gebart I was so free and have adapted it to kinetis. @haukepetersen Can I open a PR against your Branch? |
@haukepetersen I was impatient and did it haukepetersen#11. @gebart Can you review and test it on mulle it please? |
@jfischer-phytec-iot: looking great, merged! |
I get a hard fault at the end of pre_startup on k60. The return pointer gets overwritten by the canary value and popped. Edit: The old implementation was a noreturn and jumped to the reset handler after pre_reset |
You could delete the stack canary filling, or move it to Cortex M common. The purpose of it is to fill the ISR stack with a known value so that we can measure ISR stack usage by looking through the memory. |
Damn, I miss it, of course it raises hardfault. |
@gebart @haukepetersen corrected: haukepetersen#12 |
I'm on mobile so I can't comment inline. Looks good, I don't think you need
to keep the estack extern in the k60 file though.
|
@jfischer-phytec-iot: I merged your fix without really looking into it too much. I will look over this complete PR in detail once more on Monday. |
Ok, as far as I see it, the changes look good and this PR should be ready for merge. Should I squash and start Travis? |
@haukepetersen do it :-) |
9d74407
to
07dcc4d
Compare
did, ready for Travis :-) |
|
07dcc4d
to
1ea00d1
Compare
fixed whitespace issue and rebased. |
I guess we can merge it ... |
just needs a little rebase as #3095 was finally merged. Doing this now. |
1ea00d1
to
a723951
Compare
rebased, hopefully I didn't break anything... So lets wait for Travis again and merge once he is happy? |
a723951
to
88130fc
Compare
- make use of common startup code - make use of common exception handlers - renamed startup.c to vectors.c
- make use of common startup code - make use of common exception handlers - renamed startup.c to vectors.c
- make use of common startup code - make use of common exception handlers - renamed startup.c to vectors.c
- make use of common startup code - make use of common exception handlers - renamed startup.c to vectors.c
- make use of common startup code - make use of common exception handlers - renamed startup.c to vectors.c
- make use of common startup code - make use of common exception handlers - renamed startup.c to vectors.c
- make use of common startup code - make use of common exception handlers - renamed startup.c to vectors.c
- make use of common startup code - make use of common exception handlers - renamed startup.c to vectors.c
- make use of common startup code - make use of common exception handlers - renamed startup.c to vectors.c
- make use of common startup code - make use of common exception handlers - renamed startup.c to vectors.c
- make use of common cortexm isr vectors - use common cortexm startup code - renamed startup.c to vectors.c
Travis happy, go |
yeah! |
cpu: centralized startup code for cortexm CPUs
The startup code and exception handlers for cortexm based CPUs were pretty much identical, so centralizing them makes much sense.
@gebart, @jfischer-phytec-iot: I was not blunt enough to touch the kinetis code (as it still differs quite a bit from how we implemented all other platforms). Would you care to have a look at this as a follow-up?
Note: github does a shitty job on showing the actual diffs here. The changes are not as bad as it seems...