-
Notifications
You must be signed in to change notification settings - Fork 3k
M2351: Override wait_ns to provide more accurate implementation #10741
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
Conversation
At high HCLK rate, M2351 cannot provide zero-wait-state flash performance. Besides, cache is forcibly turned off for non-secure land for internal reason. We locate 'delay_loop_code' from flash to SRAM to achieve zero-wait-state performance.
@ccli8, thank you for your changes. |
}; | ||
|
||
/* Take the address of the code, set LSB to indicate Thumb, and cast to void() function pointer */ | ||
#define delay_loop ((void(*)()) ((uintptr_t) delay_loop_code | 1)) |
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.
I had a change for the main implementation that micro-optimises (nano-optimises?) this - not sure if it didn't land or you're based on old code.
If you use + 1
instead of | 1
that can be done at link time, rather than run-time. (The linker can offset symbols, but not bit-manipulate them). Saves 1 instruction and cycle.
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.
Not see the change on master. Still go with | 1
.
I guess it isn't possible to come up with a scaling factor that lets you still use ROM and not mess with the MPU? Another thought - should this be conditional on being non-secure ( |
On M2351, cache is on for secure land but off for non-secure land. The wait_ns.c file is placed under TARGET_M23_NS directory, which is scanned only in non-secure build. M2351 non-TrustZone code can be seen as secure-only code, so it doesn't need the |
Thanks, missed that this was in |
@kjbracey-arm Any update? |
#10683 is merged so this can go into CI. |
CI started. |
Test run: SUCCESSSummary: 11 of 11 test jobs passed |
This PR should have been targeted for mbed-os-5.14.0 as noted in the comment above. |
Description
At high HCLK rate, M2351 cannot provide zero-wait-state flash performance. Besides, its cache is forcibly turned off for non-secure land for internal reason. To pass
mbed-os-tests-mbed_platform-wait_ns
test, we locatedelay_loop_code
code from flash to SRAM to achieve zero-wait-state performance.Pull request type
Related PR
Dependent on #10683