Skip to content

Fix wait_ns is unstable with flash performance #10632

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.

Sign up for GitHub

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

Closed
wants to merge 1 commit into from
Closed

Fix wait_ns is unstable with flash performance #10632

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 9 additions & 1 deletion platform/mbed_wait_api_no_rtos.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -99,9 +99,13 @@ void wait_us(int us)
* functions well. So sidestep that by hand-assembling the code. Also avoids
* the hassle of handling multiple toolchains with different assembler
* syntax.
*
* Not all chips' flash are non-zero wait state. These chips usually have cache to
* improve performance. To avoid non-zero wait state and non-constant instruction
* cycles, this thumb code is located on SRAM instead of on flash.
*/
MBED_ALIGN(8)
static const uint16_t delay_loop_code[] = {
static uint16_t delay_loop_code[] = {
0x1E40, // SUBS R0,R0,#1
0xBF00, // NOP
0xBF00, // NOP
Expand All @@ -120,6 +124,10 @@ void wait_ns(unsigned int ns)
// worth at least one loop iteration.
uint32_t count = (cycles_per_us * ns) / LOOP_SCALER;

mbed_mpu_manager_lock_ram_execution();

delay_loop(count);

mbed_mpu_manager_unlock_ram_execution();
}
#endif // LOOP_SCALER