-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Start to STM32F4XX port #8
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
value is used straight away.
counter is enabled, and uses the capture/compare register rather than the auto-reset register to trigger interrupts.
emilmont
pushed a commit
that referenced
this pull request
Aug 2, 2013
PrzemekWirkus
added a commit
that referenced
this pull request
May 4, 2015
Synd with master (27 April 2015)
kpurusho
added a commit
to kpurusho/mbed
that referenced
this pull request
Nov 3, 2015
…hange to atmel * commit '57dd8871eea40ad48ce1e8f3624a12289e331b56': * Renamed TARGET_SAM_CortexM0+ to TARGET_SAM_CortexM0P for compatiblity with online compiler
bridadan
pushed a commit
that referenced
this pull request
Jun 21, 2016
Fix merge of support for --source for exporters
SeppoTakalo
pushed a commit
that referenced
this pull request
Nov 9, 2016
Coap service security fixes
bremoran
added a commit
to bremoran/mbed-os
that referenced
this pull request
Jul 26, 2018
`handle_error` calls `MBED_CALLER_ADDR()`, but this is always a location from within platform/mbed_error.c. This is because `handle_error` is declared static. This does not cause the function to be inlined however. Instead, it is called by each function within mbed_error.c. For example, mbed_error yields this code: ``` 000625c8 <mbed_error>: 625c8: b510 push {r4, lr} 625ca: 460c mov r4, r1 625cc: 4611 mov r1, r2 625ce: 461a mov r2, r3 625d0: 9b02 ldr r3, [sp, ARMmbed#8] 625d2: f7ff feff bl 623d4 <handle_error> 625d6: b968 cbnz r0, 625f4 <mbed_error+0x2c> 625d8: 4620 mov r0, r4 625da: f7ff ff67 bl 624ac <print_error_report.constprop.0> 625de: f7ff fea8 bl 62332 <core_util_is_isr_active> 625e2: b910 cbnz r0, 625ea <mbed_error+0x22> 625e4: f7ff fe9f bl 62326 <core_util_are_interrupts_enabled> 625e8: b908 cbnz r0, 625ee <mbed_error+0x26> 625ea: bf30 wfi 625ec: e7fd b.n 625ea <mbed_error+0x22> 625ee: 2001 movs r0, ARMmbed#1 625f0: f000 f948 bl 62884 <__wrap_exit> 625f4: 4800 ldr r0, [pc, #0] ; (625f8 <mbed_error+0x30>) 625f6: bd10 pop {r4, pc} 625f8: 80ff010f .word 0x80ff010f ``` Note that at `625d2` there is a bl to handle error. That replaces the LR, which means that ALL calls to mbed_error will report a location of 0x625d6 or 0x625d7 (user vs. supervisor). I do not expect that this was the intention of the code. The simplest fix is to change line 99: ```C static inline mbed_error_status_t handle_error(mbed_error_status_t error_status, unsigned int error_value, const char *filename, int line_number) ``` Since `handle_error()` will be inlined, the link register will be kept the same, so `MBED_CALLER_ADDR()` will yield the expected result. However, there is no guarantee that the compiler will respect the `inline` keyword in all circumstances. The result is that each function that wishes to report its caller must extract its caller. This code cannot be centralised. I have modified `mbed_error.c` to report the caller of each error reporting function, rather than the error reporting function itself.
cmonr
pushed a commit
that referenced
this pull request
Jul 27, 2018
`handle_error` calls `MBED_CALLER_ADDR()`, but this is always a location from within platform/mbed_error.c. This is because `handle_error` is declared static. This does not cause the function to be inlined however. Instead, it is called by each function within mbed_error.c. For example, mbed_error yields this code: ``` 000625c8 <mbed_error>: 625c8: b510 push {r4, lr} 625ca: 460c mov r4, r1 625cc: 4611 mov r1, r2 625ce: 461a mov r2, r3 625d0: 9b02 ldr r3, [sp, #8] 625d2: f7ff feff bl 623d4 <handle_error> 625d6: b968 cbnz r0, 625f4 <mbed_error+0x2c> 625d8: 4620 mov r0, r4 625da: f7ff ff67 bl 624ac <print_error_report.constprop.0> 625de: f7ff fea8 bl 62332 <core_util_is_isr_active> 625e2: b910 cbnz r0, 625ea <mbed_error+0x22> 625e4: f7ff fe9f bl 62326 <core_util_are_interrupts_enabled> 625e8: b908 cbnz r0, 625ee <mbed_error+0x26> 625ea: bf30 wfi 625ec: e7fd b.n 625ea <mbed_error+0x22> 625ee: 2001 movs r0, #1 625f0: f000 f948 bl 62884 <__wrap_exit> 625f4: 4800 ldr r0, [pc, #0] ; (625f8 <mbed_error+0x30>) 625f6: bd10 pop {r4, pc} 625f8: 80ff010f .word 0x80ff010f ``` Note that at `625d2` there is a bl to handle error. That replaces the LR, which means that ALL calls to mbed_error will report a location of 0x625d6 or 0x625d7 (user vs. supervisor). I do not expect that this was the intention of the code. The simplest fix is to change line 99: ```C static inline mbed_error_status_t handle_error(mbed_error_status_t error_status, unsigned int error_value, const char *filename, int line_number) ``` Since `handle_error()` will be inlined, the link register will be kept the same, so `MBED_CALLER_ADDR()` will yield the expected result. However, there is no guarantee that the compiler will respect the `inline` keyword in all circumstances. The result is that each function that wishes to report its caller must extract its caller. This code cannot be centralised. I have modified `mbed_error.c` to report the caller of each error reporting function, rather than the error reporting function itself.
cmonr
pushed a commit
that referenced
this pull request
Jul 28, 2018
`handle_error` calls `MBED_CALLER_ADDR()`, but this is always a location from within platform/mbed_error.c. This is because `handle_error` is declared static. This does not cause the function to be inlined however. Instead, it is called by each function within mbed_error.c. For example, mbed_error yields this code: ``` 000625c8 <mbed_error>: 625c8: b510 push {r4, lr} 625ca: 460c mov r4, r1 625cc: 4611 mov r1, r2 625ce: 461a mov r2, r3 625d0: 9b02 ldr r3, [sp, #8] 625d2: f7ff feff bl 623d4 <handle_error> 625d6: b968 cbnz r0, 625f4 <mbed_error+0x2c> 625d8: 4620 mov r0, r4 625da: f7ff ff67 bl 624ac <print_error_report.constprop.0> 625de: f7ff fea8 bl 62332 <core_util_is_isr_active> 625e2: b910 cbnz r0, 625ea <mbed_error+0x22> 625e4: f7ff fe9f bl 62326 <core_util_are_interrupts_enabled> 625e8: b908 cbnz r0, 625ee <mbed_error+0x26> 625ea: bf30 wfi 625ec: e7fd b.n 625ea <mbed_error+0x22> 625ee: 2001 movs r0, #1 625f0: f000 f948 bl 62884 <__wrap_exit> 625f4: 4800 ldr r0, [pc, #0] ; (625f8 <mbed_error+0x30>) 625f6: bd10 pop {r4, pc} 625f8: 80ff010f .word 0x80ff010f ``` Note that at `625d2` there is a bl to handle error. That replaces the LR, which means that ALL calls to mbed_error will report a location of 0x625d6 or 0x625d7 (user vs. supervisor). I do not expect that this was the intention of the code. The simplest fix is to change line 99: ```C static inline mbed_error_status_t handle_error(mbed_error_status_t error_status, unsigned int error_value, const char *filename, int line_number) ``` Since `handle_error()` will be inlined, the link register will be kept the same, so `MBED_CALLER_ADDR()` will yield the expected result. However, there is no guarantee that the compiler will respect the `inline` keyword in all circumstances. The result is that each function that wishes to report its caller must extract its caller. This code cannot be centralised. I have modified `mbed_error.c` to report the caller of each error reporting function, rather than the error reporting function itself.
cmonr
pushed a commit
that referenced
this pull request
Jul 30, 2018
`handle_error` calls `MBED_CALLER_ADDR()`, but this is always a location from within platform/mbed_error.c. This is because `handle_error` is declared static. This does not cause the function to be inlined however. Instead, it is called by each function within mbed_error.c. For example, mbed_error yields this code: ``` 000625c8 <mbed_error>: 625c8: b510 push {r4, lr} 625ca: 460c mov r4, r1 625cc: 4611 mov r1, r2 625ce: 461a mov r2, r3 625d0: 9b02 ldr r3, [sp, #8] 625d2: f7ff feff bl 623d4 <handle_error> 625d6: b968 cbnz r0, 625f4 <mbed_error+0x2c> 625d8: 4620 mov r0, r4 625da: f7ff ff67 bl 624ac <print_error_report.constprop.0> 625de: f7ff fea8 bl 62332 <core_util_is_isr_active> 625e2: b910 cbnz r0, 625ea <mbed_error+0x22> 625e4: f7ff fe9f bl 62326 <core_util_are_interrupts_enabled> 625e8: b908 cbnz r0, 625ee <mbed_error+0x26> 625ea: bf30 wfi 625ec: e7fd b.n 625ea <mbed_error+0x22> 625ee: 2001 movs r0, #1 625f0: f000 f948 bl 62884 <__wrap_exit> 625f4: 4800 ldr r0, [pc, #0] ; (625f8 <mbed_error+0x30>) 625f6: bd10 pop {r4, pc} 625f8: 80ff010f .word 0x80ff010f ``` Note that at `625d2` there is a bl to handle error. That replaces the LR, which means that ALL calls to mbed_error will report a location of 0x625d6 or 0x625d7 (user vs. supervisor). I do not expect that this was the intention of the code. The simplest fix is to change line 99: ```C static inline mbed_error_status_t handle_error(mbed_error_status_t error_status, unsigned int error_value, const char *filename, int line_number) ``` Since `handle_error()` will be inlined, the link register will be kept the same, so `MBED_CALLER_ADDR()` will yield the expected result. However, there is no guarantee that the compiler will respect the `inline` keyword in all circumstances. The result is that each function that wishes to report its caller must extract its caller. This code cannot be centralised. I have modified `mbed_error.c` to report the caller of each error reporting function, rather than the error reporting function itself.
pan-
referenced
this pull request
in pan-/mbed
Aug 22, 2018
`handle_error` calls `MBED_CALLER_ADDR()`, but this is always a location from within platform/mbed_error.c. This is because `handle_error` is declared static. This does not cause the function to be inlined however. Instead, it is called by each function within mbed_error.c. For example, mbed_error yields this code: ``` 000625c8 <mbed_error>: 625c8: b510 push {r4, lr} 625ca: 460c mov r4, r1 625cc: 4611 mov r1, r2 625ce: 461a mov r2, r3 625d0: 9b02 ldr r3, [sp, #8] 625d2: f7ff feff bl 623d4 <handle_error> 625d6: b968 cbnz r0, 625f4 <mbed_error+0x2c> 625d8: 4620 mov r0, r4 625da: f7ff ff67 bl 624ac <print_error_report.constprop.0> 625de: f7ff fea8 bl 62332 <core_util_is_isr_active> 625e2: b910 cbnz r0, 625ea <mbed_error+0x22> 625e4: f7ff fe9f bl 62326 <core_util_are_interrupts_enabled> 625e8: b908 cbnz r0, 625ee <mbed_error+0x26> 625ea: bf30 wfi 625ec: e7fd b.n 625ea <mbed_error+0x22> 625ee: 2001 movs r0, #1 625f0: f000 f948 bl 62884 <__wrap_exit> 625f4: 4800 ldr r0, [pc, #0] ; (625f8 <mbed_error+0x30>) 625f6: bd10 pop {r4, pc} 625f8: 80ff010f .word 0x80ff010f ``` Note that at `625d2` there is a bl to handle error. That replaces the LR, which means that ALL calls to mbed_error will report a location of 0x625d6 or 0x625d7 (user vs. supervisor). I do not expect that this was the intention of the code. The simplest fix is to change line 99: ```C static inline mbed_error_status_t handle_error(mbed_error_status_t error_status, unsigned int error_value, const char *filename, int line_number) ``` Since `handle_error()` will be inlined, the link register will be kept the same, so `MBED_CALLER_ADDR()` will yield the expected result. However, there is no guarantee that the compiler will respect the `inline` keyword in all circumstances. The result is that each function that wishes to report its caller must extract its caller. This code cannot be centralised. I have modified `mbed_error.c` to report the caller of each error reporting function, rather than the error reporting function itself.
geky
added a commit
to geky/mbed
that referenced
this pull request
Aug 25, 2018
Add NRF52840_DK SPIF pins
geky
added a commit
to geky/mbed
that referenced
this pull request
Aug 25, 2018
Fix write_enable commands and method.
bcostm
pushed a commit
to bcostm/mbed-os
that referenced
this pull request
Sep 17, 2018
NUCLEO_H743ZI: add bootloader
hugueskamba
referenced
this pull request
in hugueskamba/mbed-os
Jul 3, 2019
linlingao
added a commit
to linlingao/mbed-os
that referenced
this pull request
Jul 12, 2019
Add TI driverlib
geky
added a commit
to geky/mbed
that referenced
this pull request
Aug 4, 2019
Add set of event queue composition functions
LMESTM
pushed a commit
to LMESTM/mbed
that referenced
this pull request
Jan 8, 2020
mbed-cloud-client-example R1.3.1.1-GA
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Initial porting includes:
There are a couple of potentially iffy bits here which I'll do my best to draw attention to:
On second glance, that's starting to look like quite a long list of iffy bits 😀. Anyway, this should at least act as a jumping off point for getting this merged.
Joe