I'm using an ATmega328p microcontroller with the optiboot bootloader.
Optiboot is configured to flash a "start LED" for 3 times when optiboot is running.
Fuse bits are set for a bootloader section of 256 words and BOOTRST is programmed to jump into the bootloader section at start-up.
With the bootloader installed, I flash the actual firmware via the UART (pin 30 and 31) and that all works fine.
Now to my question:
When my firmware is running and I pull the reset line of the atmel to GND, I can see the "start LED" flash 3 times and then the firmware execution starts. This tells me that the bootloader run right after the reset.
However, when I start-up the atmel (supply power to the chip), I do not see the "start LED" flash 3 times and the firmware code seems to be executed right away.
Does anyone have an idea why optiboot flashes the "start LED" after pulling the reset line to GND and not when I power-on the chip?
The reset line is directly connected with a 10k pullup to the supply voltage of the atmel.
I hope someone has an explanation and any help is much appreciated.
i think it's relevant ,
"On reset, Optiboot starts and reads the reset reason from MCUSR. For any cause other than "external reset", the application is started immediately. Otherwise, optiboot attempts to download new application software"
Related
Overview
I need to program a recently purchased STM32F407ZGT6 board
In 'normal mode' my computer doesn't recognizing the board as a Ports (COM & LPT)/STMElectronics Virtual COM Port when connected via USB (I'm using a Windows 10 Pro). The LEDs turn on and I can get it into 'DFU mode'. When I try to debug the code, I get the "No ST-LINK detected!" message in either mode.
This is my first time connecting the board and also my first time dealing with STM32
Despite the instructions, I want to program the board using C directly from the STM32CubeIDE
Here is what I found
I found this question [1] where Device Manager reads the STM as Disk drives/STM32. My PC identifies it as mass storage and portable devices on Windows 10 Pro. When in DFU mode, I can see it as Universal Serial Bus Device/STM32 BOOTLOADER on Device Manager.
The tutorial [2] uses Flash Loader Demo and this older tutorial [3] uses STSW-STM32080, but both of the drivers are tagged as obsolete on the ST Website. STM32CuberProgrammer is indicated instead, but I would like to flash and debug directly from the IDE. Another forum reply [4] says that "you need a ST-link V2 programmer to program the brand new chip".
In summary
I can see the solution being one of the following options:
correct answer I need to use the ST-LINK-V2 to program from the IDE and that's the only way
I need to flash a bootloader via STM32CubeProgrammer to get it to work via IDE (is there a standard code for this?)
I have to build the cross-compiler for MicroPython [5] before I get to program it in C
What are your thoughts? Any other driver or idea that I might be missing?
Update
I went on and got my hands on a ST-LINK V2. I made the connection via the JTAG/SWD connector (see schematic) and I also tried connecting directly with the pins:
ST-Link
JTAG/SWD
Pins
SWCLK
9
PA14
SWDIO
7
PA13
GND
10
GND
3.3V
1
3.3V
RST
3
PB4
The ST-Link is not recognized. The ST-Link blinks and the board is powered up, but that's it. Device manager before and after shows the same.
So I went on checking if I was missing any new driver/program. I installed the STSW-LINK004 (STM32 ST-LINK Utility v4.6.0.0) based on these instructions, but no luck, Utility cannot find it either. I've reseted the computer after each driver installation. If I connect my boardvia USB in DFU mode, it is still recognized as STM32 BOOTLOADER, if I do it with the ST-Link, nothing changes.
Update solution
It turned out the ST-Link was faulty and therefore not connecting. After finding another ST-LINK/V2, the computer can recognize the board under Universal Serial Bus devices/STM32 STLink.
Debugging with STM32CubeIDE will always need an ST-LINK or other JTAG or SWD debug probe.
The bootloader allows you to program the microcontroller with a binary image, and that's it. The IDE will happily produce such a binary image, and possibly even have a wizard for transferring it via DFU. But that's only programming, no debugging And only be when the bootloader is running. If you did debug-like things like reading RAM contents, you'd get what the bootloader stores there while it is running, not the variables that your own program uses.
The ROM bootloader supports several ways of receiving new code to flash -- USB (DFU), CAN, I2C, SPI, UART. That last is not a USB Virtual COM port, it is honest-to-God UART using the USART peripheral in the microcontroller and RX/TX pins.
If you want a virtual COM port for your custom firmware to use to send data to the PC, you have to program the USB peripheral.
So, I programmed an ATMEGA32u4 and when I connect the device, it doesn't run the code. Instead, it gets recognised as an ATMEGA32u4 chip in Windows device manager.
To get the code running I have to open Atmel FLIP and open USB and then have to press the start application button after which it gets recognised as a HID in device manager and works as intended. I don't know why and what is happening.
The reset is pulled high with a 10k and the HWB is pulled down with a 10k and the chip has the factory bootloader on it.(if this helps)
Pulling down HWB is what you do if you want to start the bootloader built into the ATmega32U4. It sounds like you want to run your own code instead of running the bootloader so you should pull HWB up, or disable the HWBE fuse.
I have an ESP32 board with GPIO0 connected to ground through a switch. The idea is that if I press the button and issue an ESP.restart() the board would get into flash mode.
Instead, ESP.restart() just restarts the app, ignoring GPIO0 state.
Is it possible to force the whole boot process, maybe with a direct JMP to the HW reset vector?
According to Ivan Grokhotkov
On ESP32 there are 3 reset reasons which cause strapping GPIOs to be sampled: power-on, RTC WDT reset, brownout reset.
So in terms of code, see below. If the pin is strapped it will never get out of the bootloader which will be waiting for a sync on serial.
#include "soc/rtc_wdt.h"
void hardReset() {
rtc_wdt_protect_off(); //Disable RTC WDT write protection
//Set stage 0 to trigger a system reset after 1000ms
rtc_wdt_set_length_of_reset_signal(RTC_WDT_SYS_RESET_SIG, RTC_WDT_LENGTH_3_2us);
rtc_wdt_set_stage(RTC_WDT_STAGE0, RTC_WDT_STAGE_ACTION_RESET_SYSTEM);
rtc_wdt_set_time(RTC_WDT_STAGE0, 10000);
rtc_wdt_enable(); //Start the RTC WDT timer
rtc_wdt_protect_on(); //Enable RTC WDT write protection
}
A better solution is that not using firmware update mode for programmatically software updates, use it only for only bootloader updates. Split your code into two-part bootloader and logical program part.
To update your logical program part, your bootloader should handle burning the remaining addresses except for the bootloader. (Your bootloader code can burn any address on the microcontroller, filesystem libraries do that) So don't try to switch into firmware update mode which is available for whole firmware updates. The more advanced solution is using OTA update features as possible as.
In this way, you guarantee that you always have the bootable device in the field, which is ready to update any corrupted logical part. Any mistake during burning the bootloader in the field may cost your device shipment.
I am new in this. Bought Atmega8a mcu to have some fun with it. But I am unable to program it using arduino uno rev-3. Haven't used any external parts to program it. Just connected the chip as below:
Arduino pin 10 to chip pin rst,
Pin 11 to MOSI,
Pin 12 to MISO,
Pin 13 to SCK,
Connected vcc and gnd to chip pin 7 & 8,
Also used an 10 uf cap, arduino rst to gnd.
Trying to upload the bootloader using arduino ide 1.6.9. It says:
avrdude: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override this check
Am I missing something?
Most minimal AVR setups include a 10k pull-up resistor on the reset pin. Are you sure you don't need one?
Arduino target cpu (or variant) must be ATMega8A.
"Invalid signature" is not so verbose - it says nothing. Enable verbose log for avrdude in Arduino setting.
If signature is slightly different from actual one, it's selected variant problem.
If it's something like 0xFF or 0x00 it's usualy wiring, reset or missing xtal problem.
Bootloader needs correct xtal/resonator (AVR runs from internal 8MHz clock and it's divided by factor 8 by default, but after flashing bootloader it'll be set to crystal oscilator - depends on target/variant)
Remove cap from RST, it might be slowing down reset and cause invalid reading
Currently there's no arduino board with atmega8a as the main microcontroller.
You forgot about pins 20 and 22 -- you must connect them to VCC and GND even if you're not going to use ADC.
EDIT:
Ad. 1. It would be possible to add support for atmega8a to arduino ide, by modifying hardware/arduino/avr/boards.txt file and compiling a bootloader for atmega8a.
I have an arduino uno R3. I am able to upload the programs with no connectivity issues. But there is a problem while executing the program and I don't know what that is. The 13th pin led is not blinking as the default bootloader program comes with preloaded blink program. I am not able to reset the board too. What might be causing the problem?
I even tried to reload the bootloader program. But the same think happens yet again.
Thanks in advance and Regards,
Rishi.
Have you tried to blink one led with pin 2 or 3 ( any of the digital pins ). You might have a working Arduino uno but your led on the board can be broken.
Otherwise,you should try to flash the bootloader with a secondary arduino and check if you get the same issue.