Yes, this commit https://github.com/apache/nuttx/commit/8ceff0d
BR, Alan On Wed, Jan 17, 2024 at 11:31 PM Robert Turner <rob...@gmail.com> wrote: > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
