Go Down

Topic: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc) (Read 21197 times) previous topic - next topic

windoze_killa

I was wrong. it was only set to verbose for upload. Here is the verbose for compile.

Code: [Select]

Arduino: 1.8.13 (Linux), Board: "ATtiny3217/1617/1607/817/807/417, ATtiny3217, 20 MHz, 1.8V (5 MHz or less), Disabled, Disabled, EEPROM retained, Enabled (default timer), Closer to 5v"











/snap/arduino/41/arduino-builder -dump-prefs -logger=machine -hardware /snap/arduino/41/hardware -hardware /home/jason/snap/arduino/41/.arduino15/packages -hardware /home/jason/snap/arduino/current/Arduino/hardware -tools /snap/arduino/41/tools-builder -tools /snap/arduino/41/hardware/tools/avr -tools /home/jason/snap/arduino/41/.arduino15/packages -built-in-libraries /snap/arduino/41/libraries -libraries /home/jason/snap/arduino/current/Arduino/libraries -fqbn=megaTinyCore:megaavr:atxy7:chip=3217,clock=20,bodvoltage=1v8,bodmodeactive=disabled,bodmodesleep=disabled,eesave=enable,millis=enabled,uartvoltage=5v -ide-version=10813 -build-path /tmp/arduino_build_178766 -warnings=none -build-cache /tmp/arduino_cache_16426 -prefs=build.warn_data_percentage=75 -verbose /home/jason/snap/arduino/current/Arduino/PI_GPI_ATRE_OLED_TNR_3217/PI_GPI_ATRE_OLED_TNR_3217.ino

Error resolving FQBN: getting

Error compiling for board ATtiny3217/1617/1607/817/807/417.
Engineers design things.....technicians make them work.

I don't need anti-static wrist straps.....an instructor years ago told me I had no potential.

windoze_killa

Here is the compile output for version 2.0.5.

Attached as a file as it seems to be huge for somereason.
Engineers design things.....technicians make them work.

I don't need anti-static wrist straps.....an instructor years ago told me I had no potential.

pert

I was wrong. it was only set to verbose for upload. Here is the verbose for compile.
OK, that output might have provided a clue. I can now see your FQBN:
Code: [Select]
-fqbn=megaTinyCore:megaavr:atxy7:chip=3217,clock=20,bodvoltage=1v8,bodmodeactive=disabled,bodmodesleep=disabled,eesave=enable,millis=enabled,uartvoltage=5v

The strange thing is this is the FQBN that would be generated by using megaTinyCore 2.0.5.

For example, here you can see that 2.0.5 has a "20" option for the clock menu:
https://github.com/SpenceKonde/megaTinyCore/blob/2.0.5/boards.txt#L55
Code: [Select]
atxy7.menu.clock.20.build.speed=20
but 2.1.3 has no option of that name. The equivalent is "20internal":
https://github.com/SpenceKonde/megaTinyCore/blob/2.1.3/boards.txt#L60
Code: [Select]
atxy7.menu.clock.20internal=20 MHz Internal
So it's impossible to get "clock=20" in your FQBN when using megaTinyCore 2.1.3

Same for the "bodmodeactive" and "bodmodesleep" menus. Your FQBN is also missing the new "resetpin", "startuptime", and "serialevent" menu options.

So my advice is to try a fresh install. Delete everything under the /home/jason/snap/arduino/41/.arduino15 folder except for preferences.txt, then reinstall megaTinyCore 2.1.3. Note that .arduino15 is a hidden folder, so if you have your file browser configured to not show hidden files and folders then you won't see it. You can also get to it by clicking the link the the Arduino IDE's File > Preferences menu.

I was a bit suspicious of your snap installation of the Arduino IDE as the culprit, since the unspecified modifications made by random community members in order to get the IDE into the package manager repository are somtimes the cause of confusing bugs that don't occur when using the official Arduino IDE. However, I just installed the snap package and still wasn't able to reproduce the error you're getting.

