Fuse bits are not set correctly

[weedogt]

I have reported this bug several times already. Each time I have been told that "we will ask the developers to fix it" but nothing has happened. I actually reported the problem the first time in 2011. This is a mail from support dated 13th of October 2011.

Indeed, there are discrepancies between the fuse bit settings in the compiler and AVRFlahs software.
I apologize for this inconvenience, I will inform our developers regarding this issue.

Regards,
---

Filip Jankovic
mikroElektronika [Support Department]

Ticket Details
===================
Ticket ID: MJC-876167
Department: Support Department
Priority: Normal
Status: Closed

I use microBasic Pro v6.0.1 and AVRFLASH v2.14 on a Windows 7 machine.

The problem is that the settings of the programming fuses is tranferred incorrectly to AVRFLASH





Please fix this issue.

[darko.minic]

Hi,

Thank you for reporting bug. Indeed bug still exists.
I will report this behavior again to our Developers.
We are very sorry for inconvenience.

Regards,
Darko

[weedogt]

I just downloaded 6.1.0. Guess what? the bug is still there. How long does it take to fix a bug? It has been almost 4 years now...

[darko.minic]

Hi,

I will forward this bug again to our Development Team with a remark that bug is reported before almost 4 years.

We are very sorry for any inconvenience you have.

Regards,
Darko

[weedogt]

And today I downloaded ver 6.1.1. The bug is still there.

I don't understand how you guys think. Don't you fix known (since 4 years) bugs? I mean, either you say this product is end of life. That's fine, products don't live forever. Or you say it's active. And if a product is active you fix bugs, right?

[Aleksandar.Mitrovic]

Dear weedogt,

We are aware of this problem with wrong fuse bits in AVRFlash.

Unfortunately this is well known problem which is still on our to do list.

Best regards,
Aleksandar

[Hayato_U]

I downloaded mikroC PRO for AVR Ver 7.0.2 and AVRFlash Ver.2.2
The bug is still there.

When are you fixing bugs?

[Johnny Janssens]

Hello to all,
Dear Darko and/or Aleksandar,

Last week, January 2020, we where the victim of this bug, a batch of SMD controllers (soldered into the PCB) was destroyed by setting the wrong flags, although they where correctly set in the development software, they did not (correctly) transferred to the programmer software.
Since they became un-programmable, they must be replaced, what a shame...

Today I leaned, in this conversation, that this bug exits already since October 2011, that is now more than 8 years ago.
How is this possible? A bug of this kind should get fixed in shorter time!

I do not want to complain too much about this nice software, because it functions really very good.
But a bug like this should be fixed a lot faster!!!
Any idea in which "century" this will get fixed?

Anyway, kind regards, Johnny

[Johnny Janssens]

Hello To All,

Not much replies to this problem here...

Since, apparently, this bug will not be fixed by MikroE, we tried to solve the problem in another way, noticing that one may create a configurable "tool" on the toolbar, we created an executable program that accepts the project's path, reads the source files of that project, and creates the correct command with all necessary parameters to start the AVRFlash programmer, this time with the correct settings for the fuses (as they should have been originally).
After this program was completed, tests showed that the programmer performs correctly with the given -FUSE: parameter (so the problem is situated into the compiler, that does not forward the correct fuses to the programmer).

Then we added our program to the tools bar (through the setup window), and also this functioned correctly...as long the compiler stays open...
Unfortunately, after closing the compiler and opening it again, the tools icon disappeared again, although the setup window still shows the correct settings for that tools icon, but the button stays hidden.
So now we bumped onto a second bug, that makes "our solution" to fix that first bug...useless, so back to square one...

Besides this, we also noticed before that the calculated configuration registers (Fuse bits) are incorrect in the configuration window for the ATTINY841 controller, also the values stored into the .cfg file are incorrect, and needs to be corrected manually.
Granted, this is a rather new controller, so this bug was probably not yet noticed.

So at the end we run into three bugs within only one project, none the less we are still impressed about this software.
We still hope that those bugs will be fixed within a reasonable time, it should not take more than 8 years...

Kind regards,
Johnny

[Johnny Janssens]

Hello,

Still no reply about these bugs after several days, is there no support at all for these (since long time known) bugs?
Did this software somehow became orphanware or abandonware? It seems so, very pity...
This lack of support makes the software rather unreliable and useless for future projects.

Regards.

[filip]

Hi,

I apologize for the late reply.

I have been monitoring this topic since you wrote your first post, and have been in contact with our managers and development team regarding the issues your reported here.

Certainly the software is not abandoned or obsolete, we have put these issues on our to do list, I will inform you of the progress.

Regards,
Filip.

[lemiceterrieux]

I cannot understand why the "non transferring" of the clock frequency to the programmer's window should affect its function, at least at "reasonable" frequencies. The clock frequency is used by the compiler to calculate delays, baud rates, etc, but there is no fuse in the ATMega's (at least in those I use) related with it. And as far as I know it is not used by the programmer ... or is it ? For myself I use the programmer in conjunction with the (old ! ) STK200 board (4 MHz crystal) both with Mega162 and Mega8515 and had no issues with this, even if the frequency is set (in the compiler's options) to the 6 MHz used on my final application board : the processor's programming is OK, the verifying function shows no errors !

[filip]

Hi,

Frequency from the compiler is used to calculate delays, just as you said, it is not transferred to the programmer.

On the other hand, frequency set in the AVRFlash programming software is the speed of the serial programming, so if you choose some undesired oscillator (in fuse bits),
for example 128kHZ internal oscillator, the compiler will pass it to the AVRFlash which will pass it to the programmer and it will automatically use it for programming thus generating an issue.

Regards,
Filip.

[lemiceterrieux]

Another bug I noticed (but with Pascal, I don't know if it occurs with C, too) : if in a project using the Mega162 one sets (Edit) the BOD to 4.3 V and programs the processor directly from the "Build" menue (build and program), the BOD is set to 2.7 V, even if in the programmer's window the BOD was set to 4.3 V before ; but this seems less critical ...