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
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Reply via email to