SPRACINGH7RF Failure to boot caused by re-use of SPI pins. #11157
Comments
|
@hydra: This issue is being automatically closed because it does not follow the template. When you open an issue or feature request you are presented with a template. Follow the guidelines. You can edit your message to fix this and the issue will be automatically reopened. |
|
This sequence also results in the same issue: FC reboots, enter CLI:
^ incorrect, should be as follows: |
|
On further investigation it seems this issue occurs because the target also uses the same initialisation sequence that When using (
In the case of the H7RF, SPI isn't used to load the config, OctoSPI is, so changing the SPI pins should be allowed. When work more on #11110 I'll investigate this further. |
|
This can be rescheduled for 4.4. In the mean time I developed a fix for the H7RF, here: And a release for the above code: https://github.com/spracing/betaflight/releases/tag/spracingh7-20211224-1642 |
haslinghuis
added
BUG
|
@hydra Could you please explain why you define the same pins for bus 3 and bus 6. |
So that you can switch between them using just the Additional background: Different DMA controllers are used for SPI1/3 and SPI6 so it's useful to be able to balance the DMA resources and clock-speed requirements. On the H7RF SPI6 can be clocked at exactly 20Mhz because it has a different clock mux than SPI1/3 and uses a different DMA channel, so for the best utilization of the DMA controllers and the lowest latency gyro spi transfers SPI6 should be used for the Gyro, but currently there's no DMA support for SPI6. |
ctzsnooze
changed the title
haslinghuis
added this to Bug Tracker
in Finalizing Firmware 4.3 Release
via automation
|
Gonna close this as my expectations don't match the intended design. |
Describe the bug
Firmware fails to boot when a later unused SPI port uses the same pins as a used SPI port.
To Reproduce
Configure any H7 target to use PB3/PB4/PB5 for SPI3 and allocate the same pins for SPI6.
Likely also using SPI1 and SPI3 would also exhibit the same issue.
after disabling the gyro autodection code that fails,
resource showstill says:resourceshows:after it calls spiInit(SPIDEV_3) the AF's are correct.
after the call to spiInit(SPIDEV_6) the AF's are incorrect.
The AF's and pins are correct for both devices, but attempting to use SPI3 for the Gyro results in a lock-up as the SPI read never completes as the GPIO pins have the wrong AF now.
Likely the SPI device should not be initialised if the pins are used by another SPI device as per the resource configuration.
The default resource configuration in the target appears as follows:
The target.h file has this:
Expected behavior
FC shouldn't lockup, SPI3 should work.
However, I'm not 100% certain if it's intended that target definitions can define the same pin for multiple ports.
Flight controller configuration
Setup / Versions
Code use for testing is from #11110 (comment), which is based on a recent
masterwhich doesn't have any resource allocation / spi initialisation changes that I'm aware of. I verified that by comparing the source tree and looking at SPI related/resource files like pg/bus_spi.c, drivers/bus_spi*, drivers/io.c, etc.The text was updated successfully, but these errors were encountered: