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

stm32lib/CMSIS/STM32F4xx/Include/stm32f413xx.h: Add RCC_CSR_BORRSTF #4

Closed
wants to merge 1 commit into from

Conversation

chrismas9
Copy link

RCC_CSR_BORRSTF is defined in the STM32F413 Reference Manual but missing from the header file.

RCC_CSR_BORRSTF is defined in the STM32F413 Reference Manual but missing from the header file.
@dpgeorge
Copy link
Member

Thanks it looks good. It could be that a newer version of the Cube HAL includes this, but adding it this way is a lot easier than updating the HAL, and doesn't prevent updating it later.

@chrismas9
Copy link
Author

I think I used the wrong branch. Should this go to work-F0-1.9.0+F4-1.16.0+F7-1.7.0+H7-1.2.0+L4-1.8.1, not Vendor? Not sure how to fix it.

@chrismas9 chrismas9 changed the base branch from vendor to work-F0-1.9.0+F4-1.16.0+F7-1.7.0+H7-1.2.0+L4-1.8.1 December 29, 2018 06:16
@dpgeorge
Copy link
Member

It should go to the latest work branch. Vendor is used only for pulling in upstream from ST.

@dpgeorge
Copy link
Member

Merged in ed05625

@dpgeorge dpgeorge closed this Dec 29, 2018
@dpgeorge
Copy link
Member

@chrismas9 note that this won't be reflected in the MicroPython repository until the submodule is updated there, which can be done once the F413 is shown to be working.

@chrismas9
Copy link
Author

@dpgeorge, the F413 port is complete and working, however I won't release it until I finish testing.
RCC_CSR_BORRSTF is only used to define RCC_SR_BORRSTF which is never used for the F4 (only F0).
This patch allows upy to compile, but will never be functionally tested.

I have found a BOR issue. Whilst testing the hardware and from subsequent code review it appears BOR (brown out reset) is not enabled and the STM32 is only reset when the supply drops below 1.7V. This could lead to unreliable operation from 1.7 to 2.7V because the Flash latency values used are only valid above 2.7V. I will raise a separate issue to discuss this.

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.

2 participants