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

[ESP_Angus]

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

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.

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.

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?

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.

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.

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]

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.

[mzimmers]

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]

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.

[mzimmers]

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...

[mzimmers]

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.

[mzimmers]

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

[WiFive]

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

[mzimmers]

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]

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