Whenever I need to upload the bootloader to my Arduino Mega (ATMEGA2560) I use an AVRISP MKII with the fuses/lock bits described in boards.txt file. Doing this I am able to burn arduino sketches by serial connection with my FTDI.
My question is: is it possible to burn arduino sketches (.hex files) with the AVRISP but keeping the bootloader? Whenever I try to do that (I use the same avrdude command I use to program the bootloader but changing the bootloader .hex file to the sketch .hex file) I am no longer able to program the processor with FTDI (and then I need to program the bootloader again).
I think (of course I can be wrong) this problem occurs due to the fuse and lock bits settings that cannot be the same as those used to program the bootloader.
This is the fuse settings I use (from boards.txt file under Arduino folder)
mega2560.name=Arduino Mega 2560 or Mega ADK
mega2560.upload.protocol=wiring
mega2560.upload.maximum_size=258048
mega2560.upload.speed=115200
mega2560.bootloader.low_fuses=0xFF
mega2560.bootloader.high_fuses=0xD8
mega2560.bootloader.extended_fuses=0xFD
mega2560.bootloader.path=stk500v2
mega2560.bootloader.file=stk500boot_v2_mega2560.hex
mega2560.bootloader.unlock_bits=0x3F
mega2560.bootloader.lock_bits=0x0F
mega2560.build.mcu=atmega2560
mega2560.build.f_cpu=16000000L
mega2560.build.core=arduino
mega2560.build.variant=mega
Can you help me?
Thanks in advance.
Some controllers like the AT*X*MEGA series support individual flash sections that can be programmed/erased independently. However, with the ATMEGA2560 this is not possible.
One way would be to concatenate the .hex files as part of the build process. This can be achieved with some modifications to the makefile.
Something similar to this
all: $(TARGET).hex
srec_cat bootloader.hex -intel $(TARGET).hex -intel -o combined.hex -intel
Flashing the ´combined.hex´ would then include both, main application and boot loader. There is a related discussion on AVRFreaks.
Regarding the fuses, you just have to make sure that the boot loader (address) stays configured as the entry point.
EDIT: You can use this fuse bit calculator to verify fuse settings. Select your device and make sure "Boot Reset vector Enabled (default address=$0000); [BOOTRST=0]" is enabled with your current high fuse value.
You currently use
mega2560.bootloader.high_fuses=0xD8
so that seems fine.
Related
The ESP32 flash command, as executed by the Arduino IDE, seems to flash two bootloader files: boot_app0.bin at offset 0xe000 and bootloader_dio_80m.bin at offset 0x1000. I wonder what these two bootloader files actually do, and why there are two of them. Below I give some more information.
1. Context
I'm part of a team developing a new, free IDE for microcontrollers: Embeetle IDE. We're planning to support the ESP32 microcontroller family in the near future. Therefore, I'm now studying the ESP32 build system - both the ESP-IDF tool and the Arduino IDE approach to ESP32 projects.
2. Arduino IDE flash procedure for ESP32 projects
After building the .elf file, the Arduino IDE launches a command to convert it into a binary:
python esptool.py --chip esp32 elf2image
--flash_mode dio
--flash_freq 80m
--flash_size 4MB
-o /tmp/arduino_build_852524/WiFiScan.ino.bin
/tmp/arduino_build_852524/WiFiScan.ino.elf
Finally, this WiFiScan.ino.bin file is flashed to the board, alongside two bootloader files and the partitions table:
python esptool.py --chip esp32
--port /dev/ttyUSB0
--baud 921600
--before default_reset
--after hard_reset write_flash
-z
--flash_mode dio
--flash_freq 80m
--flash_size detect
0xe000 ~/.arduino15/packages/esp32/hardware/esp32/1.0.6/tools/partitions/boot_app0.bin
0x1000 ~/.arduino15/packages/esp32/hardware/esp32/1.0.6/tools/sdk/bin/bootloader_dio_80m.bin
0x10000 /tmp/arduino_build_852524/WiFiScan.ino.bin
0x8000 /tmp/arduino_build_852524/WiFiScan.ino.partitions.bin
The default partitions table, as used by Arduino IDE, looks like this (in csv format):
# Name, Type, SubType, Offset, Size, Flags
nvs, data, nvs, 0x9000, 0x5000,
otadata, data, ota, 0xe000, 0x2000,
app0, app, ota_0, 0x10000, 0x140000,
app1, app, ota_1, 0x150000,0x140000,
spiffs, data, spiffs, 0x290000,0x170000,
The binary equivalent of this csv-file gets flashed to address 0x8000. There are also two bootloader files being flashed to addresses 0xe000 and 0x1000 respectively (see next paragraph).
3. Bootloader files
The two bootloader files being flashed are:
# flashed at 0xe000
~/.arduino15/packages/esp32/hardware/esp32/1.0.6/tools/partitions/boot_app0.bin
and:
# flashed at 0x1000
~/.arduino15/packages/esp32/hardware/esp32/1.0.6/tools/sdk/bin/bootloader_dio_80m.bin
Question 1: What do these two bootloader files do?
It's also interesting to observe their locations. The first one, boot_app0.bin is located in a folder named 'partitions'. It sits there alongside several partition .csv files. Why? But maybe that gets clear when Question 1 is answered.
The other one, bootloader_dio_80m.bin is located in a folder named 'sdk/bin/' and sits alongside other files that all start their name with the 'bootloader_' prefix:
Question 2: As for the bootloader file flashed at address 0x1000, I think the '_40m' and '_80m' suffixes stand for the flash speed in MHz. But I've no idea what the '_dio', '_dout' and '_qout' suffixes stand for.
Please enlighten me ^_^
Answer
Thanks to #Juraj, I now get a better insight into the startup procedure of an ESP32 chip. I believe it looks like this:
FIRST STAGE BOOTLOADER:The hardwired ROM-bootloader runs first. This first stage bootloader is outside the Flash memory and cannot be programmed. It loads the second stage bootloader (see next step).
SECOND STAGE BOOTLOADER:The first stage ROM-bootloader loads the second stage ESP-IDF Software bootloader at address 0x1000 in Flash. The code here is the bootloader_dio_80m.bin executable, which can be found in the components/bootloader directory of the ESP-IDF framework.
This second stage bootloader reads the partition table found by default at offset 0x8000. If OTA app partitions are found in the partition table, the bootloader consults the ota_data partition to determine which one should be booted.
BOOT SWITCHThe ota_data section can be considered as merely a switch, located at 0xe000 in Flash. It determines if either app0 or app1 should boot. The switch itself is the boot_app0.bin binary. As Juraj says, the 2kB size is also used to take notes during OTA flashing.
APPLICATIONThe application at app0 or app1 executes.
Thank you also for pointing me at these resources:
ESP32 bootloader
ESP32 startup procedure
The binary at 0x1000 is the bootloader. Arduino ESP32 has bootloader binaries corresponding to boards options in Tools menu in Arduino IDE (built from boards.txt).
The bootloader functions are documented here.
The ESP-IDF Software Bootloader performs the following functions:
Minimal initial configuration of internal modules;
Initialize Flash Encryption and/or Secure features, if configured;
Select the application partition to boot, based on the partition table and ota_data (if any);
Load this image to RAM (IRAM & DRAM) and transfer management to it.
The boot_app0.bin is the OTA data partition initial content. It is documented here.
The OTA data partition is two flash sectors (0x2000 bytes) in size, to prevent problems if there is a power failure while it is being written. Sectors are independently erased and written with matching data, and if they disagree a counter field is used to determine which sector was written more recently.
DIO, QIO, DOUT, QOUT are SPI modes for the flash memory. Different esp32 modules have different flash memory chips and their connection. (D is double, Q is quad)
I am working on a fresh arduino mega rev3 device.
I want to understand how it works and i need to disassemble flash memory dump.
I have seen that bootloader starts at address 0x3E000
What i want to know now is where does the main program starts in memory.
Thanks
Where the bootloader starts (if it's used) depends on fuse settings. If you have compact bootloader, you can use smaller BOOTSZ. If you're using ICSP header for uploading user program, you don't even need bootloader at all.
Anyway, program starts at 0x0000 on this chip.
I have an Arduino Uno and I am using arduino 1.0.5 IDE. I followed he procedures for bootloading an atmega328P-PU on a breadboard.
I uploaded the ArduinoISP sketch first, made the connections(using the External Oscillator) and then wired it up. Then, I selected the programmer as Arduino as ISP, selected the board as Arduino duemilanove w/ Atmega328P. Then I selected the correct serial port and clicked Burn Bootloader.
I got the following errors:
avrdude.exe: stk500_program_enable(): protocol error, expect=0x14,
resp=0x50avrdude.exe: initialization failed, rc=-1 Double
check connections and try again, or use -F to override
this check.avrdude.exe: stk500_disable(): protocol error, expect=0x14,
resp=0x51
How to solve this issue? Also, can I upload the bootloader directly by using it on the Uno in place of the original chip. If so, how?
to my understanding the error you have indicates a bad reading from the chip. I experienced that with chips that were either dead or not properly connected, especially to power supply.
You may find more detailed information in th tutorial : https://www.arduino.cc/en/Tutorial/ArduinoISP
Especially those things :
Note for Arduino 1.0: you need to make one small change to the
ArduinoISP code. Find the line in the heartbeat() function that says
"delay(40);" and change it to "delay(20);".
Select the items in the
Tools > Board and Serial Port menus that correspond to the board you
are using as the programmer (not the board being programmed).
Instead of arduino built-in boot loader just go through below link and it will be great for uploading boot loader and verifying board status info
I am replying you this because same issue I got long back and it saved me.
One more thing for arduino boot loader: for atmega328 you need to put capacitor between reset and gnd( in case you missed)
For gammon bootloader you don't need it.
Be Innovative.
For reset line you might me using 100nf(thats what stated in documentation )...but sometimes it doesn't work...try something like 4.7uf, 22uf or 47uf or close values
I had a similar problem and the issue was that my programmer was a bit slow, I used the -B flag for avrdude to slow down the bitrate and it started working, I set the -B20 and works like a charm every time, but I use the USBTinyISP programmer, not the stk500 one, so this might not work for you.
In case someone stuck at this as I did and nothing like changing the cap value helped. Make sure you are using your USB-TTL adapter in a 5v mode (obviously for a 5v powered chip). I always used it in a 3.3v mode in order not to accidentally burn my 3.3v chips and it always worked. Until today, I was trying to flash my custom atmega8 board and everything worked with the ISP but I was having a hard time using the bootloader and after half a day searching and trying different stuff the 5v setting to the rescue.
Using arduino UNO(mac) i am trying to upload boot loader to the atmega328 where the chip is on a bread board, and connected to the UNO board tx-tx, rx-rx, vcc,gnd ,reset .
So i am trying to upload a boot loader by adding to the boards.txt file the atmega on a breadboard 8mhz , and choose it from boards menu.
than when i try to burn boot loader he says after 0 seconds :
did not find any USB device "usb"
than i change the programmer from - AVR ISP mkii to- AVR ISP
it starts then, and after 6-7 seconds of try he fails saying:
programmer is not responding
I dont know what am i doing wrong, i have also tried with a oscillator,or without it, nothing works.
maybe the fact that its a mac has todo with it ?
To access that portion of memory you need to use the arduino as an ISP (in-system programmer).
The use of USB to program an arduino chip is enabled by the bootloader you are trying to put on.
The usual way is to program a chip directly is using an ISP.
Have a look at the setup here:
http://arduino.cc/en/Tutorial/ArduinoISP
Another good resource for an advanced build is this:
How to Build an AVR Development Board: http://youtu.be/ncobWc61wL4
He explains what he is doing as he goes so it is really easy to follow and he talks about the programming process.
I downloaded several software that provide virtual COM ports. These COM ports do appear in the Device Manager and can be selected for upload from the Arduino IDE, menu Tools -> Serial Port -> COM3. It starts uploading and reaches 90% and then it either times out or just does nothing.
I want to upload onto the virtual COM port so I could then read the compilation output files in another program. I don't want to use my Arduino at all, and I don't want to manually get the verbose output files when uploading. This problem doesn't happen when I upload on the real Arduino.
The application should work on all platforms. This task seems easy on Linux, and I am facing the stated problem on Windows and any help with Mac would also be useful.
The application will be an educational tool for hardware simulation and visualization trying to give a more hands-on experience for users than other simulators out there. So may be this will give you an idea of why I want to do so.
How can I get started?
I think you might be assuming that uploading code to Arduino is one-way communications: this would be like putting strawberries in a blender, and a Daquiri comes out. If that was true, you could just take whatever the IDE dumps to the serial port, save it to a file, and you have an Arduino binary. (Skip to TL;DR if not interested in details. Upshot: this assumption is not correct).
The 1-way communication assumption is not entirely correct: there is a program on the Arduino (called "a bootloader") which is responsible for communicating with the programmer ("programmer": a program that programs the Arduino, assume it is the Arduino IDE for now). In their most "natural" state, the Arduino CPUs cannot be programmed across serial lines. Rather these chips are programmed either via the in system programming (ISP) or via the JTAG protocol. The bootloader is a program that runs on an Arduino CPU and loading of sketches/programs over the serial port. This program runs at startup and looks for programming commands over the serial port.
If it discovers that a programmer is trying to communicate programming information, it will read the compiled Arduino binary coming over the serial link, store it in flash memory, send it back to over the serial link for verification, and if everything is successful, exit and launch the stored sketch. If no programming information appears on the serial port, that is, no programmer is trying to write a new sketch, then the bootloader simply quits and launches the program already stored in flash.
TL;DR: In order to implement a pseudo-Arduino on your serial port you must write a program some code that simulates an Arduino (bootloader) on the other end of your virtual serial port. So when a programmer/IDE says to Arduino "are you there?" your program will respond "yes!", just like an Arduino would.
The default Arduino bootloader is STK-500 compatible: that means that it implements STK-500 commands - the reference for which can be found here. If you decide to do this, then the easiest thing might be to start with an existing bootloader, such as Arduino's or AdaFruit's (there are others too), and modify it. Such a bootloader would have all the commands already implemented, and since it is written in C (I wouldn't choose an assembly bootloader to modify :), it should be easy enough to modify.
Alternatively, you might decide that STK-500 is too difficult to implement. If this is the case, you can use any programmer protocol that Avrdude supports: Avrdude is a program for programming AVR chips, and Arduino IDE uses Avrdude internally to send the sketch to the Arduino. If you do this, then you'd have to change the settings in Arduino IDE for which programmer you are using.
Personally, I think STK-500 compatible is the best option for this, but YMMV.