- Tue Sep 23, 2014 12:20 am
#855
That was the option in esptool.py I was referring to
Code: Select all
Download an image to RAM and execute
- Tue Sep 23, 2014 2:46 am
#856
OK, the almost free option to load a firmware into RAM and execute from it has been added to the "esptool.py" script, but I have no clue how you can generate a firmware that execute from RAM directly, you probably need to play with either function attributes, #pragma directives or linker script.
But anyway, to use this feature you need to enter into bootloader mode by toggling GPIO0, so it doesn't solve the problem.
But anyway, to use this feature you need to enter into bootloader mode by toggling GPIO0, so it doesn't solve the problem.
- Tue Sep 23, 2014 3:06 am
#857
Does the SoC execute code directly off the SPI Flash? Sorry for my lack of knowledge , but on other SoCs/MCU usually the bootloader copies the code to the RAM where it runs then -> often called DRAM in the linker scripts , where 'D' stands for 'Data' and not 'Dynamic'
AFAIK from the LX Docs the LX106 does the same (No fancy MMU or whatever)
I will definitley look into getting some sort of GPIO0 toggling into Devboard Rev2 (if it ever comes to it...)
GPIO0 has to be in a defined state (LOW) at startup of the ESP , toggling isn't necessary to get into UART boot mode.
But It would be handy to controll the state by software and not by a jumper.
I have this points on my Rev2 ToDo list now :
Anything else? And thanks for your valuable input so far Squonk
Squonk wrote:... but I have no clue how you can generate a firmware that execute from RAM directly, you probably need to play with either function attributes, #pragma directives or linker script.
Does the SoC execute code directly off the SPI Flash? Sorry for my lack of knowledge , but on other SoCs/MCU usually the bootloader copies the code to the RAM where it runs then -> often called DRAM in the linker scripts , where 'D' stands for 'Data' and not 'Dynamic'
AFAIK from the LX Docs the LX106 does the same (No fancy MMU or whatever)
I will definitley look into getting some sort of GPIO0 toggling into Devboard Rev2 (if it ever comes to it...)
GPIO0 has to be in a defined state (LOW) at startup of the ESP , toggling isn't necessary to get into UART boot mode.
But It would be handy to controll the state by software and not by a jumper.
I have this points on my Rev2 ToDo list now :
Controlled impendance of all RF traces
FTDI can toggle the GPIO0 line (Might need an EEPROM for the FTDI to get RTS into a defined state at FTDI startup)
Some LEDs on certain GPIOs for more visual feedback
Anything else? And thanks for your valuable input so far Squonk
- Tue Sep 23, 2014 4:09 am
#859
No, the CPU probably won't execute code off the SPI Flash directly, but it looks like there is a magic cache that maps the SPI Flash contents to IRAM address space, however we still don't know how this is taking place exactly.
But if you look at the example code, there are some "ICACHE_FLASH_ATTR" attributes on some functions, apparently to put these into the ".irom0.text" section?!?
Regarding GPIO0, when I say "toggling", this is hust that you have to pull it high or low, depending if you want to boot from Flash or go into bootloader mode.
I don't think you need an EPROM for the FTDI chip:
http://www.ftdichip.com/Support/Documen ... pdf#page=8
http://www.ftdichip.com/Support/Documen ... df#page=46
As the RTS# pin is Z-state when the FTDI chip is held in RESET, then the 2 channels of the FT2232H reset to 2 asynchronous serial interfaces, and my guess is that RTS# is set to its inactive state (high) by default, so all you have to do is to put a pull-up resistor on the RTS# output to make sure it is high by default when nothing drives it, thus forcing the ESP8366 into SPI Flash boot mode.
But if you look at the example code, there are some "ICACHE_FLASH_ATTR" attributes on some functions, apparently to put these into the ".irom0.text" section?!?
Regarding GPIO0, when I say "toggling", this is hust that you have to pull it high or low, depending if you want to boot from Flash or go into bootloader mode.
I don't think you need an EPROM for the FTDI chip:
http://www.ftdichip.com/Support/Documen ... pdf#page=8
http://www.ftdichip.com/Support/Documen ... df#page=46
As the RTS# pin is Z-state when the FTDI chip is held in RESET, then the 2 channels of the FT2232H reset to 2 asynchronous serial interfaces, and my guess is that RTS# is set to its inactive state (high) by default, so all you have to do is to put a pull-up resistor on the RTS# output to make sure it is high by default when nothing drives it, thus forcing the ESP8366 into SPI Flash boot mode.
