Re: Addition of STM32H7 MCU's
Hi Kian, All the steps are documented here: https://nuttx.apache.org/docs/12.3.0/contributing/index.html If you face some issue, please let me know. BR, Alan On Thu, Jan 18, 2024 at 10:14 AM Kian Karas (KK) wrote: > 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 > Sent: 18 January 2024 03:30 > To: 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 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 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 > 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 > 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 > > > 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 > > > > 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" > > > > > > > *Кому:* "undefined" > > > > > > > *Отправлено:* пятница, 8 сентября 2023 г., 12:52 > > > > > > > *Тема:* Re: Addition
Re: Addition of STM32H7 MCU's
Yes, this commit https://github.com/apache/nuttx/commit/8ceff0d BR, Alan On Wed, Jan 17, 2024 at 11:31 PM Robert Turner 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 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 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 > 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 > 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 > > > 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 > > > > 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" > > > > > > > *Кому:* "undefined" > > > > > > > *Отправлено:* пятница, 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,
Re: Addition of STM32H7 MCU's
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 Sent: 18 January 2024 03:30 To: 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 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 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 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 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 > > 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 > > > 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" > > > > > > *Кому:* "undefined" > > > > > > *Отправлено:* пятница, 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 > >