windoze_killa

Engineers design things.....technicians make them work.

I don't need anti-static wrist straps.....an instructor years ago told me I had no potential.

pert

FQBN stands for "fully qualified board name".

If you were telling a human which board configuration to use, you might say something like:
Quote
In the Arduino IDE, select "ATtiny3217/1617/1607/817/807/417" from the Arduino IDE's Tools > Board > megaTinyCore menu.
Now make sure you have "ATtiny3217" selected from the Tools > Chip menu.
Also, make sure you have "20 MHz Internal" selected from the Tools > Clock (change 20/10/5 int<->other=burn bootloader) menu.
...and so on.

But that's not how it's done when you're communicating with a computer. We need a way to specify the exact board configuration in a machine readable format. That is the FQBN.

People who only use the Arduino IDE's GUI can usually remain blissfully unaware of FQBN. But once you start using command line tools, you must use it because there are no longer nice menus for you to use to point and click your way to a board configuration.

Your FQBN:
Code: [Select]
megaTinyCore:megaavr:atxy7:chip=3217,clock=20,bodvoltage=1v8,bodmodeactive=disabled,bodmodesleep=disabled,eesave=enable,millis=enabled,uartvoltage=5v
The "megaTinyCore" is the vendor name.
The "megaavr" is the architecture.
The "atxy7" is the board ID.
After that come the custom board options you find in the additional Tools menus that appear after you have selected a megaTinyCore board from the Tools > Board menu. You can learn more about those here:
https://arduino.github.io/arduino-cli/latest/platform-specification/#custom-board-options

windoze_killa

Followed your instructions but now get this error.

File attached.



Engineers design things.....technicians make them work.

I don't need anti-static wrist straps.....an instructor years ago told me I had no potential.

pert

The error from windoze_killa's 2.1.3 output.txt:
Code: [Select]
In file included from /home/jason/snap/arduino/current/Arduino/libraries/Adafruit_GFX_Library/Adafruit_GrayOLED.h:31:0,
                 from /home/jason/snap/arduino/current/Arduino/libraries/Adafruit_GFX_Library/Adafruit_GrayOLED.cpp:20:
/home/jason/snap/arduino/current/Arduino/libraries/Adafruit_BusIO/Adafruit_SPIDevice.h:61:22: error: 'BitOrder' has not been declared
                      BitOrder dataOrder = SPI_BITORDER_MSBFIRST,
                      ^~~~~~~~


Compatibility with the Adafruit_BusIO was broken by this change:
https://github.com/SpenceKonde/megaTinyCore/commit/adb5cbf0bbb470a34c5c206be97d49a165cff86f

Adafruit added support for megaTinyCore to the library here:
https://github.com/adafruit/Adafruit_BusIO/commit/374b86a1864da22fd275ff8465722943f82a00ca
but that was based on the previous build.board property value:
https://github.com/SpenceKonde/megaTinyCore/blob/93fe227c663664172fc1433ac0b5a9f785dc49c9/megaavr/boards.txt#L150
Code: [Select]
atxy7.build.board=attinyxy7

Since it's impossible to know how much other code might have been dependent on the previous macro, the best way forward would be to add a backwards compatibility macro definition here:
https://github.com/SpenceKonde/megaTinyCore/blob/596ca99fb5a491ac0cbe70f12aadc2233d2c2504/megaavr/boards.txt#L197
Code: [Select]
atxy7.build.extra_flags={build.serialevent} {build.millis} -DUARTBAUD{build.uartvoltage}
like so:
Code: [Select]
atxy7.build.extra_flags={build.serialevent} {build.millis} -DUARTBAUD{build.uartvoltage} -DARDUINO_attinyxy7

windoze_killa

Engineers design things.....technicians make them work.

I don't need anti-static wrist straps.....an instructor years ago told me I had no potential.

windoze_killa

Well done. Thank you. It now compiles.

Now to get it to upload.
Engineers design things.....technicians make them work.

I don't need anti-static wrist straps.....an instructor years ago told me I had no potential.

pert

You're welcome. I'm glad to hear it's compiling now. I'm wishing you good fortune with the upload!
Per

windoze_killa

Thats covered in another post under bootloader issues. I think I may have fried my programmer. (JTAG2UPDI)
Engineers design things.....technicians make them work.

I don't need anti-static wrist straps.....an instructor years ago told me I had no potential.

grandaspanna

Not sure if this is the right place, but I *think* it relates to BOD settings, which appear in the menu :-)

Under some circumstances, the microcontroller (1614 & 412 variants, at least) doesn't start properly if the on-voltage ramps up too slowly (suspicion, not yet measured). Target supply voltage is 5.5V and running at 20MHz.

Is this plausible? Would setting the BOD voltage higher help? Is there another approach?

DrAzzy

Somehow I missed those posts about the issue with the build.board changes until they were independently reported to me today. Bus_IO library is now fixed in the adafruit repo (with a much better test - and support for DxCore), but I am adding backwards compatibility defines to 2.1.4 which I hope to release tonight.

@grandaspanna - it is.... plausible? maybe? Depending on the details of the test case and configuration. What is the BOD voltage currently set to? Is BOD enabled  on at least "sampled" for active mode? How do you know that it's not starting up, as opposed to some other sort of failure? It is not the sort of cause that my mind would jump to though - like, it's the sort of thing I'd be considering only if I could demonstrate a clear correlation with the rise time of the supply AND had also ruled out a peripheral misbehaving due to the slow rising power, AND the tiny was running outside of spec at some point in the startup process....

I think it would be far more likely if it, say, depended on communication with an external device, and tried to make contact X long after power off and would hang if the device didn't respond, and the device had a different BOD set point, such that slow rising power would result in the tiny trying to talk to it before it had started.... 
ATTinyCore and megaTinyCore for all ATtiny, DxCore for DA/DB-series! github.com/SpenceKonde
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts, mosfets, awesome prototyping board in my store http://tindie.com/stores/DrAzzy

grandaspanna

Re: Bus_IO - that's great news. Will aim to do some more tinkering with that.

Re; BOD - I wasn't really even aware of these settings and have never adjusted them. What was being programmed was:
-Ufuse1:w:0b00000000
Which is 1.8V, but not enabled.

The challenge I'm facing is that two users have reported intermittent issues that I can't reproduce, and they're both in different continents.

To test this theory, I've sent an updated board with 4.2V BOD and "Enabled with wake-up halted until BOD is ready".

There's some very basic code at the start of the program to flash an LED before it does anything else and it's not even getting there - the LED is either hard on or hard off. Maybe it's launching too early at 20MHz before the voltage is high enough to cope. My plan B is to get the code working at 4MHz (it's actually super simple and should be fine), but I'm also buying some additional hardware to try and replicate their use case.

I apologise for the vagueness here, I'm kinda bouncing in a vacuum without the ability to get my hands on the set-up that's not working.

Edit: I've also thought about adjusting SYSCFG1 to delay startup to the max 64ms.

On a different note, the AVR128DA32 board is cool. Can't wait for the DB and DD chips to start showing up at local distributors!

DrAzzy

Well, I can't say I'm terribly surprised that you are having some sorts of issues, seeing as you have no BOD... and like, basically no countermeasures it sounds like? And you're starting it up 8ms after the POR circuit disengages at full speed, without any attempt to ascertain whether the power is okay or anything...You *are* kind of doing a whole bunch of things that would make it worse. The other problem with the tinyAVR 0/1-series is that unless you've fused them to switch the UPDI pin to reset, you don't have any way for them to guarantee that their attempt to power cycle it to fix the problem even caiused it to restart (a few times I had that issue, I think - no BOD, no reset pin, no regulator sucking a bit of power to pull the caps on the board below the POR voltage... I thought I was going nuts! (some people still think I am)

I'd be inclined to use BOD, as you suggested. If they don't have to run on batteries, might as well just do enabled/enabled, if they do, then enabled/hold wake as you said. The WDT might also be an option, depending on the application.

A longer SUT would also help; with 2.1.3 you can already choose 0/8/64ms SUT, and I'm adding the rest of the options for 2.1.4, which is coming out really soon (just gotta make sure the UART still works after what I did to it., and do a couple of boards.txt tweaks, plus move the version number defines into the platform.txt, because I have *got* got get away from having to change the version number in two places, since I literally have a near-zero-percent record of getting it in both places every release.....

Of course, the problem with your remedy is.... so they get the boards. Most likely, the new ones work, customers are happy.... but until you capture a non-working board and are able to make it fail yourself, you have no idea whether the problem was a manufacturing flaw (cold solder joints?) a problem with their environment, (power supply, EMI, the body of an electrical engineer from the 70's buried in a shallow grave in his back yard by the previous homeowner, directly facing his workshop), a combination of the two (cold solder joints on a cap such that fails with his crap power supply but not a good one)... And the worst part is, even if you pay for return shipping and get him to send it back (in my experience, the moment they have a working board, they promptly stop responding to your email)... and if you have an identical power source and EMI environment, and the dead engineers twin brother buried in your back yard (it wasn't easy! For one thing, the poor guy was still alive....), it STILL might not fail, because during the return shipping, thermal cycling and rough handling could have caused the dodgy solder joint to behave more consistently (I've had this sort of thing happen to me - the intermittent in my top of the line laptop healed itself en route back to the vendor's repair shop... and was still gone when I got it back, packed improperly, the CD drive ruined from it's trip back, and the warranty was expired by then... (never buy the top of the line laptops - they push the envelope, and reliability suffers; the other top of the line laptop I got is on it's third motherboard now).... Anyway, yeah, it's a very frustrating situation to be in; I wish you luck... but all things considered, with what you describe of it, I would definitely be using BOD



Aw man, you think the DA32 is cool?! It only has a single type A timer, 26 full function I/O pins, only 3 USARTs and type B timers - and it can't use a high frequency crystal for the system clock! Pah - it was only cool until they announced the DB-series ;-)

No, you want the AVR128DA64....  It's got alllll the good shit! The second TCA, the full complement of 6 USARTs and 5 TCBs, the full 8-pin MVIO-capable PORTC... not to mention the on-chip OPAMPS!

My plan with those bad boys is to make a board with the AVR128DB64... but add on this programmable regulator from Maxim that lets you set the voltage by tying 2 pins either high, low, or floating while switching the enable line.... So you will not only get the MVIO pins, but your code will be able to tell it what voltage to supply on those... Plus. naturally, crystal on PA0/PA1 with the serial port on PA4/PA5 (the alt pins). I'll need to do something about the TCD pins, of course - but kind of want to make a way to move those around anyway (apparently, the 128DA is the only part where the TCD mux is borked - it works fine of the rest of the DA's and the DBs). Microchip just this week has deigned to lower itself to selling the non-DIP versions of the DB-series in quantities of less than a tray from microchip direct, so they're not unobtainium anymore. Gotta get those board designs ready x_x )

Naturally what I'm most excited about is the DD-series - I love low pin-count devices, and MVIO on a 14 or 20-pin package would be just lovely (the crystal support is nice too, especially since the tinyAVR 2-series, (per digikey estimates, scheduled for release around 2 months from now (though, a month ago, it was 2 months from a month ago... so...)) won't have support for external crystal... but they've also got a unique potential for suggestive jokes, which doesn't come along very often in electronics....

Anyway, that was fun to write, now back to work on 2.1.4
ATTinyCore and megaTinyCore for all ATtiny, DxCore for DA/DB-series! github.com/SpenceKonde
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts, mosfets, awesome prototyping board in my store http://tindie.com/stores/DrAzzy

Go Up