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

Stack sizes and platform version issues/questions #4

Open
ntmmfts opened this issue Aug 10, 2024 · 3 comments
Open

Stack sizes and platform version issues/questions #4

ntmmfts opened this issue Aug 10, 2024 · 3 comments

Comments

@ntmmfts
Copy link

ntmmfts commented Aug 10, 2024

Hi, thanks for this project, haven't seen any others like it - especially with a PID written in assembly...

Having issues getting past canary watchpoint errors despite efforts adjusting stack sizes, and also issues with the platform version set in the repo. Got past working sizes for Tmr and IDLE, but get cpu 0 scheduler aborts with any other stack adjustments and no indication which stack causes it. When I get to this point, the backtrace decoder indicates it could be ESP_EARLY_LOGI(TAG, "Pro cpu start user code"); - and googling says that could be early debug logging before cpu is started - maybe for the stack size problems.

I saw your discussion with @dizcza and your mention of using version 4.2, but the platformio.ini in the repo still specifies 3.0.0. I can't get it to build when setting it to 4.0.0 due to endless mirror searches for matching tools, and also issues building with current 5.x with various deprecation and syntax issues.

Asking if you can update the sdkconfig with stack sizes that work with 3.0.0 or update everything to version 4 or 5 if you have either of those working.

Thanks again for this amazing work - I intend to leverage it in my (unpublished) WWVB emulator project for transmitting timecode as close to UTC as possible - currently getting sub 50ms precision without a PID. No time signal in Hawaii so I have to do it myself :-).

@liebman
Copy link
Owner

liebman commented Aug 11, 2024

I'm not going to get to that anytime soon :-(. But at some point I'll probably re-implement this using rust and using the MCPWM peripherals capture feature. I would accept PRs if you manage to upgrade it.

@ntmmfts
Copy link
Author

ntmmfts commented Aug 15, 2024

Ended up disabling brownout detection and disabling CONFIG_ESP_PHY_INIT_DATA_IN_PARTITION while the project is running off of USB power on a breadboard. Now encountering what looks like I2C and SPI conflicting which is making RTC reads irratic and freezing the display. This may be a documented problem from earlier esp-idf versions but didn't find anything specific for 3.0.0 and its updates. All of this may just be power related, but at least I'm past bootup - gonna power the components separately and see what happens.

@ntmmfts
Copy link
Author

ntmmfts commented Aug 16, 2024

Got it working, it was a breadboard wiring issue. Going to review your conversation with @dizcza and experiment with those tweaks.

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

No branches or pull requests

2 participants