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

redpine white-screens on Devo7e #1002

Closed
bkleiner opened this issue Oct 2, 2020 · 10 comments
Closed

redpine white-screens on Devo7e #1002

bkleiner opened this issue Oct 2, 2020 · 10 comments

Comments

@bkleiner
Copy link
Contributor

bkleiner commented Oct 2, 2020

With #1001 merged the devo7e seems to white-screen upon repine protocol selection.
I do not own a 7e myself, only got reports by a buddy, to go off:

Flashed the latest nightly to Devo7e, get same result - when redpine is selected, I get a white screen and radio will not power down

Find attached the ERRORS.TXT and the debug-devo7e-v5.0.0-dcfee1f.zip

What could be causing this issue? would be more then happy to submit another PR.

@TheRealMoeder
Copy link
Contributor

It crashes in static void redpine_init(unsigned int format), probably not all statics are initialized in the modular build and this messes things up. Will debug further.

@TheRealMoeder
Copy link
Contributor

I tried to reproduce the issue, but everything works fine here with redpine in a modular build on t8sg_v2...

@somewhatlurker
Copy link
Contributor

I notice that the format variable is initialised to 0 and therefore placed in .bss. Does the module loader initialise bss to 0 like the buildchain expects? I don't see that in the code. If it doesn't, format may not be initialised before the first call to redpine_init, leading to an out-of-bounds read.

If the above is correct, we should probably zero the module memory before loading to ensure it can't happen again.

@goebish
Copy link
Member

goebish commented Oct 7, 2020

unsigned format = 0;
is bad for modular build, it should be initialized in a function.

@TheRealMoeder
Copy link
Contributor

@bkleiner Next nightly version should contain the fix, please ask your buddy to try again with the updated build

@bkleiner
Copy link
Contributor Author

You just beat me to the punch, was just sitting down to give the bss theory a test.
We will test and report back, thanks!

@bkleiner
Copy link
Contributor Author

With the latest nightly selecting the redpine protocol no longer crashes the radio. However it seems to not bind up with the RX. There is a possibility my receiver implementation is at fault here, it seems to work just fine with other radios though.
We will investigate and report back.

My bud did mention that the TX Power setting only allows him to select "default" for redpine, not sure if that is related at all.

@vladislavy
Copy link
Contributor

Cneck if "hardware.ini" has
has_pa-cc2500 = 1

"default" will be with that line commented
; has_pa-cc2500 = 1

@bkleiner
Copy link
Contributor Author

Sorry for the delay. Seems there was a bit of a miscommunication on our end, with the latest fixes it’s all working.
Issue can be closed imho.

@TheRealMoeder
Copy link
Contributor

Great! Thanks for helping to track the bug!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants