STM32G4: add support for G4 series, and LPUART #6911

H-Grobben · 2021-02-16T08:53:03Z

#6808 was closed due to a rename in out git repo, so I'm opening a new pull request on the new branch.
#5396: thanks for the pointer, I have tested it with the Nucleo G4 board.

dpgeorge · 2021-02-16T14:09:12Z

I now have some STM32G4 hardware so can test this.

H-Grobben · 2021-02-16T16:01:09Z

Ah, great, I have the Nucleo board that's included in the boards folder (G474RE), and tested it quite well. The only thing I missed was LPUART support (now included in this version, but I don't have other Nucleo boards to test if they all work).

Sorry for still adding stuff, I seem to have some troubles with the ci scripts (I suddely have/had a pull_request branch?). I fixed the pyb issue, but due to STM32lib switched to vendor (I integrated it into vendor, as it is based on the vendor version) the build now fails on some unfixed bugs in the vendor tree.

I also tried to build for the G431 board, but the Flash space was not sufficient. So I didn't include the files for that board.

H-Grobben · 2021-02-16T16:10:54Z

If you need some help with integrating into the right branches etc, please leave a note and I will try to help.

dpgeorge · 2021-02-23T00:34:02Z

The stm32lib repository has now been updated to include the G4 HAL, on the branch: work-F0-1.9.0+F4-1.16.0+F7-1.7.0+G4-1.3.0+H7-1.6.0+L0-1.11.2+L4-1.8.1+WB-1.10.0

chrismas9

ports/stm32/boards/stm32g474.ld

I think the fs cache is overlapping the heap and file writes will crash the middle of the heap (if used). CCMRAM at 0x10000000 is also mapped after SRAM1 and SRAM2 and is the last part of the continuous 128KB at 0x20000000. There is only 128KB ram total comprising SRAM1 (80KB), SRAM2 (16KB) and CCMRAM (32KB).

The best layout for devices with continuous RAM is to not define RAM at 0x10000000 and just use one block at 0x20000000. Have a look at the STM32L496 linker script. Layout would be 4k fs_cache at top, then stack, then heap.

Also for devices with uniform flash sector size there is no need for FLASH_ISR. It's only needed for the F4 & F7 series to take advantage of the small sectors at the start of flash. Again look at the L496 for simpler config with FLASH first, then FLASH_FS.

H-Grobben · 2021-03-03T08:17:36Z

Sorry for the delay, had some other priorities, I'll pick it up today. I've changed the setup for the G4 as @chrismas9 suggested, and the build still work on the Nucleo board. Now running the ci tests to see if it all builds.

H-Grobben · 2021-03-05T09:13:46Z

I've updated with the comments or @chrismas9 and did some more testing (I2C, SPI, UART, Switch, LED, Timer). Found a bug in my code for timer1 callback, but also for general callback (also tested on WB series). You can't register a callback when the timer is running. Stopping before starting the timer in the callback registering function fixes this.

I do get errors when using the deploy-stlink after building. But that seems to be an issue with st-flash. If I execute a mass-erase with st-flash, the deploy is working, but that also means custom py scripts are erased.

Normally, I think, using the reset and user button, in mode 3, the filesystem is renewed but somehow it doesn't (also not on my other project with STM32WB). But it does create a fresh FS after a full erase of the processors. Will try to test the PR #6904 to verify if this fixes the problem.

H-Grobben · 2021-03-29T07:17:19Z

Please put this temporarily on hold, a new board with USB connection does not yet function with this port. Need to add USB support correctly.

codecov-commenter · 2021-09-24T09:47:15Z

Codecov Report

Merging #6911 (87465c4) into master (d42cba0) will decrease coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #6911      +/-   ##
==========================================
- Coverage   98.25%   98.24%   -0.01%     
==========================================
  Files         154      154              
  Lines       20009    20009              
==========================================
- Hits        19659    19657       -2     
- Misses        350      352       +2

Impacted Files	Coverage Δ
py/obj.c	`97.22% <0.00%> (-0.40%)`	⬇️
py/parse.c	`99.00% <0.00%> (-0.20%)`	⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d42cba0...87465c4. Read the comment docs.

H-Grobben · 2021-09-27T09:50:27Z

After a 'short' delay because of other priorities, we managed to get the USB mounting working on our own dev-board. This is now incorporated in the pull request. What we fixed in the last stages:

USB block device mounting: now capable of mounting via USB
FDCAN bug fixes: interrupts not working correctly, now OK
Timer fixes: saw strange behavior after initialization of timers. Assign {0} to structs for correct initialization

H-Grobben · 2021-09-28T08:23:58Z

To my opinion all functionality is implemented. We've tested the G4 functionality on some of our own boards, and we fixed some issues. Next to our own boards, we also added the Nucleo G474 board for everyone to use.

What can I do to help with this merge?

H-Grobben · 2021-12-02T14:14:07Z

Also tested with #8057 on Nucleo_G474 and own custom board with CAN connectivity.

H-Grobben · 2021-12-02T14:29:55Z

