Skip to content
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

Fix declaring OSPIFBlockDevice and QSPIFBlockDevice as globals, fix some STM32U585 issues #167

Merged
merged 6 commits into from Jul 18, 2023

Conversation

multiplemonomials
Copy link
Collaborator

@multiplemonomials multiplemonomials commented Jul 6, 2023

Summary of changes

@tim35ca on the forums pointed out that declaring an OSPIFBlockDevice as a global object can cause it to not work correctly. This is because the author of OSPIFBlockDevice made a common mistake: interacting with global variables in an object constructor, without realizing that those global variables might not yet have been initialized. The C++ environment is free to initialize globals in any order it wants, so depending on your luck for the day and the direction of the wind, the globals in OSPIFBlockDevice.cpp may or may not have been initialized by the time your globally declared block device instance gets constructed.

If they aren't, you will likely get a HardFault due to accessing a null _active_ospif_flash_csel_arr pointer.

In this PR, I changed the code around a bit so that the global variables (the mutex and the csel array) are now stored as local static variables in functions. This gives them a well-defined init order -- they will always be initialized the first time the function is called. I also cleaned up the code a bit (hello ScopedMutexLock, goodbye goto) and fixed an issue where OSPIFBlockDevice wasn't available on my test target due to an error in targets.json.

Also applied fixes for some other issues that @TIM35 was running into with the U585 board, including:

  • mbed-wifi not compiling
  • No upload method configuration for B_U585I_IOT02A
  • B_U585I_IOT02A missing OSPIF component due to a typo in targets.json

Update: Since QSPIFBlockDevice was found to have the same problem, I also applied this fix there.

Impact of changes

OSPIFBlockDevice should no longer hardfault when declared globally.

Migration actions required

None

Documentation

None


Pull request type

[X] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers


JohnK1987
JohnK1987 previously approved these changes Jul 6, 2023
@multiplemonomials multiplemonomials changed the title Attempt to fix declaring an OSPIFBlockDevice as a global object Attempt to fix declaring OSPIFBlockDevice and QSPIFBlockDevice as globals Jul 12, 2023
JohnK1987
JohnK1987 previously approved these changes Jul 12, 2023
@multiplemonomials multiplemonomials changed the title Attempt to fix declaring OSPIFBlockDevice and QSPIFBlockDevice as globals Fix declaring OSPIFBlockDevice and QSPIFBlockDevice as globals, fix some STM32U585 issues Jul 18, 2023
@multiplemonomials multiplemonomials merged commit a639176 into master Jul 18, 2023
9 checks passed
@multiplemonomials multiplemonomials deleted the bugfix/fix-declaring-ospif-globally branch July 18, 2023 02:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants