H7 support

[digitalentity]

• RCC
• IO
• TIMERS
• DMA
• ADC
• EXTI
• SPI
• I2C
• UART
• USB VCP
• USB MSC
• SDIO
• QSPI

[digitalentity]

Initial work - #5827

[anbello]

I tested master on Matek H743 Mini:

• Boot: OK
• Communication with Configurator via USB: OK
• Gyro + Acc (MPU6000): OK
• Baro: OK (after adding 'USE_BARO_DPS310' here)
• Output: KO, motors don't spin with any ESC protocol using HAKRC-35A-BLheli-32 ESC 4in1
• Receiver: KO with IBUS serial RX on UART6

[digitalentity]

That's WAI. TImers and UARTs are not implemented yet 😕

[anbello]

I haven't enough experience to implement this but I can test when needed.

[bkleiner]

I would like to help out.
How would one go about continuing the work here? Pull the code for the missing peripherals from BF and integrate?

[DzikuVx]

@bkleiner yes, that's the way to go ;) The most important next thing for H7 are PWM outputs. If you could pull that topic off it would be awesome!

[bkleiner]

@DzikuVx i have created a draft pull request to track my progress #6905

[DzikuVx]

VCP is not working after a reboot. Seems like USB clock is not initialized correctly

[DzikuVx]

VCP at boot fixed in #6912 thanks a lot @bkleiner

[DzikuVx]

Timers fixed #6905

[chr0mcom]

time estimate for finishing?

[bkleiner]

Right after you covered Pawel's and my (software-developer!) salary so we can dedicate ourselves exclusively to this
(open-source!) project we will be happy to provide you with precise time-estimates, roadmaps and feedback cycles as we would at our current day jobs.

Seeing that that's probably not gonna happen anytime soon and everybody involved is doing this as a hobby, i am afraid nobody will be able to provide you with this information to any degree of certainty.

On a more serious note, mentioned day job got kinda busy for me and i got distracted with an other project. I still fully intend on continuing the work, but it will probably be little while longer until i am able to do so.

[DzikuVx]

savage, but quite accurate @bkleiner ;)

[chr0mcom]

hi bkleiner,
thx for this answer, it might be interesting for people who didnt know this. so, again, thx for that.
but it wasnt an answer of my question. i will try it in german again:
-> gibt es eine zeitabschätzung für die fertigstellung dieses arbeitspaketes?

[avsaase]

Nein ;)

[chr0mcom]

ja, das wäre zum Beispiel eine valide Antwort gewesen

[bkleiner]

Back to more constructive things, uart hopefully fixed in #7039

[DzikuVx]

@bkleiner I'll check as soon as I will be able. Thanks a lot

[bkleiner]

I have unexpectedly found myself with a bit of time on my hands
and managed to take care of some of the bigger things:

uarts #7039
i2c #7040
dma #7042
adc #7043
and i have EXTI in the pipeline.

If all of the above checks out, i think we are down to getting
the last of the devices (OSD, sdcard, msc) running and polishing/fixing whatever else comes up.

[anbello]

I tested latest master on a 3 inch copter with MathekH743 Mini. Board alignment 270 Yaw degrees with Mini.
It seems all OK, for now I see only one problem: with DShot only two motors runs (1 and 3), with Standard and OneShot all four motors runs.
I also did a some little indoor test flight in Angle and AltHold with good results considering that I have default parameter.

[DzikuVx]

@anbello that's actually a very good news. On the DSHOT, seems like a DMA conflict. Let's keep it noted

[bkleiner]

@anbello thanks for boldly going where nobody went before! please keep your fingers safe tho.

i am not sure the dshot thing is a collision, seeing that the chip has a DMAMUX allowing for (almost) arbitrary combinations of streams and peripherals. i am thinking it might be related to the location of the dshot dma buffer in ram, we might have to move it to the faster section, similar to what was required on adc.

[bkleiner]

potential fix landed with #7101 Pawel was pretty much right, the streams collided in a sense.

@anbello another test would be appreciated, just be safe.

[Cal1sto]

Still issue with DSHOT with #7101 an issue one motor ESC 1 (S1) ) that not respond or start on a quad,
I try with the following timer setting (see below) but is not enough the S1 start not everytime, seems the DMAMUX or not enought fast , also similar problem with other setting than DSHOT with different result (some other motor doesn't) start, only with bellow setting only without S5 to S1X (servo set) the oneshot is runing well this reveal that the DMA part has some issue to not be able to send with enought velocity for the 16k demand where oneshot is very slower, have checked with betaflight and it run without issue with Dshot, but i want it with INAV ;-)
DEF_TIM(TIM3, CH3, PB0, TIM_USE_MC_MOTOR | TIM_USE_FW_MOTOR, 0, 1), // S1
DEF_TIM(TIM3, CH4, PB1, TIM_USE_MC_MOTOR | TIM_USE_FW_MOTOR, 0, 2), // S2
DEF_TIM(TIM5, CH1, PA0, TIM_USE_MC_MOTOR | TIM_USE_FW_MOTOR, 0, 3), // S3
DEF_TIM(TIM5, CH2, PA1, TIM_USE_MC_MOTOR | TIM_USE_FW_MOTOR, 0, 4), // S4
Tested on MATEKH743 mini .

[DzikuVx]

You can run it with Multishot, INAV does not care.

[Cal1sto]

For MULTISHOT with refresh rate 8khz and 4khz no motor are react, at 2khz only S2 and S3, only oneshot125 at 1khz possible for now seems higher refresh rate is not supported by the current firmware. I have an 4in1 ESC on bheli32 with DSHOT1200 capability (on last 3.8 version) mean 16khz refresh rate - using 4 motor (S1 to S4)

[DzikuVx]

I have extensively tested Multishot on 2kHz and 8kHz with 1630f1d

Everything looks exactly like it should be.
I will connect to ESC to verify

[DzikuVx]

In a meantime, BLHeli32.8 indeed does not work with with high speed Multishot although PWM traces look completely fine. Will dig deeper.

DSHOT problem identified and pending proper PR

[Cal1sto]

Tested with DSHOT1200 now perform very good on MATEKH743 mini with the fix (Fix DSHOT on H7 by moving to DMA_RAM #7119)

[DzikuVx]

Now, tested Multishot at 4kHz and 8kHz. It does not work on other builds of mine as well. Seems like they do no longer support high frequency Multishot updates. Not H7 related

[johannesdirks]

Hi, sorry for asking... is there already a testing target for Matek H743?

[DzikuVx]

@johannesdirks nothing official. I think it's flyable, but not yet safe to use

[anbello]

Hi, tested master (0d1ecd5) with H743 Mini on my 3 inch Copter.
Little indoor test flight in Angle and AltHold with DSHOT600, all OK.

I only have the Copter slowly but continuously rising in AltHold, it is strange because I have the same behavior with ArduCopter. Anyway this is another kind of problem, if any, respect to the argument of this issue.

[bkleiner]

USB MSC and SDIO were merged in #7572 only leaving QSPI open.
As we don't have any hardware using it (maybe @hydra can help out here?), i'm inclined to call this one done.

[DzikuVx]

Then, closed

[hydra]

@bkleiner IIRC I sent @digitalentity some H7 FC's when they were first released.

My boards are also H750, and the work to support H750 has not been started. Now is a good time for anyone wanting to start that work to do so. For H750 support the list of tasks is primarily as follows:

• Add H750 CPU support to build system.
• Update build system to support generating EXST bootloader binaries
• Update H7 startup code (only minor changes to init code so that reboot reason handing is supported).
• Update MSP to allow rebooting to bootloader.
• External flash partitioning support.
• Add QSPI support for QSPI flash chip.
• Allow saving config to external flash.

[sensei-hacker]

While this is still somewhat fresh in the developers' minds, is there anything in particular that should be included in documentation for this board? I don't see any file for this target in docs/boards/. Does anything come to mind that should be there? (Aside from basic specs from the manufacturer.)

[bkleiner]

The boards themselves a pretty straightforward (well probably with the exception of the SPRacing line, but we don't support them right now). The MCU differs in certain aspects from F4/F7 but thats likely best served with the official ref-mans and datasheets from STM.

[hydra]

I'd just like to remind everyone how awesome the H7 processors are and why they make sense:

• The price of an H750/H730 + external flash is LESS than the price of an H743, by a large margin.
• They support a flexible DMA MUX which allows for much more flexible hardware designs and better software support.
• They're not affected by critical SPI/DMA bugs/errata like the old F4's are, which further limit performance on F4.
• They have more flexible clock selection so we can run the gyros at the right SPI clock speed.
• The clock speed and CPU performance is AMAZING. Night and day difference.
• They have more more CPU coupled RAM, and caches, which further speeds up code and data access.
• They support FMAC and CORDIC math peripherals which should be leveraged to further improve performance.
• They have enough power to do everything without being overloaded.
• There are better inter-peripheral interconnects to allow more to be done in hardware, further reducing the load on the CPU.
• They have enough power to run a CPU controlled Pixel/Canvas OSD solution (such as the SPRacingPixelOSD system) the overall board space is smaller than an CPU + Max7456 and the cost is lower, for more features!
• They are much more future-proof, both in terms of code-space and cpu cycles.
• They are much more friendly to develop code with, especially for proof-of-concept code where cpu performance isn't optimized.
• They have other updated and improved peripherals, such as serial ports that support inversion.

F4 is very very old, F3 is newer, F7 is like a fixed F4 with caches, H7 is just better all round.

[happy12]

Just found this (github thread) after installing Matek H743 into my plane and the SD card makes it freeze... sad panda

[MrD-RC]

@happy12 This is the issue you want to check out #7759

[packetkiller]

Lumenier LUX H7 HD with Lumenier Eliete 60A Pro ESC. Works and flies great with iNAV 4.1.0. Alt-hold, poshold, missions, horz, angle, and acro all working fine.
Blackbox logs to SD card fine.
SD Card read from USB not working from iNAV 4.1.0 Configurator (have to pop the top every time to get data direct from SD).
Same issue during iNAV 3.0.2 days, and it got fixed during a nightly build. Fix got lost during revamp to iNAV 4.
Where would be most helpful in tracking this down? Too much change from 3.x to 4.x to port the old code? Happy to lend a hand if you guys point me in the general direction.