MCUSR always reports 0 at startup

[smdg49]

MCUSR register always reports zero at startup. There is no way to debug what caused the last reset. ATMEGA328p Used to work properly in previous versions (I am not sure which was the last though) thanks for Minicore!!

[MCUdude]

Are you using a bootloader, and if yes, Urboot?

[smdg49]

Bootloader ->yes (uart0)

On Tue, Mar 12, 2024, 3:11 AM Hans @.***> wrote:

Are you using a bootloader, and if yes, Urboot?

— Reply to this email directly, view it on GitHub https://github.com/MCUdude/MiniCore/issues/289#issuecomment-1990921212, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANXRDUJNJWDCWP66Y7A2OYDYX2TB5AVCNFSM6AAAAABEQUDW2CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJQHEZDCMRRGI . You are receiving this because you authored the thread.Message ID: @.***>

[MCUdude]

OK, and you're using the latest MiniCore version?

[MCUdude]

It's most likely caused by the Urboot bootloader. However, the bootloader stores the reset cause in the R2 register. @stefanrueger do you have a proof of concept code snippet to read R2?

[smdg49]

Yes

On Tue, Mar 12, 2024, 7:50 AM Hans @.***> wrote:

OK, and you're using the latest MiniCore version?

— Reply to this email directly, view it on GitHub https://github.com/MCUdude/MiniCore/issues/289#issuecomment-1991472172, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANXRDUK2CXHYQC4QJFSXYF3YX3TW3AVCNFSM6AAAAABEQUDW2CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJRGQ3TEMJXGI . You are receiving this because you authored the thread.Message ID: @.***>

[smdg49]

Do you mean general purpose register 2?

On Tue, Mar 12, 2024, 8:16 AM Hans @.***> wrote:

It's most likely caused by the Urboot bootloader. However, the bootloader stores the reset cause in the R2 register. @stefanrueger https://github.com/stefanrueger do you have a proof of concept code snippet to read R2?

— Reply to this email directly, view it on GitHub https://github.com/MCUdude/MiniCore/issues/289#issuecomment-1991517615, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANXRDUMUKVWJKVFITKH5VTTYX3WZVAVCNFSM6AAAAABEQUDW2CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJRGUYTONRRGU . You are receiving this because you authored the thread.Message ID: @.***>

[MCUdude]

Yes, see the Urboot documentation: https://github.com/stefanrueger/urboot

I have not tried it myself.

[stefanrueger]

Urboot puts the MCUSR into the processor register R2 (not the general purpose register 2), which means it must be read before the compiler does any initialisation. Below code copies it into the user-chosen variable cpmcusr.

// This variable in .noinit will not be initialised by avr-gcc's init code
uint8_t cpmcusr __attribute__ ((section(".noinit")));

// Copy r2 into global variable; needs to be done quite early on, hence choosing init0 here
void savemcusr(void) __attribute__ ((naked)) __attribute__ ((section (".init0")))  __attribute__ ((used));

void savemcusr(void) {
  __asm__ __volatile__ ("sts %0, r2\n" : "=m" (cpmcusr) :);
}

Urboot first keeps a copy of MCUSR in R2 and then clears MCUSR. The urboot bootloader gets invoked on external reset and normally hands over control to the application using the watchdog reset. So, you will see watchdog rather than external reset when pressing the reset button on your board. Also note that, unless you have a very clean way of powering on the device or switched off the brown-out detection, normally you will see brown-out reset rather than power-on reset.

[smdg49]

Thanks for the response. I used to be able to do byte mcusr=MCUSR; MCUSR=0; Wdtdisable(): to prevent constant resetting.

I was also able to detect wether it was a external reset or wdt.

I was definitely using minicore and I must have had some bootloader since I was able to program using tx rx gnd reset rather than ICSP.

What changed? Did minicore have a different bootloader in the past? What changed

On Tue, Mar 12, 2024, 9:56 PM Stefan Rueger @.***> wrote:

Urboot puts the MCUSR into the processor register R2 (not the general purpose register 2), which means it must be read before the compiler does any initialisation. Below code copies it into the user-chosen variable cpmcusr.

// This variable in .noinit will not be initialised by avr-gcc's init code uint8_t cpmcusr attribute ((section(".noinit")));

// Copy r2 into global variable; needs to be done quite early on, hence choosing init0 here void savemcusr(void) attribute ((naked)) attribute ((section (".init0"))) attribute ((used));

void savemcusr(void) { asm volatile ("sts %0, r2\n" : "=m" (cpmcusr) :); }

Urboot first keeps a copy of MCUSR in R2 and then clears MCUSR. The urboot bootloader gets invoked on external reset and normally hands over control to the application using the watchdog reset. So, you will see watchdog rather than external reset when pressing the reset button on your board. Also note that, unless you have a very clean way of powering on the device or switched off the brown-out detection, normally you will see brown-out reset rather than power-on reset.

— Reply to this email directly, view it on GitHub https://github.com/MCUdude/MiniCore/issues/289#issuecomment-1993092564, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANXRDUK3R5K2BMKIE425T7LYX6W6FAVCNFSM6AAAAABEQUDW2CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJTGA4TENJWGQ . You are receiving this because you authored the thread.Message ID: @.***>

[stefanrueger]

Before Minicore switched to urboot it was using the optiboot bootloader, which has an ambition to preserve the reset causes in the MCUSR as much as possible. This requires quite a few bytes of code in the bootloader. The urboot project doesn't see the ability to distinguish external reset from WDT reset (other than caused by the bootloader itself) as a core requirement: it prefers to spend the limited code space on other features such as autobaud detection, EEPROM r/w etc.

Best to switch to Optiboot for your requirements, @smdg49, or not use a bootloader at all (in which case you are not at mercy what it does with MCUSR). See also this discussion from 2015 when optiboot showed the same MCUSR behaviour as urboot does now.

[smdg49]

Got it. I think it WAS optiboot. Would I lose the ability to upload through rx tx if without bootloader?

On Wed, Mar 13, 2024, 12:14 AM Stefan Rueger @.***> wrote:

Before Minicore switched to urboot it was using the optiboot bootloader, which has an ambition to preserve the reset causes in the MCUSR as much as possible https://github.com/Optiboot/optiboot/issues/140. This requires quite a few bytes of code in the bootloader. The urboot project doesn't see the ability to distinguish external reset from WDT reset (other than caused by the bootloader itself) as a core requirement: it prefers to spend the limited code space on other features such as autobaud detection, EEPROM r/w etc.

Best to switch to Optiboot for your requirements, @smdg49 https://github.com/smdg49, or not use a bootloader at all (in which case you are not at mercy what it does with MCUSR). See also this discussion from 2015 https://github.com/Optiboot/optiboot/issues/97 when optiboot showed the same MCUSR behaviour as urboot does now.

— Reply to this email directly, view it on GitHub https://github.com/MCUdude/MiniCore/issues/289#issuecomment-1993427127, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANXRDULGQ2HKKYCJFZ4IVPDYX7HAVAVCNFSM6AAAAABEQUDW2CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJTGQZDOMJSG4 . You are receiving this because you were mentioned.Message ID: @.***>

[MCUdude]

Would I lose the ability to upload through rx tx if without bootloader?

Yes, you will.

[smdg49]

K. Thank you

On Wed, Mar 13, 2024, 6:27 AM Hans @.***> wrote:

Would I lose the ability to upload through rx tx if without bootloader?

Yes, you will.

— Reply to this email directly, view it on GitHub https://github.com/MCUdude/MiniCore/issues/289#issuecomment-1994053714, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANXRDUNPLZ4NGYF33DS6Y7TYYAS2XAVCNFSM6AAAAABEQUDW2CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJUGA2TGNZRGQ . You are receiving this because you were mentioned.Message ID: @.***>