I have defined data partition storage, data, spiffs, , 12M, and linked my data folder to it using the spiffs_create_partition_image cmake command. The IDE uploads spiffs filesystem to the flash chip inside the module each time I click run in the IDE.
Can I do the same to spi nor flash chips outside of the esp32 module?
Related
so when I connect my development board (NUCLEO-f446re) to my laptop , everything is working normally , but there is only one thing that confuses me , see the next picture
windows recognize my development board as external storage device with 1.52 MB size (partition named NODE_F446RE(E:))
when I open it , the next image show what I see
there is only 2 files there , the .HTM file takes me to this link and the .TXT file has the follow content:
Version: V2J40M27
Build: May 5 2022 13:16:48
so I don't understand what does this mean ?, like what does 1.5MB storage represent in my MCU even though , the flash size of my MCU is only 512 KB which is way less than the shown storage , also what happens if I put any .exe file in that partition ?
From the web page you link (emphasis by me):
USB re-enumeration capability: three different interfaces supported on USB
Virtual Com port
Mass storage (USB Disk drive) for drag'n'drop programming
Debug port
Your board offers the option to program your application. Simply drap and drop the bin (binary) file of the application into this drive.
It is "just" a virtual drive, the software behind it does the flashing for you, if it receives a binary file.
Why the size of the drive is bigger than the available flash memory, is not clear. Perhaps to allow for necessary overhead to mimic a file system, and to have room for the files you see.
If you copy an exe file in it, I'd expect some kind of error message. Or that the file will not be stored. Experiment!
This functionality is perhaps not well documented, but is part of the "Mbed Enabled" functionality. It is a feature of the Mbed bootloader, to allow "drag'n'drop programming" via a "fake" mass storage device in order to avoid the need for special programming tools or protocols.
You can write to the device, but the "file" will not appear in the filesystem, rather the content will be used to program the on-chip flash memory.
The files on the fake drive are read-only - mbed.htm will open in a browser and take you to the Mbed sign-up/login where you can start developing using Mbed. details.txt contains details of the mbed firmware pre-loaded on the board.
At one time the Mbed on-line/in-browser IDE lacked hardware programming and debug capability, so this feature was the primary means of programming Mbed boards, and debugging was painful. I believe all that has changed now and the feature is perhaps less important in development.
https://os.mbed.com/platforms/ST-Nucleo-F446RE/
I have created a custom code for ESp32 in Arduino IDE. I flashed the program directly from IDE using UART with the help of TTL. I'm looking for an alternative method to flash the firmware of ESP32.
I'm trying to flash the esp32 binary file generated from Arduino IDE, using the flash downloader tool.
https://www.espressif.com/en/support/download/other-tools
I have used the configuration settings as follows
This settings flashed the firmware and the board reset worked perfectly. The SPIFFS did not however work.
Please find the log attached.
Also attached the reset log after flashing for reference
Thanks for the help.
Problem
I'm looking for a way to flash an ESP32 module's memory without installing the whole IDF software suite.
Why
Because I want to integrate ESP32 onto a custom board along with a low-performance ARM-powered CPU which runs a tiny Linux distro (based on Debian), and I want to flash ESP32 from this tiny Linux distro.
I know I could use the bootloader, but who will upload the initial bootloader? I don't want to do extra steps, so my idea is to embed the ESP32 module onto my custom board, and let the Linux to flash it from factory-state (when it's flash is empty, ie. no preloaded bootloader). Or is the serial bootloader always preinstalled on all ESP32 modules (like on ESP-WROOM-32)?
Why I don't want to use IDF? Because I don't want to build or debug anything, I just want to flash myprogram.bin onto ESP32. Also, as the board is low-performance, it would take ages to download everything for running IDF.
Current state
The ESP32 module is now visible via UART (RX,TX,GND), and if I held low the GPIO0, it runs the bootloader (my current module is embedded onto a NodeMCU - but there is no USB connected, this is raw UART!):
rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download
Could I expect the same behavior (controlling GPIO0 for running the bootloader) for all ESP32 modules, or this works just because guys at NodeMCU preprogrammed already some bootloader onto it?
I'm looking for a way to flash this ESP32 preferrably without any python script.
The ESP32 has a first-stage bootloader in ROM capable of writing to Flash - that's what's printing your output. You can talk to it if you know the protocol - this is implemented by the Python scripts in ESP IDF. If you don't want to use the official implementation because it's too heavy, you'll have to write your own implementation of this protocol which scratches your specific itch. Fortunately it's more or less documented and you can likely reverse engineer any missing knowledge from official Python scripts.
Actually Espressif also provides a nice and small binary for flashing ESPs:
https://github.com/espressif/esp-serial-flasher
Serial flasher component provides portable library for flashing Espressif SoCs (ESP32, ESP32-S2, ESP8266) from other host microcontroller. Espressif SoCs are normally programmed via serial interface (UART). Port layer for given host microcontroller has to be implemented, if not available.
One more (but very important) addition:
You have to modify this repo to make it work correctly, and also you might have to upload not just your binary, but also bootloader and partition_table.
I compiled the xilinx pcie driver using this as a starting point.
https://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules
and then instead of using this to the prebuilt image:
MACHINE_EXTRA_RRECOMMENDS += "kernel-module-mymodule"
I copy kernel file .ko directly to the image as:
fs#fs:/opt/PHYTEC_BSPs/yocto_imx7/build/tmp/work/cortexa7hf-neon-poky-linux-gnueabi/met/0.1-r0$ scp xpcie.ko root#172.17.100.101:/lib/modules
then when I insert this kernel module with hardware connected:
root#imx7d-phyboard-zeta-001:/lib/modules# insmod /lib/modules/xpcie.ko
Base hw val 0
Base hw len 0
BAR0 of 0K
BAR0 of 0M
xpcie: Init: Could not remap memory.
insmod: ERROR: could not insert module /lib/modules/xpcie.ko: Operation
not permitted
root#imx7d-phyboard-zeta-001:/lib/modules#
What is the reason?
Is it not allowed to copy kernel directly on already built image like this?
Futhermore when I add it to the image as in local.conf file:
MACHINE_EXTRA_RRECOMMENDS += "kernel-module-mymodule"
again built and load the image, it is not available in /lib/modules/ directory. Where i can find it? or using other 3 methods will be better?
Using insmod to install the driver is the right thing to do. It does not seem to be the cause of the problem you are seeing.
When you build the driver, the .ko file will usually be in the source directory where you built it, unless you make modules_install.
Getting back to the actual problem:
Looking at the driver source, the message "Could not remap memory" indicates that the driver could not map the PCIE memory region into the kernel address space.
Looks like the base address registers were not configured. On all the machines I use, the BIOS has to configure the base address registers before Linux can use the device.
We program the FPGA, reboot the machine, and then load the driver and use the FPGA. Did you try this? Does your FPGA show up with lspci?
Once the FPGA is programmed, if the PCIE configuration does not change you can tell the kernel to rescan and it will write the base address registers with the same values.
I am having a question regarding Uboot. I am looking forward to make a ARM based Board.
Now i want to to burn Uboot to NAND flash attached to my controller. How can i perform this operation ?
http://www.stlinux.com/u-boot/target-install
What i got from this link is that -- STx7111 Mboard - have some serial port which is capable to communicate with GDB.
And from GDB we use to burn following file u-boot. Is this file burned in RAM or NAND flash by gdb ?
Then execution moves to this u-boot program "u-boot". Now this program "u-boot" will burn the actual u-boot.bin onto the NAND flash.
Do every controller have some serial port which is capable to communicate with GDB ?
Do every controller follow this approach to burn uboot bootloader into its NAND flash ?
Please suggest.
What i got from this link is that -- STx7111 Mboard - have some serial port which is capable to communicate with GDB. And from GDB we use to burn following file u-boot. Is this file burned in RAM or NAND flash by gdb ?
No, you did not read that article accurately.
GDB is merely used as the interface to the JTAG.
This first step is to load an executable (a copy of U-Boot) into RAM.
Do every controller have some serial port which is capable to communicate with GDB ?
Do every controller follow this approach to burn uboot bootloader into its NAND flash ?
You should avoid making (or trying to make) sweeping generalizations (in this and your other postings).
The features and capabilities of microcontrollers, microprocessors and SoCs ("controllers" is something else) is so broad that very few generalization can be made. Rarely is there only "one way" to perform these procedures.
In order the write a copy of U-Boot (or any file image) to NAND flash, there are two steps:
transfer the image file from the host PC (or some storage device) into local memory;
erase the NAND flash blocks, and then write the image file to NAND flash with ECC if required and cognizant of bad blocks.
These are not trivial steps, so a capable utility is needed. There are at least three approaches:
The microcontroller can be configured (via input pins) to a "receive and write an image file" mode on power-up. A hardcoded program in ROM will load the image and write it to the integrated flash.
The SoC ROM has a bootloader that has capabilities to communicate with a host PC over RS232 or USB, and can perform as the client side of a proprietary utility program. On the host PC you would run the server side of this utility program. This scheme would allow transferring files and reading & writing the target's memories. Atmel's SAM-BA utility fits into this category.
Use an open-source utility, such as U-Boot, that is configurable and extensible to support the external NAND flash and any other memory types on your board, and also has file transfer capabilities. The console for U-Boot is typically a UART/USART serial port, but can be configured to use a USB-to-RS232 adapter.
In the case of using a program like U-Boot to install programs in NAND, a chicken versus egg situation arises: how to get this program loaded in the first place? The two common approaches are:
a. Install the utility (i.e. U-Boot) on a SDcard with any required bootloader, and then boot the SoC from the SDcard. This assumes that the SoC has this booting capability, but this scheme requires the least operator skill.
b. Load the utility (i.e. U-Boot) using JTAG, such as Segger J-Link, which will allow you to transfer the image file to RAM (assuming that RAM has been properly initialized if necessary) and then start its execution. The J-Link can be interfaced using its own JLINK program or GDB.
Once U-Boot is resident and executing, you have all of its capabilities available. U-Boot cannot write itself to NAND flash, so you have to load another copy of U-Boot in order to write it to NAND (or any other type of) flash.
If you load something using GDB, then it must be loaded in RAM..
Using gdb you will run that binary (u-boot), and the binary will give you the u-boot prompt, which you use to burn another image (it can be u-boot.img (configured for running from FLASH), linux kernel image, or any other image) into the flash (it can be NOR or NAND)..