(resolved) can't redirect console output (regression)

ESP_Angus
Posts: 1897
Joined: Sun May 08, 2016 4:11 am

Re: can't redirect console output (regression)

Postby ESP_Angus » Thu Nov 14, 2019 1:59 am

mzimmers wrote:
Wed Nov 13, 2019 3:22 pm
1. As I mentioned above, this all came about when I tried to migrate to IDF release/v4.0. When I returned to release/v3.3, however, the problem persisted. I had assumed that the release/v3.3 branch was immutable at this point, but perhaps I was mistaken. If it isn't immutable, which IDF should I use in production?
The release branches are not immutable. We tag our releases with git tags, but then keep backporting changes to the release branch which will then become, for example, v3.3.1, v3.3.2, etc. The latest v3.3 stable release is v3.3: https://docs.espressif.com/projects/esp-idf/en/v3.3/

The IDF docs has a section about versions which explains the difference between these concepts. If you find any information there is missing or unclear, please let me know - we want the system to be clearly understood by everyone: https://docs.espressif.com/projects/esp ... sions.html
mzimmers wrote:
Wed Nov 13, 2019 3:22 pm
2. As a follow-up to #1, what IDF release I can I use today to verify that this was the problem?
The bug was introduced to master (which was then version v4.0-dev) in commit 434dd2d7 and backported to release/v3.3 branch in commit f380d728. This commit isn't in the v3.3 release ("git tag --contains f380d728" confirms this), so if you "git checkout v3.3" then the UART will work correctly again.
mzimmers wrote:
Wed Nov 13, 2019 3:22 pm
3. Why am I able to see the bootloader output in my console but not my application output?
During app startup IDF makes some additional tweaks to the flash config, and one of them clobbers GPIO 9 & 10 UART function.
mzimmers wrote:
Wed Nov 13, 2019 3:22 pm
4. Oh yeah: when and where can I expect to see the fix? (your comment about use of SD2/3 is noted; I'm forwarding that information to my HW guys)
May be a week or two because we're having issues (again) with our internal CI system infrastructure, so a lot of changes are getting queued up. If this is a blocker for you then I can give you a short patch that fixes the problem, you can apply it to IDF and then remove it later when you update.

Which branch do you want the patch for?
mzimmers wrote:
Wed Nov 13, 2019 3:22 pm
Finally, I'm impressed by how quickly you found the root cause of this problem. May I ask what development tools you use?
I'm not a good candidate for dev tool recommendations, due to almost two decades of being an emacs user. I'm not fast with emacs because it's somehow superior, I'm fast because I have all the relevant emacs addons I use (helm, projectile, gnu global tags integration, etc) baked into my subconscious & the keyboard shortcuts in my muscle memory.

The reason I found this bug pretty quickly is less exotic: I've been working on ESP-IDF since before it was called ESP-IDF, and it's my job to know what goes on in the IDF codebase.
mzimmers wrote:
Wed Nov 13, 2019 3:22 pm
My primary complaint about the ESP32 platform is the paucity of modern development tools, notably an interactive debugger. The lack of this has been a major factor in my productivity with this device. (That's why I was trying to move to Eclipse in the first place.)
That's fair, and major reason is that most of the early ESP-IDF core developers were comfortable with "old school" tools like emacs/vim/etc.

The new Eclipse plugin looks really good, I'm excited about and I think it will change this situation for the better (I'm almost ready to give up my comfort blanket of emacs and switch. Almost). There is also official VSCode support coming soon, including debugger support also.
mzimmers wrote:
Wed Nov 13, 2019 3:22 pm
Also, regarding the use of SD2/SD3: if I'm reading the datasheet correctly, these are my only choices for UART1. I tried using menuconfig to assign some other lines (IO32 and IO35), but I'm not getting any output. Can someone confirm that this is expected behavior?
GPIOs 34 and higher are input-only. Probably the config system should limit setting them as TX pins, sorry about that. If you set RX to 35 and TX to 32 then it should work.

Pin functions in ESP32 are a bit confusing. We have the "IOMUX" for high speed assignments, and it has fixed pin-to-peripheral mappings (that's the pin where IO9 is UART1 or SD2, etc). Then there is "GPIO Mux" which allows arbitrary peripheral to pin mappings. Some peripherals (SD card for example) need to use IOMUX.

Other peripherals can use either IOMUX or GPIO Mux, meaning any pin. The only reason to require IOMUX is if you need really high speeds (40MHz+). If you don't need to run UART1 at 40Mbaud, you can use any pins.

ESP_Angus
Posts: 1897
Joined: Sun May 08, 2016 4:11 am

Re: can't redirect console output (regression)

Postby ESP_Angus » Thu Nov 14, 2019 2:00 am

mzimmers wrote:
Wed Nov 13, 2019 11:07 pm
Unfortunately, using v3.3 yields the same (erroneous) behavior for my app as did v3.3-rc.
That's interesting, maybe I'm wrong about exactly when the regression was introduced (I didn't test any v3.3 revisions at all.)

If you'd like a temporary patch to fix it on either v3.3 or v4.0 branch, let me know.

User avatar
mzimmers
Posts: 393
Joined: Wed Mar 07, 2018 11:54 pm
Location: USA

Re: can't redirect console output (regression)

Postby mzimmers » Thu Nov 14, 2019 2:04 am

Thanks for the offer. At this point, though, I'm still wondering how it is that it works for the hello world example, but not for my app. As stated above, the sdkconfig files are nearly identical (I have to build my app in release mode due to size constraints), and the partition table is identical.

If you could patch v3.3 (and give me a link to it), I'd appreciate it.

ESP_Angus
Posts: 1897
Joined: Sun May 08, 2016 4:11 am

Re: can't redirect console output (regression)

Postby ESP_Angus » Thu Nov 14, 2019 2:37 am

mzimmers wrote:
Thu Nov 14, 2019 2:04 am
Thanks for the offer. At this point, though, I'm still wondering how it is that it works for the hello world example, but not for my app. As stated above, the sdkconfig files are nearly identical (I have to build my app in release mode due to size constraints), and the partition table is identical.
Oh, I missed that. Not sure what the root cause here is, maybe as you say something unrelated to console? If you add a log statement as the first line in your app_main(), does this get printed?
If you could patch v3.3 (and give me a link to it), I'd appreciate it.
Will do, give me a day or so.

User avatar
mzimmers
Posts: 393
Joined: Wed Mar 07, 2018 11:54 pm
Location: USA

Re: can't redirect console output (regression)

Postby mzimmers » Thu Nov 14, 2019 3:15 am

ESP_Angus wrote:
Thu Nov 14, 2019 2:37 am
Oh, I missed that. Not sure what the root cause here is, maybe as you say something unrelated to console? If you add a log statement as the first line in your app_main(), does this get printed?
Nope. My app_main() does not seem to get called. Very strange...

User avatar
mzimmers
Posts: 393
Joined: Wed Mar 07, 2018 11:54 pm
Location: USA

Re: can't redirect console output (regression)

Postby mzimmers » Thu Nov 14, 2019 6:09 pm

Current summary:
  • my app doesn't seem to be starting.
  • I'm fairly sure that the console bug that Angus referenced above is no longer a factor.
  • I put some telltales in port.c; here are the results:

    Code: Select all

    I (359) cpu_start: Starting scheduler on PRO CPU.
    I (359) port.c: _xt_coproc_init() completed.
    I (359) port.c: _xt_tick_divisor_init() completed.
    I (359) port.c: _frxt_tick_timer_init() completed.
    I (m59)35ortcp: xPart: Stareing schedueted.
    CPU.
    I (369) port.c: _xt_coproc_init() completed.
    I (369) port.c: _xt_tick_divisor_init() completed.
    I (379) port.c: _frxt_tick_timer_init() completed.
    I (379) port.c: xPortGetCoreID() completed.
    0m
    0m
    0m
    0m
  • The 0m goes on for several more lines, then gives way to a bunch of blank lines, then I start getting this:

    Code: Select all

    E (5379) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
    E (5379) task_wdt:  - IDLE1 (CPU 1)
    E (5379) task_wdt: Tasks currently running:
    E (5379) task_wdt: CPU 0: IDLE0
    E (5379) task_wdt: CPU 1: ipc1
So, a few things seem curious to me:
  1. why am I getting the telltales twice?
  2. note the garbling of the 1st instance of my 4th telltale.
  3. I don't know where the "CPU" or the "0m" lines are coming from.
Hopefully someone can shed some light on this...thanks.

User avatar
mzimmers
Posts: 393
Joined: Wed Mar 07, 2018 11:54 pm
Location: USA

Re: can't redirect console output (regression)

Postby mzimmers » Fri Nov 15, 2019 6:03 pm

BTT. Is this an appropriate candidate for opening an issue on github?

WiFive
Posts: 2822
Joined: Tue Dec 01, 2015 7:35 am

Re: can't redirect console output (regression)

Postby WiFive » Sat Nov 16, 2019 2:26 am

If you can provide an app that reproduces it. Have you tried verbose log level?

User avatar
mzimmers
Posts: 393
Joined: Wed Mar 07, 2018 11:54 pm
Location: USA

Re: can't redirect console output (regression)

Postby mzimmers » Sat Nov 16, 2019 2:58 am

I can definitely provide a reproducible example. I'm not sure how much my app figures into this, though, given that the problem seems to occur before (or just as) app_main starts. Opinion?

WiFive
Posts: 2822
Joined: Tue Dec 01, 2015 7:35 am

Re: can't redirect console output (regression)

Postby WiFive » Sat Nov 16, 2019 3:10 am

Whatever minimum viable example you can put together that consistently reproduces the problem.

Who is online

Users browsing this forum: Bing [Bot], WiFive and 13 guests