Mcucsr: 2.0.8.6 - Does not work, 2.0.8.5 - ALL OK

Alexander-Dan · Joined: 13 Mar 2014 Posts: 111 Location: S.Posad

Hi all!

How can you find out about the reason for the restart in the version 2.0.8.6 of the BASCOM?
I've read the "change history" but don't understand how to apply this information.

This is a simple example. If power is supplied, the red LED lights up, if there is another reason for the restart, the green LED lights up.

The example does not work in the version 2.0.8.6.
But in the old version 2.0.8.5 everything is fine.

albertsm · Joined: 09 Apr 2004 Posts: 5922 Location: Holland

check the config watchdog help.

Alexander-Dan · Joined: 13 Mar 2014 Posts: 111 Location: S.Posad

Mark, I read it of course

I'll change the question: when exactly in the code do I need to read the state of the register?
at what point will the register be cleared by the initialization procedure?

I need the porf bit only, not the watchdog bit

ps
Maybe someone will suggest another method of saving the Mcucsr register before starting the initialization procedure?

albertsm · Joined: 09 Apr 2004 Posts: 5922 Location: Holland

you must do this as soon as possible. in your code.
one way is using $initmicro

also , you say it works in 2085 but that is either a coincidence or not true since it was changed long time ago.

one thing that changed in 2086 : - mcucr register was not properly cleared at start up for old AVR processors. only the WD flag was reset, notice you should not write a 0, since some AVR have other unrelated bit flags in the MCUCR register! processors like that will have an additional mask in the dat file : WD=MCUCSR.WDRF,$E0

so some times, a fix means different behavior. you could rename the DAT file and remark that line if you want the old incorrect behavior.
without this additional mask, the compiler would first save the register in R0 then write a 0 to mcucsr. but while for many chips that is not a problem, some old chips have some other bits in mcucsr.
for those it will perform an AND with the mask to clear just the bits 0-4.
But in all cases the register is saved in r0

only the mask is new in 2086 to fix writing a 0 to other unrelated bits.
you will see that not all DAT files have this.

albertsm · Joined: 09 Apr 2004 Posts: 5922 Location: Holland

beside all that your code is wrong too.
you must not reset mcucsr to 0. the compiler already does that for you.

Alexander-Dan · Joined: 13 Mar 2014 Posts: 111 Location: S.Posad

Thank you. I'll try different options.

The code was copied from projects that I have been using for more than 9 years... Smile

I will report the test results later.

albertsm · Joined: 09 Apr 2004 Posts: 5922 Location: Holland

but i do not think these projects were using 2085?
anyway since the first version of bascom-avr the compiler clears the watchdog flags, since otherwise a processor could hang.
only later the register was saved in r0 to allow the user to do something with the info if needed.
and only in 2086 for some processors a fix was made not to clear the entire register (like you do in your code) but to clear just the power reset registers.
but it was never needed to clear mcucsr yourself.
your code must be very old.

Alexander-Dan · Joined: 13 Mar 2014 Posts: 111 Location: S.Posad

2.0.8.1 and oldest version of Bascom.

albertsm · Joined: 09 Apr 2004 Posts: 5922 Location: Holland

even in 2075 saving mcucsr into r0 existed.

your code never worked since mcucsr was cleared before your code executed.

Alexander-Dan · Joined: 13 Mar 2014 Posts: 111 Location: S.Posad

Mark,
I don't want to argue with you.

I have been using this method for a long time and successfully.
First I organize the variable, then I read into the status register variable.
And only in the new version I got the problem.

I use analysis of the reason for the launch to create a hidden method for entering the system menu. I usually check the bit and button press. If power is applied and the button is pressed, the device setup mode is activated.

I really don’t want to disable initialization, it’s easier for me to go back to the old version, since I don’t use new chips

Alexander-Dan · Joined: 13 Mar 2014 Posts: 111 Location: S.Posad

I am attaching two files: 2086 and 2085.
You can upload it to MK and check it yourself.

Alexander-Dan · Joined: 13 Mar 2014 Posts: 111 Location: S.Posad

I checked this option. Yes, reading data from the register R0 solved this problem.

MWS · Joined: 22 Aug 2009 Posts: 2262

In regards of ATM16, where I've checked, there is a difference between 2.0.8.5 and 2.0.8.6 with the effect, that BORF, EXTRF, PORF in MCUCSR is not reset in 2.0.8.5 and can be evaluated.
This has changed in 2.0.8.6, there these three flags get cleared.

Alexander-Dan · Joined: 13 Mar 2014 Posts: 111 Location: S.Posad

thank you for analyzing the code, MWS
I haven’t used assembler for a long time and I was too lazy to look at the codes obtained from different versions of the compiler using a disassembler.
Thanks again for the analysis!

MWS · Joined: 22 Aug 2009 Posts: 2262

No problem.
As far as I remember there was always the rule to read MCUSR/MCUCSR not directly, but by fetching R0.
It worked for you by chance till 2086.002, history.txt gives a hint there for MCUCR.
Previously MCUCSR was AND-ed with &hF7, after with &hE0, which had the effect you did observe.