Re: IDF and ESPTOOL_PY Licence Clarification Request
Posted: Wed Mar 18, 2020 5:56 pm
Thank you. Yes, I've just found a descriptin of the flash upload protocol: https://github.com/espressif/esptool/wi ... l-Protocol
After porting it (mentioned functions, but also those filesystem related) into STM32 project and an attempt to run it with ESP8266 board there are a couple of observations.serial_flash_example_main.c / esp_flash_new_image() is an entry point here. There are just slight defferences between ESP8266 and ESP32 within the protocol and it make sense (as one of next steps when working on the code) to add something like "chip profile" (or the loader_config.h file ?) into the C flash uploader code, so it can work for both chips.
1) some commands are not supported by ESP8266. Those found so far are: CHANGE_BAUDRATE, SPI_FLASH_MD5 . Commenting out the section of the example code works. That's documented on above www page, but taking the STM32 example and using it for ESP8266 (this is what I did) will just not work. Some fine-tinning is just needed.
2) Msg structure - slight differences between ESP8266 vs ESP32:
typedef struct __attribute__((packed))
{
command_common_t common;
uint32_t configuration;
//uint32_t zero; // ESP32 ROM only
} spi_attach_command_t;
typedef struct __attribute__((packed))
{
uint8_t failed;
uint8_t error;
// uint8_t reserved_0; // ESP32 ROM only
// uint8_t reserved_1; // ESP32 ROM only
} response_status_t;
3) Serial Speed = 74800 rather then 115200 ( ESP Crystal Freq = 26 MHz vs 40MHz ) -> good to know, as there may be there may be defferences between board types.
4) STM32 is faster then ESP32, so implementation (part of the code port) of loader_port_serial_read() needs some retry (when polling for a RX data), so it does not exit prematurely.
5) Flash erase command works in the exmple for 4kB file/block, but the function loader_flash_begin_cmd() fails when trying to load ~450kB file. Reason is: the flash erase operation takes just more time for the bigger block, while check_response() exits prematurely with fail status. More retry cycles (longer polling for a response from a chip) makes the function working.
Finally the code upload is reported as pass bo a response for a chip (WOW - some little success finally ), but I have not succeeded to boot from the newly uploaded code yet. It;s possible tehre may be some other trick to do. Kindly please to share hints if any are known.
I appreciate sharing the solution. Making it from scrach (everyone separatelly) would be way harder, and here there is at least some structure almost working "off the shelf", so it shall be able to polish it a little, and it will work finally .
Thanks,
Andrzej
After porting it (mentioned functions, but also those filesystem related) into STM32 project and an attempt to run it with ESP8266 board there are a couple of observations.serial_flash_example_main.c / esp_flash_new_image() is an entry point here. There are just slight defferences between ESP8266 and ESP32 within the protocol and it make sense (as one of next steps when working on the code) to add something like "chip profile" (or the loader_config.h file ?) into the C flash uploader code, so it can work for both chips.
1) some commands are not supported by ESP8266. Those found so far are: CHANGE_BAUDRATE, SPI_FLASH_MD5 . Commenting out the section of the example code works. That's documented on above www page, but taking the STM32 example and using it for ESP8266 (this is what I did) will just not work. Some fine-tinning is just needed.
2) Msg structure - slight differences between ESP8266 vs ESP32:
typedef struct __attribute__((packed))
{
command_common_t common;
uint32_t configuration;
//uint32_t zero; // ESP32 ROM only
} spi_attach_command_t;
typedef struct __attribute__((packed))
{
uint8_t failed;
uint8_t error;
// uint8_t reserved_0; // ESP32 ROM only
// uint8_t reserved_1; // ESP32 ROM only
} response_status_t;
3) Serial Speed = 74800 rather then 115200 ( ESP Crystal Freq = 26 MHz vs 40MHz ) -> good to know, as there may be there may be defferences between board types.
4) STM32 is faster then ESP32, so implementation (part of the code port) of loader_port_serial_read() needs some retry (when polling for a RX data), so it does not exit prematurely.
5) Flash erase command works in the exmple for 4kB file/block, but the function loader_flash_begin_cmd() fails when trying to load ~450kB file. Reason is: the flash erase operation takes just more time for the bigger block, while check_response() exits prematurely with fail status. More retry cycles (longer polling for a response from a chip) makes the function working.
Finally the code upload is reported as pass bo a response for a chip (WOW - some little success finally ), but I have not succeeded to boot from the newly uploaded code yet. It;s possible tehre may be some other trick to do. Kindly please to share hints if any are known.
I appreciate sharing the solution. Making it from scrach (everyone separatelly) would be way harder, and here there is at least some structure almost working "off the shelf", so it shall be able to polish it a little, and it will work finally .
Thanks,
Andrzej