Problems with megaTinyCore in IDE 2

Development Tools IDE 2.x
1

I am encountering clocking problems using megaTinyCore with IDE 2.

Some details.
I use an ATTiny1614 to generate DCC signals using timer TCA. With prescaler set to 1 clocking is at system clock and timer values are for 16MHz clock speed (historical mostly).
I built a new H-Bridge driver and was checking the pulse rise times and then decided to check the period. Pulses representing a 1 should be 116 micro second and zero should be 200. I measured 92.7, for a one, implying clocking at 20MHz. Checking my settings in megaTinyCore it was definitely set to 16MHz.
I then did some experimenting. It turns out that the clock is not set to 16MHz for any of the frequencies requiring it. All setting are only using the 20MHz setting.
Looking at the upload it actually always displays:
Target: attiny1614
Set fuses: ['2:0x02', '6:0x04', '8:0x00']
Offset 0x02 (in 2:0x02) is the OSCCFG register and 0x02 represents 20MHz. Thus, the 16MHZ, 8MHz and 4MHz all clock the same as 20MHz, 10MHz and 5MHz.
I then tried the same sketch in IDE 1.8.16 and everything works as expected. Upload shows:
Target: attiny1614
Set fuses: ['2:0x01', '6:0x04', '8:0x00']
And all the above clocking speeds checked out correct.

I next checked uploading to a ATTiny3217 board, again with megaTinyCore, and it has the same problem. IDE 1.8.16 works fine.

I checked the version of megaTinyCore used in IDE 1, having updated it from IDE 2, and they both use the same core. I also installed the latest nightly for the IDE, the problem persists.

My immediate conclusion is there is something fishy in the way IDE 2 handles the board file in megeTinyCore. With IDE 1.8 working as expected my current conclusion is the problem must be with IDE 2.

I also had unexpected upload verification problems (after a single line change in the sketch - text to be printed to an LCD), basically stopping the MCU from working. That problem disappeared in IDE ver 1.8.

Anyone else finding similar problems?

I like working in 2 but currently, because of the clock speed problem, need to use 1.

2

Hi @Willem43. Thanks for giving the Arduino IDE 2.0.0 release candidate a try!

The problem is caused by this bug:

If you have a GitHub account, you can subscribe to that issue to get notifications of any new developments related to this subject.

There is a workaround for this. Unfortunately, it is a bit complex because it involved modifying the megaTinyCore configuration files. But if you would like, I can provide you with instructions.

3

@ptillisch Thanks for the quick reply.

Just as a note, I did delete the ..\roaming\arduino-ide folder and it made no difference (other than me having to reselect all the settings).

I would really appreciate the instructions for the current clock problem workaround. I have no problems making changes to the config and board files.

Just as an added note, the verification problem is known and should be fixed in the near future (there is also an easy workaround for that).

4

That is expected. Deleting that folder is not the fix for the issue. It is only a required step in the instructions for a minimal demonstration of the bug that will be used by the developers to understand the bug and to verify the fix.

OK, here we go.

Assumptions

The following instructions are based on the following assumptions I have made:

  • You are using the Tools > Board > megaTinyCore > ATtiny3224/1624/1614/1604/824/814/804/424/414/404/214/204 board selection.
  • You are using the Tools > Clock > 16 MHz internal clock setting.

If you are using a different board (e.g., "ATtiny1614/1604/814/804/414/404 w/Optiboot") or clock (e.g., "16 MHz internal - tuned"), then please let me know as some minor adjustments will need to be made to the provided boards.local.txt file before the instructions will do you any good.

Instructions

  1. Download this file: boards.local.zip (181 Bytes)
  2. Unzip the downloaded file.
  3. Select File > Preferences... from the Arduino IDE menus.
  4. Check the box next to Show verbose output during > ☐ compile.
  5. Click the OK button.
  6. Select Sketch > Verify/Compile from the Arduino IDE menus.
    It doesn't matter which sketch you compile. We are just using this to gather some information.
  7. Wait for compilation to finish.
  8. Scroll up in "Output" panel of the Arduino IDE.
    There you will see a line that looks something like this:
    Using board 'atxy4' from platform in folder: C:\Users\per\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.10
  9. Copy the file boards.local.txt from the folder you unzipped at step (2) to the path you found at that line of the compilation output.
    For the example output above, the target path of the file would be:
    C:\Users\per\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.10\boards.local.txt
  10. Select File > Quit from the Arduino IDE menus.
    (this is needed because the IDE must be restarted to recognize the change you made to the megaTinyCore boards platform configuration)
  11. Start the Arduino IDE.

Now try uploading again. You should see OSCCFG is now using 0x01 as expected.

Additional information

In case you are curious, I'll provide some supplemental information about the bug and workaround. Feel free to ignore it if you are not interested in esoteric details of the Arduino boards platform system.

Cause

This bug occurs only under specific somewhat rare Arduino boards platform configurations:

The default setting of the "Clock" custom board option for this board is "20 MHz internal". This option (megaTinyCore:megaavr:atxy4:clock=20internal) has an associated platform configuration property named bootloader.OSCCFG:

atxy4.menu.clock.20internal.bootloader.OSCCFG=0x02

But the clock=16internal option does not have an associated bootloader.OSCCFG property. The reason is because DrAzzy/SpenceKonde defined a default value for the bootloader.OSCCFG property, which should be used whenever the custom board option does not set the property:

atxy4.bootloader.OSCCFG=0x01

The arduino/arduino-cli#1614 bug causes the IDE to use the property value set by the default custom board option when the currently selected board option does not explicitly set it.

Workaround

This means the workaround is simply to add a property definition associated with the custom board option you are using:

atxy4.menu.clock.16internal.bootloader.OSCCFG=0x01

If Arduino CLI was working correctly, that would be redundant to the default definition.

Use of boards.local.txt

I set this property in a supplemental boards.local.txt platform configuration file in order to avoid the need to edit megaTinyCore's primary boards.txt platform configuration file. That makes the workaround a little more simple and also allows it to easily be re-applied, which will be necessary after updating to each new release of megaTinyCore, since the modification to the platform will be lost during the update. But the use of boards.local.txt is only done for convenience. The workaround would work exactly the same if you added that line directly to boards.txt.

5

@ptillisch, thanks a million for the information. Your assumptions were spot on.

You describing the background and the reason for the problem was very educational. I now know exactly what to do when megaTinyCore gets updated. That could be soon(?) to fix, amongst others, the verify problem.

I simply added the required property definition to the boards.txt file. I also added an additional one for the ATTiny3217. Those are the only MCUs I currently use with megaTinyCore. All now work as expected - great.

It is encouraging to know how many of the outstanding problems are actually known. I am sure we will eventually end up with a great IDE.

I really appreciate the huge effort you go to in explaining the background to the problem. This way one learns more about the system. I think there are quite a few very clever people on this forum who can learn from your efforts to promote and education others.

Again, thanks a lot.

6

You're welcome. I'm glad it's working now.

Regards, Per

7

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.