What mean - max min avg ovr in tasks log?
threads.txt will contain CPU usage as a percentage if you build with this option
Yes - i’m understand this - later i’m rebuild fw. I’m don’t understand what max min ovr avg in tasks.txt?
task execution time in us
Not building -
In file included from …/…/modules/ChibiOS/os/rt/include/ch.h:116,
from …/…/modules/ChibiOS/os/hal/osal/rt-nil/osal.h:32,
from …/…/modules/ChibiOS/os/hal/include/hal.h:28,
from …/…/libraries/AP_HAL/board/chibios.h:4,
from …/…/libraries/AP_HAL/AP_HAL_Boards.h:131,
from …/…/libraries/AP_HAL/AP_HAL.h:6,
from …/…/libraries/AP_Param/AP_Param.h:27,
from …/…/libraries/AC_AttitudeControl/AC_AttitudeControl.h:7,
from …/…/libraries/AC_AttitudeControl/ControlMonitor.cpp:1:
…/…/modules/ChibiOS/os/rt/include/chschd.h: In function ‘void ch_sch_prio_insert(ch_queue_t*, ch_queue_t*)’:
…/…/modules/ChibiOS/os/rt/include/chschd.h:509:14: error: cast from ‘ch_queue_t*’ {aka ‘ch_queue*’} to ‘thread_t*’ {aka ‘ch_thread*’} increases required alignment of target type [-Werror=cast-align]
509 | (((thread_t *)cp)->hdr.pqueue.prio >= ((thread_t *)tp)->hdr.pqueue.prio));
And many this errors…
Yeah the chibios upgrade broke it, needs fixing …
Ok.
But again - i’m revert size of buffers and enable dma on serial6 - gps.
And again see this messages.
What i’m doing wrong?
There is definitely a problem and I don’t want to crash on a heavy copter again.
Maybe this related to dma? How many channels have f4 - if i’m enable dma for all serials this normal?
Or GPS doesn’t like dma?
I don’t mind using 4.0.7 - but there is no crossfire.
No
Diving so deep into the code is impressive but I think we should take a step back and see an onboard log file. Could you post one?
By the way, linked to this discussion was this change that added a GPS_DRV_OPTIONS bit that allows forcing the UBlox GPS to 115000 baud. This change was included in Copter-4.1.0-beta7.
@andyp1per, don’t you think we’re diving in a bit too deep here before taking a more high level look at the problem?
What logs you need - now i’m using moded fw with edited buffers and disabled DMA on serial6 - you need logs from stock fw without any mods?
Ok. I’m using crossfire on serial1 - need DMA but stock hwdef disabled DMA on serial1 - any reason for this? If i’m enable DMA on serial1 - this good for proper log or need using other port? (bad way for me - because serial1 - this is sbus pin which in stock using for recievers and have inverter…)
The electrical problem is fixed. Now the 5v for GPS is stable. The problem of GPS reinitialization is still present. It begins a few minutes after arming and then it becomes more frequent.
I updated the firmware to the latest beta and learned get a log (sorry, i am only a “user”). As soon as the weather allows, i try to provide a log. I will also try GPS_DRV_OPTIONS
1 Like
Oh. I’m maybe find - power on crossfire makes this spikes - and not matter original crossfire or elrs - crsf protocol make AP unstable.
From logs - first minute i’m not enable crossfire and after i’m power on my elrs and see gps health warnings in mission planner.
This logs from stock unmodified AP beta 7
Links for logs.
https://drive.google.com/file/d/1BPLRihrG0CgydXBCZyJxwQoNMJnbpKjJ/view?usp=sharing, https://drive.google.com/file/d/1dNuECwTA_J84rN1Msu72wE0C6Y8Ibjmm/view?usp=sharing, https://drive.google.com/file/d/1r25-gSj9WQDG0lhVb0pqg8MjwsuKAMYm/view?usp=sharing
And i’m found some strange in
libraries/AP_RCProtocol/AP_RCProtocol_CRSF.cpp
/*
- CRSF protocol
- CRSF protocol uses a single wire half duplex uart connection.
- The master sends one frame every 4ms and the slave replies between two frames from the master.
This not right for RX side - rx working in full duplex mode - this only true for TX side.
And baud rate from ELRS using for RX = 420000 but AP using 416666 - this strange baud rate?
And what softserial did in crsf protocol?
from
libraries/AP_RCProtocol/AP_RCProtocol_CRSF.h
SoftSerial ss{CRSF_BAUDRATE, SoftSerial::SERIAL_CONFIG_8N1};
stm32 f4 can handle data with soft serial for this baud rate?
Maybe but BF, inav, elrs using 420000 baud rate. But ok - differences are minimal.
Now it remains to find out why the crsf in AP so affects the gps or maybe the whole system
Just to recap this discussion, we really have two separate reports in this thread:
-
@THKoelnMech’s issue is the GPS resets intermittently which I’m pretty confident will be fixed with the GPS_DRV_OPTIONS bit to force the UBlox to use 115200 baud. @THKoelnMech is going to try this and if it works I can close the "Mamba losing GPS connection " issue on the 4.1 issues list.
-
@Evgen_Stenkin’s issue is that if ELRS or CRSF is used the GPS (?) doesn’t work? This is currently not recorded on the 4.1 issues list. @andyp1per can you help us get to the bottom as to whether this is a software or hardware issue and whether we need to track this issue?
gps working but AP always send warning messages about gps health when using crsf protocol. And i’m don’t know maybe this can make some problems in flight, or gps position issues - last my flight ended with crash - fc rebooting at 150m alt - my radio always say me about gps health…
i’m make some tests - increasing buffers and disabling dma not helping if speed > 57600. This mean that AP can handle GPS data with only with 57600 or slower baud if using crsf protocol.
Please optimise crsf protocol stuff - i’m think something need rewrite
Thanks for the report.
So, we need to separate these issues and get logs for them. Also ideally it would be best to fly with the regular beta firmware. AP of course is open source and we welcome people making their own changes but it makes it difficult for us to support.
I had a look at the .bin log linked above (there’s also a .tlog and .rlog but I didn’t look at these because they normally have much less information in them than the .bin) and it looks like the GPS never got a lock. It does appear to be sending messages though which makes me think the telemetry radio is interfering with the GPS due to EMI (electromagnetic interference) rather than the issue being a software problem.
Can you provide a .bin log for the crash at 150m? This is pretty scary and I’d like to get to the bottom of it.
I’ve put the CSRF + GPS issue on the 4.1 issues list so it won’t be forgotten.
Thanks again and sorry if I’m being a little strict and asking you to do all kinds of things. Your testing is greatly appreciated!
No - this normal - i’m at home 
- no time to test in outdoor - but gpa delta we can see without fix. At outdoor GPS locking very fast…
Oh no - bacause AP clear data from flash - i’m find my copter - power off and travel to home - at home i’m power on and see that logs cleared - i’m think because data flash full and after rebooting AP clear all data from flash and start new log.
Maybe full flash make internal error or fc rebooting - dont know… But before i’m using crossfire - i’m never have any crash
1 Like