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

Add support for STM32G4 family #287

Merged
merged 7 commits into from
Oct 9, 2019
Merged

Conversation

rleh
Copy link
Member

@rleh rleh commented Sep 10, 2019

  • Blink example compiles! 😉
  • Adapt peripherals
    • ADC
    • DAC There is generally no DAC driver yet.
    • Comparator
    • New FDCAN driver -> different PR
  • Add Nucleo-G474RE BSP and examples
  • Test on real hardware

@rleh
Copy link
Member Author

rleh commented Sep 10, 2019

There are a lot of this redefined errors:

modm/src/modm/platform/uart/uart_base.hpp:25: warning: "USART_ISR_RXNE" redefined
   25 | #define USART_ISR_RXNE    USART_ISR_RXNE_RXFNE
      | 
In file included from modm/src/modm/platform/clock/../device.hpp:25,
[...]
modm/ext/cmsis/device/stm32g474xx.h:15998: note: this is the location of the previous definition
15998 | #define USART_ISR_RXNE               USART_ISR_RXNE_Msk                        /*!< Read Data Register Not Empty */

Another ST inconsistency?

ext/st/device.hpp.in Outdated Show resolved Hide resolved
@salkinium
Copy link
Member

salkinium commented Sep 10, 2019

Please update the STM32 CMSIS Header submodule to the latest commit, so that you're not working with bugs that have already been fixed!

@salkinium
Copy link
Member

ST already fixed their own header files:

#define USART_CR1_TXEIE_Pos          (7U)
#define USART_CR1_TXEIE_Msk          (0x1UL << USART_CR1_TXEIE_Pos)            /*!< 0x00000080 */
#define USART_CR1_TXEIE              USART_CR1_TXEIE_Msk                       /*!< TXE Interrupt Enable */
#define USART_CR1_TXEIE_TXFNFIE_Pos  USART_CR1_TXEIE_Pos
#define USART_CR1_TXEIE_TXFNFIE_Msk  USART_CR1_TXEIE_Msk                       /*!< 0x00000080 */
#define USART_CR1_TXEIE_TXFNFIE      USART_CR1_TXEIE_Msk                       /*!< TXE and TX FIFO Not Full Interrupt Enable */

and

#define USART_ISR_TXE_Pos            (7U)
#define USART_ISR_TXE_Msk            (0x1UL << USART_ISR_TXE_Pos)              /*!< 0x00000080 */
#define USART_ISR_TXE                USART_ISR_TXE_Msk                         /*!< Transmit Data Register Empty */
#define USART_ISR_TXE_TXFNF_Pos      USART_ISR_TXE_Pos
#define USART_ISR_TXE_TXFNF_Msk      USART_ISR_TXE_Msk                       /*!< 0x00000080 */
#define USART_ISR_TXE_TXFNF          USART_ISR_TXE_Msk                       /*!< Transmit Data Register Empty or TX FIFO Not Full Flag */

So the lines in uart_base.hpp requires a few #ifndef.

@salkinium
Copy link
Member

@rleh rleh marked this pull request as ready for review September 12, 2019 15:20
@rleh rleh requested a review from salkinium September 12, 2019 15:20
@rleh rleh mentioned this pull request Sep 13, 2019
@rleh rleh force-pushed the feature/stm32g4 branch from 3ab80d9 to 969be6b Compare October 5, 2019 11:43
@rleh rleh force-pushed the feature/stm32g4 branch 3 times, most recently from b9ac44c to fb52706 Compare October 6, 2019 10:13
@rleh
Copy link
Member Author

rleh commented Oct 6, 2019

The build-docs CI job fails:

...
Merging module tree...
/bin/bash: line 1:   405 Killed                  python3 tools/scripts/generate_module_docs.py
Exited with code 137

Hint: Exit code 137 typically means the process is killed because it was running out of memory
Hint: Check if you can optimize the memory usage in your app
Hint: Max memory usage of this container is 4283166720
 according to /sys/fs/cgroup/memory/memory.max_usage_in_bytes

@salkinium
Copy link
Member

Try this patch, it should only use 1.5GB of memory by merging the module tree immediately instead of storing all trees and then merging (which was stupid).
https://gist.github.com/salkinium/4cd2509cb2bf8d28ac2c022320fa11f5

@rleh
Copy link
Member Author

rleh commented Oct 8, 2019

There is a issue with OpenOCD: The latest OpenOCD Version (0.10.0 from January 2017) neither supports the STM32G4 as a target, nor the ST-Link V3 on the Nucleo-G474RE board.

There is probably no way out to use a newer OpenOCD version than 0.10.0. So compile OpenOCD yourself or use the AUR version (Git HEAD) for Arch-Linux.

To fix the missing STM32G4 support I will try to add the necessary files in tools/openocd/modm/.

StLink-V3 support: http://openocd.zylin.com/#/c/4717/
STM32G4 support: http://openocd.zylin.com/#/c/4807/

@salkinium
Copy link
Member

OpenOCD also has no STM32G0 support either, I've been using the ST-Link mass storage device to flash it, but debugging would be useful too. OpenOCD has a very slow PR process, as in like multiple years.

Copy link
Member

@salkinium salkinium left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested in hardware?

src/modm/platform/comp/stm32/base.hpp.in Outdated Show resolved Hide resolved
src/modm/platform/comp/stm32/module.lb Show resolved Hide resolved
ext/st/device.hpp.in Outdated Show resolved Hide resolved
@rleh rleh force-pushed the feature/stm32g4 branch from 235a5c3 to 74b198f Compare October 9, 2019 00:32
@rleh
Copy link
Member Author

rleh commented Oct 9, 2019

Test on real hardware: ✅

Merge?

@salkinium
Copy link
Member

Can you add the family to the README, and check if there're any other docs that need updating?

@salkinium
Copy link
Member

Is the linkerscript chosen correctly?

@rleh
Copy link
Member Author

rleh commented Oct 9, 2019

Is the linkerscript chosen correctly?

The ICCM Linkerscript is chosen, looks right to me.
STM32G474 Memory

@rleh rleh force-pushed the feature/stm32g4 branch from 74b198f to 78da525 Compare October 9, 2019 01:34
@rleh
Copy link
Member Author

rleh commented Oct 9, 2019

Can you add the family to the README, and check if there're any other docs that need updating?

README done.
I cannot find any other documents that need to be updated.

Copy link
Member

@salkinium salkinium left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fantastic!

@rleh
Copy link
Member Author

rleh commented Oct 9, 2019

I wrote a small blog-post about how to compile OpenOCD with support for STM32G0 and STM32G4:
https://rleh.de/2019/10/08/openocd-stm32-stm32g4-stm32g0.html

@salkinium salkinium merged commit 78da525 into modm-io:develop Oct 9, 2019
@rleh rleh deleted the feature/stm32g4 branch October 9, 2019 15:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

2 participants