iNavFlight
Updated resource mapping for neutronrcf435mini target
This PR is in response to the issue #10059 . I have checked the resource mapping of the board and compared it with the config file in BF and indeed there is a deviation in the resource mapping of the UART port.
Changes I made
Referenced from BF
The datasheet for the chip says PB11 is the rx, PB10 is the tx. (Page #38 in the datasheet). https://www.arterychip.com/download/DS/DS_AT32F435_437_V2.12_EN.pdf
Have you tested this?
We don't want to blindly copy mistakes from Betaflight, so please let us know if you've tested it, which would indicate the manufacturer of the chip (Artery) may have an error.
If it is tested and confirmed, there are at least three targets this would probably apply to.
https://github.com/iNavFlight/inav/commit/37c417e36e08ebea64702f70f70f992f8f708e5b
Hello @sensei-hacker I checked it by flashing my own fc with the compiled target, now we have a completely different problem💀.
I have confirmed that the original firmware does not work for the UART3
And it only works when the pins are mapped like this
receiver FC
TX -> TX3(yellow)
RX -> RX3(white)
But even after changing the resources and flashing the custom firmware, it had the same issue and only worked in the tx-tx3 and rx-rx3 mapping and not tx-rx3 and rx-tx3
This suggests that my changes did not affect the uart3 pin mapping and could be some underlying problem
The AT32 and a couple of STM32 chips have a "uart pin swap" feature where software can change the pins responsibilities after the fact. This is commonly done to avoid high traffic uart devices, like receivers, blocking the dfu bootloader by swamping it with data. Neutron uses that quite heavily on their boards. This PR corrects the assignments but we would still need a piece of code in the uart driver to detect this scenario and trigger the re-assignment.
