Hi Robert, Community We have NuttX running on an STM32H723VE, but haven't tested all peripherals. We also did some initial work on an STM32H730, but this has hardly been tested.
What is the best way to share the STM32H723VE support with the community? It needs some reviewing. I am concerned we could have broken stuff for other MCUs in the familly, but I can't test this. @Robert: if you are in a hurry, send me an email directly and I'll respond with a patch. Regards Kian ________________________________ From: Robert Turner <rob...@gmail.com> Sent: 18 January 2024 03:30 To: dev@nuttx.apache.org <dev@nuttx.apache.org> Subject: Re: Addition of STM32H7 MCU's Nah not internal cache. The SRAM sizes for H723/5 are different from any of those defined in arch/arm/include/stm32h7/chip.h Suspect we need to get these correct as other files use these defs also, such as stm32_allocateheap.c Is Jorge's PR the one merged on Jul 12 (8ceff0d)? Thanks, Robert On Thu, Jan 18, 2024 at 2:56 PM Alan C. Assis <acas...@gmail.com> wrote: > Hi Robert, > Thank you for the explanation! Is it about internal cache? > > Looking at > https://www.st.com/en/microcontrollers-microprocessors/stm32h7-series.html > I can see that H723/5 shares mostly everything with H333/5. > I only tested NuttX on STM32H743ZI and STM32H753BI (I and Jorge added > support to this few weeks ago). > > Please take a look at Jorge's PRs, probably if you fix the memory in the > linker script and the clock tree for your board NuttX will work fine on it. > > BR, > > Alan > > On Wed, Jan 17, 2024 at 10:25 PM Robert Turner <rob...@gmail.com> wrote: > > > Apologies, I should have been more specific, I was referring to parts in > > the family which are not currently covered, such as the STM32H723xx which > > we use. The RAM sizes definitions in chip.h for > > CONFIG_STM32H7_STM32H7X3XX/CONFIG_STM32H7_STM32H7X5XX are incorrect for > > the STM32H723xx and STM32H725xx. > > BR, > > Robert > > > > On Thu, Jan 18, 2024 at 1:28 PM Alan C. Assis <acas...@gmail.com> wrote: > > > > > Robert, > > > STM32H7 family is already supported. > > > > > > Look at arch/arm/src/stm32h7 and equivalent at boards/ > > > > > > BR, > > > > > > Alan > > > > > > On Tuesday, January 16, 2024, Robert Turner <rob...@gmail.com> wrote: > > > > > > > Did anyone finish supporting the broader STM32H7xx family? If so, is > it > > > > close to being mergeable or sendable as a patch? > > > > > > > > Thanks, > > > > Robert > > > > > > > > On Fri, Sep 8, 2023 at 10:33 PM raiden00pl <raiden0...@gmail.com> > > wrote: > > > > > > > > > > You're right, but not entirely) For example, chips of different > > > > subseries > > > > > have different interrupt vector tables. Those. The > stm32h7x3xx_irq.h > > > file > > > > > lists interrupt vectors for the RM0433, but not for the RM0455 or > > > > > RM0468. Although > > > > > some chips from all these series have 7x3 in the name. > > > > > > > > > > I think they are the same (not checked, intuition tells me so). But > > > some > > > > > peripherals are not available on some chips and then the > > > > > corresponding interrupt line is marked RESERVED, or its the same > > > > peripheral > > > > > but with upgraded functionality (QSPI/OCTOSPI) or > > > > > for some reason ST changed its name to confuse devs. There should > be > > no > > > > > conflict between IRQ lines. > > > > > > > > > > > Even if it duplicates 90% of the file it is better than #ifdefing > > the > > > > > > stm32h7x3xx_irq.h file. AKA ifdef rash! > > > > > > > > > > One file approach can be done with only one level of #ifdefs, one > > level > > > > of > > > > > #ifdefs doesn't have a negative impact on code quality (but > > > > > it's probably a matter of individual feelings). > > > > > For IRQ and memory map (and probably DMAMUX), the approach with > > > separate > > > > > files may make sense but for peripheral definitions > > > > > I don't see any benefit in duplicating files. > > > > > > > > > > pt., 8 wrz 2023 o 12:01 <o.svezhins...@indrones.ru.invalid> > > > napisał(a): > > > > > > > > > > > You're right, but not entirely) For example, chips of different > > > > subseries > > > > > > have different interrupt vector tables. Those. The > > stm32h7x3xx_irq.h > > > > file > > > > > > lists interrupt vectors for the RM0433, but not for the RM0455 or > > > > > RM0468. Although > > > > > > some chips from all these series have 7x3 in the name. > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------ > > > > > > *От:* "raiden00pl" <raiden0...@gmail.com> > > > > > > *Кому:* "undefined" <dev@nuttx.apache.org> > > > > > > *Отправлено:* пятница, 8 сентября 2023 г., 12:52 > > > > > > *Тема:* Re: Addition of STM32H7 MCU's > > > > > > > > > > > > From what I'm familiar with STM32H7, all chips use the same > > registers > > > > and > > > > > > bit definitions. > > > > > > Therefore, keeping definitions for different chips in different > > files > > > > > > doesn't make sense in my opinion. > > > > > > The only problem is that some chips support some peripherals > while > > > > others > > > > > > do not. But this can be > > > > > > solved using definitions from Kconfig, where we define the > > supported > > > > > > peripherals anyway, using > > > > > > `select STM32H7_HAVE_xxx`. In that case, it's possible to have > only > > > one > > > > > > version of files with hardware > > > > > > definitions (irq, peripherals) and guard the optional > > functionalities > > > > > with > > > > > > `#ifdef CONFIG_STM32H7_HAVE_xxx`. > > > > > > Moreover, I think this can be done for all stm32 families, but > > it's a > > > > lot > > > > > > of work that no one has undertaken > > > > > > so far (I tried, but failed ;) ) > > > > > > > > > > > > I understand that code duplication is often not bad, but in the > > case > > > of > > > > > > stm32 it is a bit too high. It's partly ST's fault > > > > > > because of how they release their manuals. The user must spend a > > lot > > > of > > > > > > time to come to the conclusion > > > > > > that the only thing that changes in the other version of the chip > > is > > > > the > > > > > > chip code number in the reference manual :) > > > > > > > > > > > > > > > > > > pt., 8 wrz 2023 o 11:11 napisał(a): > > > > > > > > > > > > > Hi, all > > > > > > > > > > > > > > I would like to start working on developing support for > STM32H735 > > > > > > > microcontrollers in NuttX OS, but I found some strange things > in > > > the > > > > > > > principle of configuring this series of microcontrollers. > > > > > > > > > > > > > > Microcontrollers of the H7 series are divided into several > > > subseries, > > > > > > each > > > > > > > united by one reference manual: > > > > > > > - STM32H723/733, STM32H725/735 and STM32H730 (RM0468) > > > > > > > - STM32H745/755 and STM32H747/757 (RM0399) > > > > > > > - STM32H742, STM32H743/753 and STM32H750 (RM0433) > > > > > > > - STM32H7A3/7B3 and STM32H7B0 (RM0455) > > > > > > > > > > > > > > But some header files in arch/arm/include/stm32h7 are > designated > > as > > > > > > > stm32h7x3xx_irq.h or stm32h7x5xx_irq.h, although they are only > > for > > > > the > > > > > > H743 > > > > > > > or H745 series respectively, not for H723 or H735. And such a > > > > > > discrepancy > > > > > > > is also present in other source code files that belong to the > H7 > > > > > series. > > > > > > > > > > > > > > Maybe it's worth fixing this somehow? Will this break anything > > > > > > important? > > > > > > > > > > > > > > > > > > > > > Oleg Svezhinskiy > > > > > > > > > > > > > > > > > > > > > > > > > > > >