@dpgeorge / @chrismas9 I would like to get all ci checks in the green, but I don't think I could easily fix old commit messages to get them into the style of the Code Conventions (sorry my mistake...). If there is an easy way to fix them, could you point me in the right direction?

robert-hh · 2021-12-02T15:20:19Z

Using git rebase -i <before_first_commit_to_change_hash> you can edit and change old commits. Changing the title is the easiest part, done with the reword action. Check the git documentation for usage and examples.

H-Grobben · 2021-12-03T10:01:39Z

Using git rebase -i <before_first_commit_to_change_hash> you can edit and change old commits. Changing the title is the easiest part, done with the reword action. Check the git documentation for usage and examples.

I have looked into this, but that doesn't seem like the proper fix: I need to reword some commits from last year, and I just merged the master. If I reword my commits, I also (can) change the commits from the master (all hash-es change from the starting point, and I can change any commit message). And that is not what I want to. And I don't think the developers behind Micropython would like me to do this...

Another way is to rebase the whole G4 change into the current master, but that is a lot of additional work, checks and tests, I don't think I can persuade my boss to let me do this for some commit-message fixes.

dpgeorge · 2021-12-15T02:00:47Z

Can you please rebase this on latest master? The new stm32lib was merged with G4 HAL support.

H-Grobben · 2022-01-26T15:56:13Z

Can you please rebase this on latest master? The new stm32lib was merged with G4 HAL support.

Rebased and reword applied. Tests currently running on Nucleo G474.

H-Grobben · 2022-01-26T16:01:16Z

Code formatting seems to have failed on an extra in ports/stm32/make-stmconst.py
Quite strange, as the local ci_code_formatting_run has added the extra newline. See last commit.

.gitmodules

ports/stm32/Makefile

ports/stm32/boards/NUCLEO_G474RE/board_init.c

ports/stm32/boards/NUCLEO_G474RE/mpconfigboard.mk

ports/stm32/boards/NUCLEO_G474RE/stm32g4xx_hal_conf.h

ports/stm32/boards/stm32g4xx_hal_conf_base.h

ports/stm32/dma.c

ports/stm32/pin_defs_stm32.h

dpgeorge · 2022-01-27T12:35:06Z

Thanks @H-Grobben for the effort on this, there is a lot of work here.

I left some comments which are hopefully not too much work to respond to. If your time is short I can work them in during merge. Just let me know.

H-Grobben · 2022-01-28T14:00:16Z

Testing done. Still have issues with the ci_code_formatting_run on the ports/stm32/make-stmconst.py file. When running locally, some py files get extra newlines. But they are rejected by the github ci process.

H-Grobben · 2022-01-28T16:26:11Z

Tests showed that the RNG did not produce fully random numbers. This was caused by a clock issue on the RNG peripheral. Now the HSI48 is enabled and selected for RNG (and for future PR also for USB).

dpgeorge · 2022-01-31T07:29:51Z

Thanks for responding to the review comments. It looks like the CI failures are now gone, which is good!

There are many commits in this PR and I will squash them all down into one during merge.

dpgeorge · 2022-02-01T05:27:47Z

Squashed and merged in 8f68e26 with the following minor changes (that did not change the compiled firmware image):

removed README.md because the LPUART now works as REPL
moved defined(STM32G4)'s to sorted order with respect to MCU series (eg F4, G4, H7, L0)
fixed second heading row in new af.csv file
factored new code in make-pins.py
removed unnecessary changes to pyb_can.c
split change to .gitmodules to a separate commit

Thanks for the effort on this!

dpgeorge · 2022-02-01T05:29:08Z

ports/stm32/mpconfigboard_common.h

+#define PYB_EXTI_NUM_VECTORS (42) // up to 42 event/interrupt requests: 28 configurable lines, 14 direct lines
+#define MICROPY_HW_MAX_I2C (3)
+#define MICROPY_HW_MAX_TIMER (20) // TIM 1-8, 20
+#define MICROPY_HW_MAX_UART (5) // uart 1 - 5 + lpuart1


@H-Grobben I'm wondering if this should be 4, not 5. LPUART1 is excluded from this count, I think. Eg there is the following:

struct _pyb_uart_obj_t *pyb_uart_obj_all[MICROPY_HW_MAX_UART + MICROPY_HW_MAX_LPUART];

@dpgeorge It depends on the specific type. There are types with 3 USARTS (and LPUART) only, and the added Nucleo type (G474Rx) has 3 USARTS and 2 UARTS (and LPUART). I was in doubt on the number I should include here, but my decision was the number of peripherals in the Nucleo board, so that's why it was 5.

Check https://www.st.com/resource/en/datasheet/stm32g474re.pdf , page 15, Table 2.

Ah, I see, thanks! So it is correct as is, it should be 5 because that is the maximum possible on the G4 series.

…-message touch up analogbufio ValueError msg

dpgeorge added the port-stm32 label Feb 16, 2021

H-Grobben mentioned this pull request Feb 16, 2021

stm32/uart: Add support for LPUART1 on L0, L4, H7 and WB MCUs. #5396

Closed

dpgeorge mentioned this pull request Feb 23, 2021

Added new family to stml32 platform: stm32f3xx devices micropython/stm32lib#14

Closed

chrismas9 reviewed Feb 25, 2021

View reviewed changes

H-Grobben mentioned this pull request Dec 1, 2021

STM32: FDCAN fix for FIFO1 usage and handling of Error interrupts. #8057

Closed

H-Grobben force-pushed the STM32G4 branch 2 times, most recently from 214093d to c650676 Compare January 26, 2022 15:47

dpgeorge requested changes Jan 27, 2022

View reviewed changes

H-Grobben added 4 commits January 28, 2022 13:49

STM32G4: Updates for STM32G4 series.

5303a01

STM32G4: Add readme for connecting REPL uart.

dd17e8d

STM32G4: Add G4 family.

b947541

STM32G4: Building succeded, now test if it still all works.

1136724

H-Grobben added 17 commits January 28, 2022 13:49

STM32G4: Set compiler opt to build succesfully.

3b71858

STM32G4: Transfer to AEMICS repo.

cad1662

STM: Add set_baudrate for lpuart.

b8b740a

STM32 F4 / F7: Don't have LPUART, remove include after pyb test.

fca27a5

STM32G4: Changed loader script for g474.

1386df8

STM32G4: Changed loader script for g474.

fa9f5e1

STM: Timer callback fails. Add stop before start to fix.

86a5831

STM32G4: Fix Timer1 callback issue.

6d068a7

STM32G4: Extint vector mapping fix.

894e49a

STM32: Fix merge issue.

5060481

STM32G4: Fix for HSE enabled devices, use HSE as clock source.

02f9bcf

STM32G4: Last walktrough, update with last status of master.

27d4a37

STM32G4: Code formating fix.

20755f4

STM32G4: Rebased to 30b6ce8 with final test and fixes.

368a1ac

STM32G4: CI check code formatting, and removed comment from board file.

fa52bd8

STM32G4: Implemented review comments.

a542b04

STM32G4: Rebase to last head.

cbfd14a

H-Grobben force-pushed the STM32G4 branch from d49ffb5 to cbfd14a Compare January 28, 2022 13:51

STM32G4: RNG did not produce random nr due to clock issue.

f2f5b41

H-Grobben requested a review from dpgeorge January 31, 2022 07:27

dpgeorge approved these changes Feb 1, 2022

View reviewed changes

dpgeorge closed this Feb 1, 2022

dpgeorge reviewed Feb 1, 2022

View reviewed changes

Wind-stormger pushed a commit to BPI-STEAM/micropython that referenced this pull request Oct 13, 2022

Merge pull request micropython#6911 from dhalbert/fix-analogbufio-err…

3d96703

…-message touch up analogbufio ValueError msg

jimmo mentioned this pull request May 19, 2023

stm32/usb: Fix USB support on STM32G4. #11556

Merged

Uh oh!

STM32G4: add support for G4 series, and LPUART #6911

STM32G4: add support for G4 series, and LPUART #6911

Uh oh!

Conversation

H-Grobben commented Feb 16, 2021

Uh oh!

dpgeorge commented Feb 16, 2021

Uh oh!

H-Grobben commented Feb 16, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

H-Grobben commented Feb 16, 2021

Uh oh!

dpgeorge commented Feb 23, 2021

Uh oh!

chrismas9 left a comment

Choose a reason for hiding this comment

Uh oh!

H-Grobben commented Mar 3, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

H-Grobben commented Mar 5, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

H-Grobben commented Mar 29, 2021

Uh oh!

codecov-commenter commented Sep 24, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

H-Grobben commented Sep 27, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

H-Grobben commented Sep 28, 2021

Uh oh!

H-Grobben commented Dec 2, 2021

Uh oh!

H-Grobben commented Dec 2, 2021

Uh oh!

robert-hh commented Dec 2, 2021

Uh oh!

H-Grobben commented Dec 3, 2021

Uh oh!

dpgeorge commented Dec 15, 2021

Uh oh!

H-Grobben commented Jan 26, 2022

Uh oh!

H-Grobben commented Jan 26, 2022

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

dpgeorge commented Jan 27, 2022

Uh oh!

H-Grobben commented Jan 28, 2022

Uh oh!

H-Grobben commented Jan 28, 2022

Uh oh!

dpgeorge commented Jan 31, 2022

Uh oh!

dpgeorge commented Feb 1, 2022

Uh oh!

dpgeorge Feb 1, 2022

Choose a reason for hiding this comment

Uh oh!

H-Grobben Feb 1, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dpgeorge Feb 1, 2022

Choose a reason for hiding this comment

Uh oh!

H-Grobben commented Feb 16, 2021 •

edited

Loading

H-Grobben commented Mar 3, 2021 •

edited

Loading

H-Grobben commented Mar 5, 2021 •

edited

Loading

codecov-commenter commented Sep 24, 2021 •

edited

Loading

H-Grobben commented Sep 27, 2021 •

edited

Loading

H-Grobben Feb 1, 2022 •

edited

Loading