Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updated resource mapping for neutronrcf435mini target #10065

Closed

Conversation

Pglol03
Copy link

@Pglol03 Pglol03 commented May 20, 2024

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
image

Referenced from BF
image

@sensei-hacker
Copy link
Collaborator

sensei-hacker commented May 20, 2024

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.

37c417e

@Pglol03
Copy link
Author

Pglol03 commented May 20, 2024

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
telegram-cloud-photo-size-5-6222196899734209103-y
And it only works when the pins are mapped like this
receiver FC
TX -> TX3(yellow)
RX -> RX3(white)
telegram-cloud-photo-size-5-6222196899734209102-y

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
telegram-cloud-photo-size-5-6222196899734209107-y
telegram-cloud-photo-size-5-6222196899734209106-y

This suggests that my changes did not affect the uart3 pin mapping and could be some underlying problem

@bkleiner
Copy link
Collaborator

bkleiner commented Aug 8, 2024

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.

@bkleiner bkleiner mentioned this pull request Sep 2, 2024
@bkleiner
Copy link
Collaborator

replaced by #10333

@bkleiner bkleiner closed this Sep 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants