Not able to change XTAL frequency when building the example
Mforcen opened this issue · 8 comments
I'm trying to build and run an example on a board that is using a 26MHz XTAL instead of the default 40MHz one.
I've been using this board successfully with the esp-idf in C, so I know it is possible to use it with such configuration.
I've tried setting the configuration like in the idf example. So far I've:
-
Added the following section to the Cargo.toml file:
[package.metadata.esp-idf-sys]
esp_idf_sdkconfig = "sdkconfig"
esp_idf_sdkconfig_defaults = ["sdkconfig.defaults"] -
Added the following lines to sdkconfig.defaults
CONFIG_SOC_XTAL_SUPPORT_26M=y
CONFIG_XTAL_FREQ_SEL=26
CONFIG_XTAL_FREQ=26
CONFIG_XTAL_FREQ_26=y
CONFIG_ESP32_XTAL_FREQ_26=y
CONFIG_ESP32_XTAL_FREQ=26 -
Copied the file sdkconfig.defaults to sdkconfig
-
Added the following lines in .carg/config.toml in the [env] section
CONFIG_XTAL_FREQ_SEL = "26"
CONFIG_XTAL_FREQ = "26"
CONFIG_XTAL_FREQ_26 = "y" -
Run
CONFIG_XTAL_FREQ_26=y cargo run
to check if this way, the compilation is successful.
It is important to note that espflash works flawlessly, it is able to upload the firmware, detecting the crystal clock properly, but the compilation is made with the 40MHz crystal configured, so once that the program is loaded, it outputs a lot of gibberish through the UART port.
Any ideas please let me know, I will work on it.
Thanks in advance,
Manuel.
- Added the following section to the Cargo.toml file:
[package.metadata.esp-idf-sys]
esp_idf_sdkconfig = "sdkconfig"
esp_idf_sdkconfig_defaults = ["sdkconfig.defaults"]
Not necessary, don't do it.
- Added the following lines to sdkconfig.defaults
CONFIG_SOC_XTAL_SUPPORT_26M=y
CONFIG_XTAL_FREQ_SEL=26
CONFIG_XTAL_FREQ=26
CONFIG_XTAL_FREQ_26=y
CONFIG_ESP32_XTAL_FREQ_26=y
CONFIG_ESP32_XTAL_FREQ=26
This ^^^ is what you should be doing, and only that.
- Copied the file sdkconfig.defaults to sdkconfig
Bad idea, don't do it. Do you copy sdkconfig.defaults
over to sdkconfig
in pure C ESP IDF development? I guess, not. Same applies to the Rust world.
- Added the following lines in .carg/config.toml in the [env] section
CONFIG_XTAL_FREQ_SEL = "26"
CONFIG_XTAL_FREQ = "26"
CONFIG_XTAL_FREQ_26 = "y"
Won't do anything.
- Run
CONFIG_XTAL_FREQ_26=y cargo run
to check if this way, the compilation is successful.
Ditto.
It is important to note that espflash works flawlessly, it is able to upload the firmware, detecting the crystal clock properly, but the compilation is made with the 40MHz crystal configured, so once that the program is loaded, it outputs a lot of gibberish through the UART port.
Once you do the above changes to sdkconfig.defaults
, you only might need to do a clean rebuild as in cargo clean
and then cargo build
. That's all.
Other than that, you might want to check if some of the above parameters might affect the bootloader, rather than your main app. In that case, you might have to also flash the bootloader that is built as a side effect from building your main app as well. But other than that, just putting the settings in sdkconfig.defaults
and then doing a clean rebuild (which is also btw just in case) should work.
@ivmarkov already summarized the issue, feel free to check https://docs.esp-rs.org/book/troubleshooting/espflash.html#if-you-are-building-an-esp-idf-sys-based-project too, where it might be worth adding that may require a cargo clean
after changing it.
I think the issue can be closed, feel free to reopen it if the issue is not solved.
I didn't know that a clean build should be done after changing those parameters. Maybe it could be interesting to add that in the link you provided.
Thanks for the effort.
Just created a PR with the changes: esp-rs/book#150
I didn't know that a clean build should be done after changing those parameters. Maybe it could be interesting to add that in the link you provided.
Thanks for the effort.
Can you confirm that a clean build actually solves your issue?
Can you also confirm that some of the CONFIG_ parameters you need actually affect the bootloader? Did you flash the bootloader too?
Hi!
I've managed to make it work, but it took me extra steps.
I was trying to load the binary by using the cargo run
command, but it was still not working with the same issue. Then I tried to load it using espflash
manually, specifying the bootloader as the one that was generated in the target file, and it worked.
I would guess that the default cargo runner does not check the bootloader version. But this is not a problem because the command can be changed at any time.
Nevertheless, I would like to mention that I've updated espflash to the version 3.0 and it stopped working with my board due to timeout, but I rolled back to 2.1.0 and it started to work again. The board is a TTGO LoRa board from AliExpress.
If you point me how to help on that, I could try working on this, but I'm just starting with Rust on ESP32, so I'm a bit lost.
Thanks for all, your work is awesome!
I was trying to load the binary by using the cargo run command, but it was still not working with the same issue. Then I tried to load it using espflash manually, specifying the bootloader as the one that was generated in the target file, and it worked.
You can also use cargo-espflash
which uses the partition-table and bootloader of your esp-idf project, see https://github.com/esp-rs/espflash/tree/main/cargo-espflash#bootloader-and-partition-table
Nevertheless, I would like to mention that I've updated espflash to the version 3.0 and it stopped working with my board due to timeout, but I rolled back to 2.1.0 and it started to work again. The board is a TTGO LoRa board from AliExpress.
If you point me how to help on that, I could try working on this, but I'm just starting with Rust on ESP32, so I'm a bit lost.
Could you please provide more details on the issue? Check if its the same as any of the open issues of espflash https://github.com/esp-rs/espflash/issues, if not, please open an issue. I will happily help you if you want to help us fix it. In fact it would be very very useful as you can reproduce the issue, some of the late issues I cant reproduce them myself so its kinda hard to solve them.