search

esp-rs / esp-idf-template

A "Hello, world!" template of a Rust binary crate for the ESP-IDF framework.
372 stars 43 forks source link

Not able to change XTAL frequency when building the example #200

Closed Mforcen closed 3 months ago

Mforcen commented 3 months ago

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:

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.

ivmarkov commented 3 months ago
  • 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.

SergioGasquez commented 3 months ago

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

Mforcen commented 3 months ago

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.

SergioGasquez commented 3 months ago

Just created a PR with the changes: https://github.com/esp-rs/book/pull/150

ivmarkov commented 3 months ago

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?

Mforcen commented 3 months ago

This afternoon I'll have the time to make all the changes and I'll update you then. Thanks for everything.

El jue, 21 mar 2024, 11:12, ivmarkov @.***> escribió:

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?

— Reply to this email directly, view it on GitHub https://github.com/esp-rs/esp-idf-template/issues/200#issuecomment-2011827246, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEI6424QN3ESIPI7RF7HXDYZKXCRAVCNFSM6AAAAABE6BUEXGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJRHAZDOMRUGY . You are receiving this because you authored the thread.Message ID: @.***>

Mforcen commented 3 months ago

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!

SergioGasquez commented 3 months ago

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.