hi,
in my sketch I want to distinguish between pwr-on-reset and all other resets.
Here in the forum I found postings about Optiboot bootloader which can do this.
But here come my questions:
Thanks in advance for tipps
You could write a signature into RAM. If the power went down, it will be erased. If not, the reset line or other cause reset the processor, but the signature will still be in RAM.
I hope you're not initiating reset in order to fix some intermittent problem...
1. This is (Fig-1) the "Power-on Reset Circuit" of ATmega328P at conceptual level.
Figure-1:
2. This is the brief description of the functioning of the circuit of Fig-1.
The Vcc supply starts rising from 0V at time t0. At Vcc = 1.4V (called VPOT = Power-on Reset Threshold at rising), the ‘Power-on Reset Circuit (POR)’ triggers and generates the pulse, Qa. As a result, the PORF (Power-on Reset Flag) of MCUCSR register assumes LH-state indicating that an Internal Power-on Reset (start-up) has occurred. The POR circuit can also be used to detect a failure in ‘Vcc Power Supply’ and in this case the detection threshold is VPOT = 1.3V.
The Qa pulse triggers the ‘Delay Counter’, which waits for ‘Time-out’ period to reset the FF1. As a result, the MCU gets a time equal to ‘Time-out’ for the reset of the internal logic and start-up.
Using Megacore and Optiboot makes problems:
I could not find a download page for Optiboot only.
Therefore I first installed Megacore and then with Megacore selected, loaded a bootloader. I suppose that then Optiboot had been loaded.
My setup() starts with:
void setup()
{
uint8_t *ptr;
uint8_t rs_reg;
Serial.begin(9600);
while(!Serial);
rs_reg=MCUSR;
Serial.print(F("MCUSR=0x"));Serial.println(rs_reg,HEX);
...
... and then runs a test program for a LCD display.
For testing I pressed the reset button.
For a second test I used the watchdog:
void setup()
{
uint8_t *ptr;
uint8_t rs_reg;
wdt_disable(); // watchdog ausschalten
wdt_reset();
Serial.begin(9600);
while(!Serial);
rs_reg=MCUSR;
Serial.print(F("MCUSR=0x"));Serial.println(rs_reg,HEX);
Serial.println(F("Paint.ino"));
Serial.print(F("watchdog:!"));
wdt_enable(WDTO_2S);
while (1);
With the initial configuration (without Megacore and without Optiboot) the content of MCUSR was printed as 0x0, no matter what type of reset occurred.
The LCD test program runs ok.
With Megacore and Optiboot MCUSR is printed as 0x7, no matter what type of reset occurred.
But the LCD test program does not run.
The combinations
Final result:
There is a difference between standard boot loader and Optiboot concerning content of MCUSR.
Both loaders don't pass MCUSR to the sketch.
Now I will try the first tip with a signature in RAM.
The joy of being able to access MCUSR is that you also must reset it, or it’s results will be cumulative...
westfw:
- Your 2560 does NOT have Optiboot unless you’ve installed it. (The default is a different bootloader)
- You’ll need to get a recent version of optiboot to have the MCUSR pass-through support. I recommend MCUDUDE’s “megacore “
I want to interpret MCUSR after a reset, per the OP, and am trying to use the code here:
https://github.com/Optiboot/optiboot/blob/master/optiboot/examples/test_reset/test_reset.ino
However, I'm having problems and would appreciate guidance.
My target is an old Mega 2560 with the original bootloader and its attendant problems, so per (1) above I upgraded it using IDE 1.8.12 > Tools > Burn Bootloader (via another Mega acting as Arduino ISP). This 'works' and avoids the WDT loop problem in the original bootloader.
However, when using test_reset to check on MCUSR values, I have two problems:
Item (2) of the quoted text suggests I might need to use a different version of Optiboot, but I thought the latest IDE already made use of v7, which includes the R2 passthru. So I'm lost as to why test_reset is acting the way it is.
Any ideas?
I upgraded it using IDE 1.8.12 > Tools > Burn Bootloader (via another Mega acting as Arduino ISP). This 'works' and avoids the WDT loop problem in the original bootloader.
yes, but it still uses stk500boot for the Mega2560 bootloader.
- I can't seem to update MCUSR ("New MCUSR content" is always 0x0)
MCUSR can't be "updated", it can only be "cleared." That's why there are so many complications in the first place.
- I only ever get R2 showing "0x80 Unknown"
That's probably because you're not using Optiboot...
Item (2) of the quoted text suggests I might need to use a different version of Optiboot, but I thought the latest IDE already made use of v7, which includes the R2 passthru.
No, the IDE is still "stuck" on v4.4 of Optiboot, but ONLY FOR THE PLATFORMS THAT USE OPTIBOOT, which does NOT include the MEGA2560.
I recommend MCUDUDE's "megacore" (still. Again.)
Thanks for that - ninja skills clearly needed!
Is there a guide that helps us mere mortals? I had read the following to mean I could use Optiboot on the 2560:
pert:
Optiboot 8.0 does support ATmega2560:
Add generic support for devices with more than 128KB flash, and atmega2560 by majekw · Pull Request #159 · Optiboot/optiboot · GitHub
. . which was further supported by the comments against Optiboot here, which implies that the 'fix' has been merged into Optiboot: Add generic support for devices with more than 128KB flash, and atmega2560 by majekw · Pull Request #159 · Optiboot/optiboot · GitHub
However, what I'd missed was that the IDE doesn't/can't use Optiboot for the 2560 
I will try Megacore as you suggest - and as I also found, here:
pert:
If you want to go the easy way you can use this hardware package:
GitHub - MCUdude/MegaCore: Arduino hardware package for ATmega64, ATmega128, ATmega165, ATmega169, ATmega325, ATmega329, ATmega640, ATmega645, ATmega649, ATmega1280, ATmega1281, ATmega2560, ATmega2561, ATmega3250, ATmega3290, ATmega6450, ATmega6490, AT90CAN32, AT90CAN64 and AT90CAN128
which uses the same variant of optiboot as in the above link, but with Majekw's flash write feature added also.Just install via Boards Manager, select the correct board, then Tools > Burn Bootloader.
BTW - I thought one of the features of test_reset was to update MCUSR - eg
MCUSR = ch & 0xF;
printReset("\nNew MCUSR content: 0x", MCUSR);
. . or did I miss something?
I thought one of the features of test_reset was to update MCUSR - eg
MCUSR = ch & 0xF;
That SHOULD end up clearing the low 4 bits of MCUSR. It's one of those "write ones to clear bits" registers.
what I'd missed was that the IDE doesn't/can't use Optiboot for the 2560
AND the IDE doesn't use the most recent Optiboot for anything.
While it's frustrating to have worked on Optiboot for the last several years now and not have the changes "accepted" by the Arduino team, I also understand that change is risk, and that for most users, the changes to Optiboot are not relevant. (most chips, easier compilation?)
A substantial part of what I do to Optiboot is review other peoples' improvements, and make risk/benefit decisions on whether those go into the Optiboot repository. It took quite a while to get the MCUSR stuff to where it is now, and I'm still not sure that it's perfect...
While it's frustrating to have worked on Optiboot for the last several years now and not have the changes "accepted" by the Arduino team
Despite that, a lot of people are still getting the use of the modern Optiboot, especially via the MCUdude/hansibull and DrAzzy/SpenceKonde platforms.
Here's an example from this week of someone benefiting from being able to use Optiboot on an ATmega32 courtesy of MightyCore:
A bit of griping about the IDE, but not a word of complaint about the bootloader! No mention of it in the Hackaday article, but you could consider it a good sign that we don't really even need to think about Optiboot. It just works on all the AVR chips we love, all the time. Thanks for all the great work you've done on this!
the changes to Optiboot are not relevant.
I think the ATmega2560 support would probably be the most noticeable improvement to the average Arduino user, but of course some will argue that the extra 7 kB of flash you can save by switching to Optiboot is not so much in demand. I certainly like to have it available in case I should find a use for it. A jump from 248 kB to 255 kB of available flash is still pretty significant!
a lot of people are still getting the use of the modern Optiboot, especially via the MCUdude/hansibull and DrAzzy/SpenceKonde platforms.
Yep. I'm really happy about that. And the Arduino team deserves some (a lot of) credit for doing such a good job on the "board manager" and 3rd party Hardware platform support in general.
"We won't do but has it" is usually fine...
I was very inspired to see all the work they did back in the Arduino IDE 1.5 and early 1.6 days to enable 3rd party platform developers, especially since many of those platforms are for products in direct competition with Arduino's offerings. That was when I was just getting started with trying to contribute to the project and it really motivated me in that.
They opened up Boards Manager.
They made a nice system for referencing resources from other platforms. Arduino doesn't even have any use for that referencing feature in their own platforms, but it is super useful for making minimal custom platforms.
They only have a couple of boards that use a single custom boards menu, but the 3rd party platforms have used the heck out of that feature.
In addition to being the right thing to do for the good of the Arduino project as a whole, I believe this is and will be the right choice from a business standpoint in the long term.
(I actually saw a comment on another forum, one that usually has mostly bad things to say about the Arduino IDE, that the Arduino Board and Library Managers were "noticeably better than some others.")
If you want a simple way for Mega with Optiboot, you can define your boards in hardware folder like I do
one of "my boards" is Arduino Mega with Optiboot