I am trying to upgrade a new NodeMCU devkit 1.0 which came with nodemcu-firmware 0.9.6, to a much newer build. I am using esptool on OS X 10.11.3, following the instructions from http://nodemcu.readthedocs.org/en/dev/en/flash/
I verified that I could connect to the NodeMCU and see the Lua prompt before beginning.
After "successfully" write the new flash:
kirsch$ ./esptool.py --port /dev/cu.SLAB_USBtoUART write_flash 0x00000 nodemcu-dev-8-modules-2016-02-06-03-56-03-integer.bin 0x3fc000 esp_iot_sdk_v1/esp_iot_sdk_v1.4.0/bin/esp_init_data_default.bin
Connecting...
Erasing flash...
Took 1.56s to erase flash block
Wrote 410624 bytes at 0x00000000 in 39.6 seconds (83.0 kbit/s)...
Erasing flash...
Took 0.09s to erase flash block
Wrote 1024 bytes at 0x003fc000 in 0.1 seconds (85.4 kbit/s)...
Leaving...
However, if I reset the chip all I get from the chip at the dreaded (by me) 74880 baud is:
load 0x40100000, len 28292, room 16
tail 4
chksum 0xef
load 0x33333333, len 858993459, room 4
I also tried placing esp_init_data_default.bin at address 0x7c000.
Any help is appreciated!
You should start esptool with a few more command line arguments to make sure it uses the correct SPI flash modes for your v2 devkit 1.0 (confused about those names?). The v2 devkit uses SPI mode DIO, flash size 32mbit and SPI speed 40MHz. That translates to
kirsch$ ./esptool.py --port /dev/cu.SLAB_USBtoUART write_flash -fm dio -fs 32m -ff 40m ...
Related
I am working with
U-boot v2021.10
BeagleBone Black rev C
I've created an uboot.env image with mkenvimage tool from file
loadfromsd=load mmc 0:1 0x82000000 /zImage; load mmc 0:1 0x88000000 /am335x-boneblack.dtb
set_bootargs=setenv bootargs console=ttyS0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait
uenvcmd=setenv auotload no; run set_bootargs; run loadfromsd; printenv bootargs; bootz 0x82000000 - 0x88000000
The problem is in files loading to memory with load cmd in first line.
Full message from start is:
U-Boot SPL 2021.10 (Oct 14 2021 - 20:41:20 -0700)
Trying to boot from MMC1
U-Boot 2021.10 (Oct 14 2021 - 20:41:20 -0700)
CPU : AM335X-GP rev 2.1
Model: TI AM335x BeagleBone Black
DRAM: 512 MiB
ti_sysc target-module#9000: failed to get fck clock
WDT: Started with servicing (60s timeout)
NAND: nand_base: timeout while waiting for chip to become ready
nand_base: No NAND device found
0 MiB
MMC: ti_sysc target-module#7000: failed to get fck clock
OMAP SD/MMC: 0, OMAP SD/MMC: 1
Loading Environment from FAT... OK
<ethaddr> not set. Validating first E-fuse MAC
Net: eth2: ethernet#4a100000, eth3: usb_ether
=> run uenvcmd
4295456 bytes read in 282 ms (14.5 MiB/s)
'ailed to load '/am335x-boneblack.dtb
bootargs=console=ttyS0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait
Kernel image # 0x82000000 [ 0x000000 - 0x418b20 ]
ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree
Actual error is
=> run uenvcmd
4295456 bytes read in 282 ms (14.5 MiB/s)
'ailed to load '/am335x-boneblack.dtb
P.S. My u-boot fails to recognize ${} substitutions properly, and usage of
console=ttyS0,115200n8
bootpartition=mmcblk0p2
set_bootargs=setenv bootargs console=${console} root=/dev/${bootpartition} rw rootfstype=ext4 rootwait
caused and error
syntax error:
rootfstype=ext4 rootwait0n8
this 0n8 was appended after rootwait and shouldn't be there. So I've written this "straight" file without variables.
Thanks to sawdust for info that carriage return character matters and overrides first letter of error msg - I've got an idea that it also matters for path to file in load cmd, and it matters.
If I use space+\r, NOT just \r - everything works fine.
I was able to flash a micropython binary which I'd cross compiled some 6 months ago, and it was working fine. It was built from master branch at that point of time, and I did not save the code, nor the binary.
Today, when I again compiled, the binary is having problem at a point. So I want to revert back to the old binary, only problem is I'm not sure what commitID/build the master was at at that point of time ~6 months ago when my compiled binary which works fine was created.
I do have an ESP which has that binary flashed into it. So I was thinking if there is a way to retrieve the binary from the ESP?
Please let me know if this can be done somehow via ampy, etc..
Or suggest me some workaround. I'm already trying to find out the approximate commit around that time, and would cross compile again, which I'm not sure if would work as expected.
Regardless of which firmware you loaded onto your ESP8266 module (NodeMCU, MicroPython, Arduino, etc.) you can use esptool.py to dump the flash content to a file like so:
./esptool.py -p PORT -b 460800 read_flash 0 0x200000 flash_contents.bin
read_flash is the command, 0x200000 the argument for the upper memory bound (2MB).
For reading the firmware as a BIN file
For reading the firmware as a BIN file you need FIRST to connect correct the FTDI with the pins on the IR module
FTDI to IR Module as follows
FTDI 3.3 V to IR 3.3 V,
FTDI GND to IR GND,
FTDI GND to IR IO0 (flash mode - IMPORTANT otherwise it will not work),
FTDI RX to IR TXD,
FTDI TX to IR RXD
Then run the command (if the COM port is 5 and the name to extract the bin is flash-contents, otherwise you replace them to match your COM and the name you wish to have) – important the baud rate to be 9600
esptool.py -p COM5 -b 9600 read_flash 0 0x200000 flash_contents.bin
Below is the outcome for me (running under python 3.10.2 on windows 11):
PS F:\> esptool.py -p COM5 -b 9600 read_flash 0 0x200000 flash_contents.bin
esptool.py v3.2
Serial port COM5
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying
again...
Connecting...
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
Crystal is 26MHz
MAC: 10:52:1c:f8:b7:c7
Stub is already running. No upload is necessary.
2097152 (100 %)
2097152 (100 %)
Read 2097152 bytes at 0x0 in 2215.2 seconds (7.6 kbit/s)...
Hard resetting via RTS pin...
PS F:\>
Remember the esptool.py -p COM5 -b 9600 read_flash 0 0x200000 flash_contents.bin is for 2MB memory
but it is well run with esptool.py -p COM5 -b 9600 read_flash 0 0x100000 flash_contents.bin for 1MB memory as it was in my IR Module
I reduced the speed of reading the flash memory of my esp8266
460800 for "46080" I took a zero.
and successful
My system is a windows 10
C:\Users\POSITIVO\Downloads\esptool-master\esptool-master>esptool.py -p COM6 -b 46080 read_flash 0 0x400000 flash_contents3.bin
esptool.py v3.0-dev
Serial port COM6
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
Crystal is 26MHz
MAC: 2c:3a:e8:42:b9:f7
Uploading stub...
Running stub...
Stub running...
4194304 (100 %)
4194304 (100 %)
Read 4194304 bytes at 0x0 in 937.7 seconds (35.8 kbit/s)...
Hard resetting via RTS pin...
some words to my system.
Im work on the Xilinx development-board zc706.
The basic example of freertos are running.
Now the question is: How i can boot the application over network?
A freertos application is a bare-metal approach.
Typically a loader like u-boot is been used, but the examples I find, was only for the linux use-case.
Addition:
With the XMD console its possible to load the u-boot in the memory
XMD% source ps7_init.tcl
XMD% ps7_init
XMD% dow u-boot
Processor started. Type "stop" to stop processor
Processor Stop Condition Unknown
Processor Reset .... DONE
Downloading Program -- u-boot
section, .text: 0x04000000-0x040524d7
section, efi_runtime_text: 0x040524d8-0x040524fb
section, .rodata: 0x04052500-0x040650d1
section, .hash: 0x040650d4-0x040650ff
section, .dtb.init.rodata: 0x04065100-0x0406866f
section, .data: 0x04068670-0x0406b31b
section, .got.plt: 0x0406b31c-0x0406b327
section, efi_runtime_data: 0x0406b328-0x0406b3ff
section, .u_boot_list: 0x0406b400-0x0406c71f
section, .rel.dyn: 0x0406c720-0x04077d5f
section, .bss: 0x0406c720-0x040ad29f
Download Progress..10.20.30.40.50.60.70.80.90.Done
Setting PC with Program Start Address 0x04000000
XMD% run
RUNNING> 0
XMD%
The result ist seen with on a com port:
U-Boot 2017.01-00012-g374a838 (May 29 2017 - 17:55:04 +0200)
Model: Zynq ZC706 Development Board
Board: Xilinx Zynq
I2C: ready
DRAM: ECC disabled 1 GiB
MMC: sdhci#e0100000: 0 (SD)
SF: Detected s25fl128s_64k with page size 512 Bytes, erase size 128 KiB, total 32 MiB
*** Warning - bad CRC, using default environment
In: serial#e0001000
Out: serial#e0001000
Err: serial#e0001000
Model: Zynq ZC706 Development Board
Board: Xilinx Zynq
Net: ZYNQ GEM: e000b000, phyaddr 7, interface rgmii-id
eth0: ethernet#e000b000
Hit any key to stop autoboot: 0
Device: sdhci#e0100000
Manufacturer ID: 27
OEM: 5048
Name: SD16G
Tran Speed: 50000000
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 14.5 GiB
Bus Width: 4-bit
Erase Group Size: 512 Bytes
reading uEnv.txt
** Unable to read file uEnv.txt **
Copying Linux from SD to RAM...
reading uImage
** Unable to read file uImage **
Zynq>
Addition:
I have build the FSBL with the flag FSBL_DEBUG:
(Project -> Properties -> C/C++ Build -> Settings -> ARM gcc compiler -> Symbols)
The I build the bin file only with the boot loader partion and put it on the SD card:
Xilinx Tools->Create Boot Image
Addition:
The problem is, that the SDK needs a file with name u-boot.elf. The extention was not there after the build of u-boot.
So now I have a TFTP-Server running on my host and the u-boot find the uEnv.txt file, but the cmd in this file doesn't run:
How I can setup the u-boot an give the right loadAddress to loadthe freeRTos elf-file?
The tftpboot cmd seems to be:
tftpboot [loadAddress] [bootfilename]
e.g.
tftpboot 0x80400000 vlm-boards/14726/uImage
What is the load address of the zc706 board?
Addition:
The connection an the download with the TFTP-server seems to work:
But after starting with the "go" cmd a reset occur.
Zynq> setenv ipaddr 192.168.150.101
Zynq> setenv netmask 255.255.255.0
Zynq> setenv gatewayip 192.168.150.1
Zynq> serverip=192.168.150.100
Zynq> ping 192.168.150.100
Using ethernet#e000b000 device
host 192.168.150.100 is alive
Zynq> tftpboot 0x8000 FreeRTOS_HelloWorld.elf
Using ethernet#e000b000 device
TFTP from server 192.168.150.100; our IP address is 192.168.150.101
Filename 'FreeRTOS_HelloWorld.elf'.
Load address: 0x8000
Loading: ###############
2.8 MiB/s
done
Bytes transferred = 205675 (3236b hex)
Zynq> go 0x8000
## Starting application at 0x00008000 ...
undefined instruction
pc : [<0000fa60>] lr : [<3ff443c4>]
reloc pc : [<c40cda60>] lr : [<040023c4>]
sp : 3eb20cf4 ip : 0000001c fp : 3ff4437c
r10: 3eb1f9b0 r9 : 3eb21ee8 r8 : 3ffaef30
r7 : 00000000 r6 : 00008000 r5 : 00000002 r4 : 3eb2f9b4
r3 : 00008000 r2 : 3eb2f9b4 r1 : 3eb2f9b4 r0 : 00001084
Flags: nZcv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
resetting ...
Thx in advance
The solution is:
The Xilinx SDK supply as an output an Elf-File, which the u-boot understands:
tftpboot 0x000000 FreeRTOS_ZC706_HelloWorld.elf
bootelf 0x0
Thanks
tftpboot 0x0 hello.efl; bootelf 0x0;
works in Uboot 2019.2 version and FreeRTOS.elf.
For the other core, you need to convert it to bin format using arm-none-eabi-objcopy -O binary hello.elf hello.bin. tftpboot it under the correct memory postion. And fire it up in the CPU0 code.
I am trying to get the latest version of NodeMCU firmware working on my ESP8266 ES-12 module. I have followed the following steps with v1.5.4.x and it seems to be working just fine. Here are the steps:
Erase the flash esptool.py --port /dev/cu.usbXXXX erase_flash
Flash init data esptool.py --port /dev/cu.usbXXXX write_flash -fm dio -fs 32m 0x3fc000 esp_iot_sdk_v2.1.0/bin/esp_init_data_default.bin
Flash the actual build files esptool.py --port /dev/cu.usbXXXX --baud 115200 write_flash -fm dio -fs 32m 0x00000 0x00000.bin 0x10000 0x10000.bin
When I boot, I encounter the following after a file system format message
Got answer! Communication with MCU established.
AutoDetect firmware...
Can't autodetect firmware, because proper answer not received (may be unknown firmware).
Please, reset module or continue.
l��r��c�n�����p�|����x��ǒ��p
�nn��;�n�����b�$rrp�n�������l���b�n��n���쎟
�p��nn�����l`���#�n��{nr���;����rp�n����r���pp��<��
���p��nn���r��#�n�$�l`�8`rn|��n����l`9~����#�n�$���nn���l`nn����r��l�pp��<����b��<~�n����l`�n��Ìrnr���;����{r�ےn����l`�����x�n��>r���n�b��lrb�������l�|��n���l`�<r�x��l`#�r����8��� #�r����8���0��lrr��;l�Ğb����bp�b��l��p����l�x~�n�nܒ��r���l���l��������l�{�n��ܒ��b�l���8�b�>��ܒ��b�|�rr�
Formatting file system. Please wait...
ets Jan 8 2013,rst cause:4, boot mode:(3,6)
wdt reset
load 0x40100000, len 26772, room 16
tail 4
chksum 0x93
load 0x3ffe8000, len 2432, room 4
tail 12
chksum 0x74
ho 0 tail 12 room 4
load 0x3ffe8980, len 136, room 12
tail 12
chksum 0x67
csum 0x67
csum err
ets_main.c rl��r��c�n�����p�|����x��ǒ��p�nn��;�n�����b�cl`$`nn�������l���b�n��n���쎟�p��nn�����l`���#�n��{nr���;��?��rp�n����r���pp��<�����p��nn���r��#�n�$�l`�8`rn|��n����l`;~����#�n�$���nn���l`nn����r��l�pp��<����b��>~�n����l`�n��Ìrnr���;����{r�ےn����l`�8���;�b�Ē`$��r���wn��bp�
Like I mentioned before, following the exact same steps for v1.5.4 worked absolutely fine and I get a proper lua prompt after the file system is formatted. What am I missing here? Any help would be appreciated.
I have used spiffsimg to create a single file containing multiple lua files:
# ./spiffsimg -f lua.img -c 262144 -r lua.script
f 4227 init.lua
f 413 cfg.lua
f 2233 setupWifi.lua
f 7498 configServer.lua
f 558 cfgForm.htm
f 4255 setupConfig.lua
f 14192 main.lua
#
I then use esptool.py to flash the NodeMCU firmware and the file containing the lua files to the esp8266 (NodeMCU dev kit):
c:\esptool-master>c:\Python27\python esptool.py -p COM7 write_flash -fs 32m -fm dio 0x00000 nodemcu-dev-9-modules-2016-07-18-12-06-36-integer.bin 0x78000 lua.img
esptool.py v1.0.2-dev
Connecting...
Running Cesanta flasher stub...
Flash params set to 0x0240
Writing 446464 # 0x0... 446464 (100 %)
Wrote 446464 bytes at 0x0 in 38.9 seconds (91.9 kbit/s)...
Writing 262144 # 0x78000... 262144 (100 %)
Wrote 262144 bytes at 0x78000 in 22.8 seconds (91.9 kbit/s)...
Leaving...
I then run ESPLorer to check the status and get:
PORT OPEN 115200
Communication with MCU..Got answer! AutoDetect firmware...
Can't autodetect firmware, because proper answer not received.
NodeMCU custom build by frightanic.com
branch: dev
commit: b21b3e08aad633ccfd5fd29066400a06bb699ae2
SSL: true
modules: file,gpio,http,net,node,rtctime,tmr,uart,wifi
build built on: 2016-07-18 12:05
powered by Lua 5.1.4 on SDK 1.5.4(baaeaebb)
lua: cannot open init.lua
>
----------------------------
No files found.
----------------------------
>
Total : 3455015 bytes
Used : 0 bytes
Remain: 3455015 bytes
The NodeMCU firmware flashed correctly, but the lua files can't be located.
I have tried flashing to other locations (0x84000, 0x7c000), but I am just guessing at these locations based on reading threads on github.
I used the NodeMCU file.fscfg() routine to get the flash address and size. If I only flash the NodeMCU firmware I get the following:
print (file.fscfg())
524288 3653632
534288 is 0x80000, so I tried flashing only the spiffsimg file (lua.img) to 0x8000, then ran the same print statement and got:
print (file.fscfg())
786432 3391488
The flash address incremented by the exact number of bytes in the lua.img - which I don't understand, why would the flash address change? Is the first number returned by file.fscfg not the starting flash address, but the ending flash address?
What is the correct address for flashing an image file, contain lua files, that was created by spiffsimg?
The version of spiffsimg found here will provide the correct address for flashing an image file that contains lua files.
Do not use this version of spiffsimg as it is out of date.
To install the spiffsimg utility, you need to download and install the entire nodemcu-firmware package (into a linux environment, use make to install - note: make on my debian linux box generated an error, but i was able to go to the ../tools/spiffsimg subdirectory and run make on the Makefile found in that directory to create the utility).
The spiffsimg instructions found here are quite clear, with one exception: the file name you specify, with the -f parameter, needs to include the characters %x. The %x will be replaced with the address that the image file should be flashed to.
For example, the command
spiffsimage -f %x-luaFiles.img -S 4MB -U 465783 -r lua.script
will create a file, in the local directory, with a name like: 80000-luaFiles.img. Which means you should install that image file at address 0x80000 on the ESP8266.
I've never done that myself but I'm reasonably confident the correct answer can be extracted from the docs.
-f specifies the filename for the disk image. '%x' will be replaced
by the calculated offset of the file system.
And a bit further down
The disk image file is placed into the bin directory and it is named
0x<offset>-<size>.bin where the offset is the location where it
should be flashed, and the size is the size of the flash part.
However, there's a slight mismatch between the two statements. We may have a bug in the docs. If "'%x' will be replaced..." then I'd expected the final name won't contain 0x anymore.
Furthermore, it is possible to define a fixed SPIFFS position when you build the firmware.
#define SPIFFS_FIXED_LOCATION 0x100000
This specifies that the SPIFFS filesystem starts at 1Mb from the start of the flash. Unless
otherwise specified, it will run to the end of the flash (excluding
the 16k of space reserved by the SDK).