20-Jan-2021, 09:09 PM (This post was last modified: 20-Jan-2021, 09:10 PM by SnowLeopardFPV.)
Everything looks fine. I'm not entirely sure what FC you have in that. On the GEPRC product page for the Thinking P16 (HERE) is states that it uses a GEP-12A-F4 AIO FC, but I have one of those FC's but it doesn't look like yours. Mine is a V1.2 and looks like the one HERE. Notice that yours has long traces where the motors sockets are soldered to it, and there are some MOSFETS on the top side of the board.
Either way, I flashed my GEP-12A-F4 AIO FC with the GEPRCF411 target to Betaflight 4.1.7 as yours is on and I then ran your complete dump onto mine. Then I ran the "resource show all" command, and the A02 and A03 resources are correctly allocated to SERIAL_TX 2 and SERIAL_RX 2 as shown below.
I suggest you save a "diff all" of your configuration and then re-flash the Betaflight 4.1.7 firmware making sure that the "Full chip erase" option is switched on. Then run your "diff all" back in.
Well all I can tell you is that my V1.2 board works on Betaflight 4.1.7 with your dump file loaded. So it can only either be corrupt firmware or faulty hardware. It's still worth trying to re-flash the FC again with the full chip erase option, even if you already did that when you got the new board. It's odd that GEPRC don't seem to list the V1.3 board on their website, and no other vendors have it listed either that I can find, so I wonder if that version is still under development and testing, in which case you could have ended up with a "beta" version of the board that still has issues.
(20-Jan-2021, 10:24 PM)SnowLeopardFPV Wrote: Well all I can tell you is that my V1.2 board works on Betaflight 4.1.7 with your dump file loaded. So it can only either be corrupt firmware or faulty hardware. It's still worth trying to re-flash the FC again with the full chip erase option, even if you already did that when you got the new board. It's odd that GEPRC don't seem to list the V1.3 board on their website, and no other vendors have it listed either that I can find, so I wonder if that version is still under development and testing, in which case you could have ended up with a "beta" version of the board that still has issues.
It's the default board that comes with Thinking P16 HD, it's not available for purchase as a single component.
However I wrote to GEPRC and hopefully they should answer during the night (Italian time). I will keep you updated!ù
(20-Jan-2021, 10:43 PM)voodoo614 Wrote: This is an odd problem. I wonder if GEPRC changed the design and pin assignments but haven't update the config file. I had a hard time finding his FC.
You can trace the RX2 and TX2 to the MCU and see which pin it is connected to.
I sent a very detailed email to GEPRC, let's see...
In the meantime, please see the following link. It's related to my specific version of FC.
(21-Jan-2021, 09:30 AM)Zanna83 Wrote: By the way, what excactly do the CLI commands listed below the DJI unit ?
Quote:feature SOFTSERIAL <- enables Softserial resource SERIAL_TX 1 none <- unassigns the resource assigned to TX1 resource SERIAL_RX 1 none <- unassigns the resource assigned to RX1 resource LED_STRIP none <- unassigns the resource assigned to LED_STRIP resource SERIAL_TX 11 A09 <- assigns pin A09 to Softserial TX1 resource SERIAL_RX 11 A08 <- assigns pin A08 to Softserial RX1 serial 1 64 115200 57600 0 115200 <- enables Serial Rx on UART2 serial 30 1 115200 57600 0 115200 <- enables MSP on Softserial1 SAVE <- saves configuration and reboots FC
This is a workaround due to the lack of UARTs on most F4 FCs. People have reported problems running the DJI MSP interface over Softserial, so let us know how it works out.
21-Jan-2021, 10:26 AM (This post was last modified: 21-Jan-2021, 10:31 AM by Zanna83.)
Thanks, I cannot understand the following lines:
resource SERIAL_TX 11 A09 <- assigns pin A09 to Softserial TX1 resource SERIAL_RX 11 A08 <- assigns pin A08 to Softserial RX1 serial 1 64 115200 57600 0 115200 <- enables Serial Rx on UART2 serial 30 1 115200 57600 0 115200 <- enables MSP on Softserial1
I suppose that the number 11 assigned to the "virtual" port is just an index greater than 10... I could assign for example number 12 without problems, right ? And the numbers following the instruction "serial" ?
Well the V1.3 board is documented as using the MATEK411 target. The GEPRCF411 target has identical resource assignments as the MATEKF411 target except that it doesn't assign the I2C1 resource, and it also has a different gyro alignment, so they are essentially the same target and but neither of those differences will cause the issue that you're seeing. The problem you have is a firmware and MCU issue, so even if traces from the MCU pins went to different pads on the board compared to the V1.2 board, the A02 and A03 outputs of the MCU should still be getting assigned (and owned by) the UART2 TX and RX resources.
When you assign a resource to an MCU output pin, the resource will only be given ownership of that MCU output if something is configured to make use of it. In your case, UART2 is configured for "Serial RX" and the Serial Provider is set to "CRSF". So that is enough to give ownership of the A02 and A03 MCU outputs to UART2. But yours is clearly showing "FREE" as the owner while mine shows "SERIAL_TX 2" and "SERIAL_RX 2" as the owner using exactly the same Betaflight firmware target/version and exactly the same dump loaded in for the settings.
(21-Jan-2021, 10:26 AM)Zanna83 Wrote: I cannot understand the following lines:
resource SERIAL_TX 11 A09 <- assigns pin A09 to Softserial TX1 resource SERIAL_RX 11 A08 <- assigns pin A08 to Softserial RX1 serial 1 64 115200 57600 0 115200 <- enables Serial Rx on UART2 serial 30 1 115200 57600 0 115200 <- enables MSP on Softserial1
I suppose that the number 11 assigned to the "virtual" port is just an index greater than 10... I could assign for example number 12 without problems, right ? And the numbers following the instruction "serial" ?
Yes, serial resources 11 and 12 are reserved for SoftSerial, and Betaflight makes two software serial ports available for optional use. If either or both of those two special serial resources have MCU output pins assigned to them you will then see SOFTSERIAL1 (which relates to serial port 30) and SOFTSERIAL2 (which relates to serial port 31) in the ports tab respectively.
This shouldn't make any difference to resource assignments / ownership inside the MCU, but desolder the Crossfire Nano RX from the T2 and R2 pads, then run both the "dump" and "resource show all" commands again, and post the results back here.
I managed to map UART2 correctly! This evening I will check if crossfire is correctly speaking with the FC but I think everything is solved!
I flashed again 4.1.7 on the FC with target GEPRCF411 but this time, when after the first connection BF asks to restore custom settings, I answered NO!
With a completely clean firmware, the DUMP received from GEPRC loaded like a charm with everything perfectly mapped. Now my dump is identical to the one Snow posted a couple of post above. The problem was in the "custom settings" betaflight sets after flashing the firmware.
Thank you Snow and Voodoo for your precious help and for all the explanations!!
UART2 was correctly mapped before, so I'm confused as to what is now different if you've simply just ran the dump in over the top of a fresh flash. All you did by not applying custom defaults was that you didn't apply the MATEKF411 of GEPRCF411 unified settings, but by then running in the dump you would have applied them anyway.
If you run "resource show all", does it now show A02 and A03 correctly owned by "SERIAL_TX 2" and "SERIAL_RX 2"?
(21-Jan-2021, 02:01 PM)SnowLeopardFPV Wrote: UART2 was correctly mapped before, so I'm confused as to what is now different if you've simply just ran the dump in over the top of a fresh flash. All you did by not applying custom defaults was that you didn't apply the MATEKF411 of GEPRCF411 unified settings, but by then running in the dump you would have applied them anyway.
If you run "resource show all", does it now show A02 and A03 correctly owned by "SERIAL_TX 2" and "SERIAL_RX 2"?
I flashed 4.1.7 and refused to install default settings when suggested by betaflight.
At this point "resource show all" generates a list of FREE without any assignment.
I sent the following CLI
resource serial_tx 2 A02 resource serial_rx 2 A03 save
Then I activated SERIAL RX on UART 2 in the section Port on betaflight.
In section Configuration i selected the correct protocol for crossfire CRSF and activated the feature "Telemetry".
After that UART 2 was already correctly mapped on A02 and A03.
Finally i loaded the dump received from GEPRC support.
Had you applied the custom defaults and then applied the GEPRC dump it would have resulted in exactly the same outcome. So it looks like it was just down to corrupt firmware from a previous flash.
![[-]](https://intofpv.com/images/collapse.png)
