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

Correct OmnibusNanov6 build #12800

Open
wants to merge 3 commits into
base: master
from

Conversation

@andyp1per
Copy link
Contributor

andyp1per commented Nov 8, 2019

This adds the OmnibusNanov6 HAL subtype to the list of boards to avoid compilation warnings and turns off DMA on the ESC telemetry UART which generally seems to be a problem when using Dshot.

@andyp1per andyp1per added the ChibiOS label Nov 8, 2019
@andyp1per

This comment has been minimized.

Copy link
Contributor Author

andyp1per commented Nov 8, 2019

Need @1wick to confirm that the DMA change is necessary

@1wick

This comment has been minimized.

Copy link

1wick commented Nov 8, 2019

I got busy w/ work, and tomorrow am home alone w/ my 4 year old, so probably won't be able to do any testing.. Maybe Sunday.
I have had several flights using the ESC Telemetry based notch w/ the official 4.0rc2 release, and have had no problems at all. So w/ this release, the noDMA mod doesn't seem necessary.

But, I'll put your firmware w/ the FFT back on it and do the same things I was doing a few days ago to see if I get all those prearm errors again. And then either way, I'll put the noDMA version on it and take a few flights and report back.

@1wick

This comment has been minimized.

Copy link

1wick commented Nov 10, 2019

OK,
The issue is repeatable w/ even the default 4.0rc2. And even on a new FC w/ nothing installed, fresh of the bag.

Calibrate level, and I get 0x8000 error and cannot arm. 3.6 doesn't cause the error.
The no DMA version made no difference.

Doing a 'soft reboot' doesn't fix it.. that's when I start getting the 0x4000 errors as well. (by soft reboot I mean in MP, Actions, preflight_reboot_shutdown, DO Action)

It's ok after a complete power off.

@tridge

This comment has been minimized.

Copy link
Contributor

tridge commented Dec 12, 2019

the cal level error is easily fixed, and I've opened a PR for it here: #13043
The one I'd really like to reproduce is the SPI timeout. My omnibusnanov6 has now arrived but I don't see the SPI timeout. If anyone can give me exact instructions for reproducing that from a bare board it would be appreciated

@andyp1per

This comment has been minimized.

Copy link
Contributor Author

andyp1per commented Dec 12, 2019

@tridge I've not been able to reproduce. I guess we can see if the cal level fix makes the other one go away?

@tridge

This comment has been minimized.

Copy link
Contributor

tridge commented Dec 12, 2019

@andyp1per they should be unrelated. I'd really like to find the SPI issue ...

@1wick

This comment has been minimized.

Copy link

1wick commented Dec 12, 2019

@tridge, For me, I got the SPI timeout if I hot reboot after doing a level calibration. That's the only time I got it.
So, calibrate level. It causes error. I thought a quick reboot would fix it, so I tried rebooting from in MP, actions, preflight_reboot_shutdown, then I got the SPI error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.