BLHeli32 ESC telemetry setup - how?

Works great. I have ESC telemetry on SERIAL7

To do it this way requires undefining an SPIDEV declaration - is this possible?

great, thanks for testing! i commented your PR respectively. donā€˜t get me wrong on this please, i just think itā€˜d be nice to avoid having users run into the same issue.

cheers, basti.

Just as an update - I have raised a bug for the BLHeli issues https://github.com/ArduPilot/ardupilot/issues/12542 - the good news is that the ā€œCritical errorā€ goes away when I turn off auto telemetry. The bad news is that telemetry appears to be overloading the MCU - and this is an F7. So Iā€™m glad I got it working, but not going to fly with it for now :slight_smile:

It should not be overloading mcu. R u sure it is telemetry? What loop frequency do u set in params?

I have 2 models on regular kakute f7 that uses esc telemetry. Mini f7 is a same chip.

Loop rate 800Hz. Without telemetry everything is fine.

Try setting to 400. U see cpu jumping to the max as soon as u arm? I saw it too, it was not esc feed.
It was mavlink loop, i do not recall. Tridge knows better, ask him

iā€™d say adding BLH telemetry might be whatā€™s finishing off your block logging, but likely not the root cause. canā€™t reproduce any errors by enabling BLH telemetry alone. besides having doubled your sched looprate thereā€™s relevant changes to log_bufsize and sample rates in your params too.
iā€™m not exactly familiar with int err code handling, but isnā€™t 0x8000 pointing to a logger_blockcount_mismatch ?

That f7 mini has no logging support on flash? Turning off all logging then may also help

It logs internally - thatā€™s working fine. Higher loop rate with this is also fine - the internal dataflash is much faster than an SD card.

I can run on this board with a dynamic FFT of 128 at 800Hz loop - that sucks up CPU but itā€™s still fine. Iā€™ve flown on F4ā€™s like this with no issues at all.

As soon as I switch on ESC telemetry its not fine - logs disappear, internal errors ā€¦

But the 0x8000 steer is interesting - maybe itā€™s the logging of the ESC telemetry data that is causing the issue

EDIT: scratch that 0x8000 is main_loop_stuck so something is really blowing this up

What does the NODMA flag achieve on UART pins? Wondering whether this should be set on the Kakute telemetry pin

Try it. But, nodma is what it means - no dma support for data stream on that input. With nodma hint it should use more cpu, but i never saw an actual measurable impact from uart data streams on f7 arm chips. Cpu is killed by some other loop, in the gitter channel tridge explained it once what it was, but i do not remember. I never found enough time to learn that code, may be this winter, if time permits I will.

I think it was mavlink, but, not sure. I also got to say, boosting loop timing is not really that important. 80hz for filters is, i can look later at params from my 3" abd 4" models

@andyp1per i think i could reproduce the issue, i can trigger it by doing BLH_TEST. this makes EKF flag pos vert error, reset and it triggers internal error 0x8000. can you try and reproduce on your board?

Yeah I definitely get the error by doing that.

I added NODMA to the RX pin and now things are looking a lot more sane - my logging is working and no internal errors. The RPM values have wide variation, which I find a bit suspicious - but thatā€™s a different problem.

Hereā€™s a graph of the output:

thereā€™s something wrong in BLH debug handling on copter too, as you noticed further up. on plane it returns console prompts as expected, it does not on copter though.

I use nodma on all uarts as a precaution as on early kakutes it was producing hiccups on dma stream into dshot protocol to motors causing flips and crashes
I did not get it on the last newest kakute f7 i used. And did not get it on matek f765. So, be careful

Ok, I will do a PR on the PR that tridge just merged :stuck_out_tongue:
Whatā€™s the correct way to disable the TX pin? I think I have this wrong.

iā€™m testing on a plain 405 with just the esc connected and can reliably trigger int err 0x8000 by doing BLH test. you sure this is board/dma related?

Btw, if you did a 3" gecko - what lipo u used? What is your final weight, did you get under 250g with lipo?
I dis not get that frame yet, did 4" gecko on 4s - crazy fast, flies around 10min, but a bit heavier than 250g

Iā€™m not sure. But the two donā€™t have to be related. Certainly my internal errors have now disappeared. I was also getting a lot of CRC errors in the console but they have all disappeared - so NODMA has certainly fixed something.