Urboot for ATTiny13/A #19
Comments
|
Would these baud rates be what you are after for these F_CPU? if [[ /attiny13/attiny13a/ =~ /$mcu/ ]]; then
baud[9600000]=250000/230400/115200/57600/38400/19200/9600
baud[4800000]=115200/57600/38400/19200/9600
baud[1200000]=38400/19200/9600
baud[600000]=19200/9600
fi |
|
That would be excellent! Is 250000 baud the fastest "standard" baudrate the ATtiny13/A can handle without too much error? |
Yes. The ATtiny13 does not have a hardware UART. So, F_CPU/baud rate is the budget of clock cycles that the software has for delaying half a bit, sensing the RX bit, then delaying half a bit. 9.6 MHz/250 kbaud gives us 38.4 cycles. That should just about work, but I doubt one can do SWIO with 460800 baud (only 20 cycles for a complex task). BTW, 38.4 cycles also means an intrinsic quantisation error of 0.4/38.4 ~ 1%, which is OK assuming the internal oscillator does not add more than about 1.5% of frequency deviation. Smaller baud rates have a better quantisation error: for example, at 115200 baud there is a budget of 83.333 cycles where the quantisation error is 0.33/83.33 = 0.4 %, so you can afford the internal oscillator to be off by max 2%. |
|
OK, done: see, eg, ATtiny13A bootloaders |
|
Thanks! I'll be away for the weekend, but I'll give it a try next week when I'm back home |
|
I checked my SWIO code for the max baud rate. It is F_CPU/29 for classic parts with 16-bit PC and F_CPU/33 for classic parts with 22-bit PC (ATmega2560, eg). XMEGA parts can achieve slightly higher baud rates: F_CPU/28 and F_CPU/32, respectively. This is owing to subtle changes in the clock cycles for opcodes. So, yes, 9.6 MHZ/29 ~ 330 kbaud is the most you can hope to work here. BTW, is there a good documentation for the timings of newer parts? Some of these have Do these parts have XMEGA timings? @SpenceKonde @MCUdude @mcuee |
|
I am not an AVR expert but I read that they have a bit better timing than the xmega timing as mentioned in Chapter 4 of the following Microchip/Atmel document In the manual, AVR DA is said to have the same AVRxm core as the xmega but I think it is a mistake, as the chip datasheet points to AVRxt core. Examples, I can see improvement in instructions like SBIS, some cases of LD/LDD/ST/STD.
|
|
It does not seem to be able to write to flash in terminal mode. EEPROM writing is okay.
```
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_issue_1262_mod -c usbasp -p t13a -qqt
avrdude> dump lfuse
0000 3a |: |
avrdude> dump hfuse avrdude> dump lock avrdude> erase PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_issue_1262_mod -c usbasp -p t13a PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_issue_1262_mod -c urclock -P COM7 avrdude_issue_1262_mod: AVR device initialized and ready to accept instructions PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_issue_1262_mod -c urclock -P COM7 -p t13a -qqt avrdude> write eeprom 0 0xaa 0x55 0xaa avrdude> dump flash 0x100 0x40 avrdude> write flash 0x100 0xaa 0x55 avrdude> quit PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_issue_1262_mod -c usbasp -p t13a -qqt avrdude> quit |
|
Same for normal mode. EEPROM writing is okay but not flash writing. Basically it does not write anything in the flash.
```
PS C:\work\avr\avrdude_test\avrdude_bin> cat .\entest_64B.eep
:020000040000FA
:2000000054686520717569636B2062726F776E20666F78206A756D7073206F76657220740E
:200020006865206C617A7920646F670A54686520717569636B2062726F776E20666F78207C
:00000001FF
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_issue_1262_mod -c urclock -P COM7 avrdude_issue_1262_mod: AVR device initialized and ready to accept instructions Writing | ################################################## | 100% 0.24 s avrdude_issue_1262_mod: 64 bytes of eeprom written Reading | ################################################## | 100% 0.06 s avrdude_issue_1262_mod: 64 bytes of eeprom verified avrdude_issue_1262_mod done. Thank you. PS C:\work\avr\avrdude_test\avrdude_bin> cat .\zeros_t13a_test.hex PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_issue_1262_mod -c urclock avrdude_issue_1262_mod: AVR device initialized and ready to accept instructions Writing | ################################################## | 100% 0.04 s avrdude_issue_1262_mod: 256 bytes of flash written Reading | | 0% avrdude_issue_1262_mod warning: verification mismatch avrdude_issue_1262_mod done. Thank you. PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_issue_1262_mod -c usbasp -p t13a -qqt avrdude> quit |
|
@mcuee Thanks for testing! Looks like you need to enable |
|
@mcuee And thanks for the pointers to exact timings. |
That is it. Thanks for pointing out this apparent mistake. Now it works well. |
|
250,000 bps is also fine. |
That's good. Thanks for testing @mcuee. Amazing that the bootloader works on such a small flash/sram. The smallest b/loader is 256 bytes so can be used for rapid prototyping... |
|
Haha, now you may have a chance to add urboot to MicroCore. |
|
Adding Urboot to MicroCore is definitly something I'll consider! The only problem is that when I designed the "MicroCore hardware", I decided to keep compatibility with the existing ATtinyCore and its bootloader implementation, so that ATtiny85's could be programmed usimmg my board without modifications. The quirk here is that ATtinyCore and MicroCore use pin PB0 for TX, and PB1 for RX. The opposite of what the pre-compiled urboot binaries does. |
That should be a easy change. |
|
It would be awesome to have a menu in the Arduino tools menu like this. For rapid prototyping, a bootloader is very convenient |
Sure. Lines 586 to 608 in 15ced59 | separated list:
|
|
I assume the microcore boards do not have a LED? That saves 6 bytes (choose a b/loader without |
|
I'll look more into this tonight. |
You can judge this by checking out if there is a | I can only assume that a hardware reset also resets the internal WD timer to 0... That is actually highly likely come to think of that. Most AVR will have a fuse setting that switches on the WD timer by default. In order for these to work the WD timer needs to be reset to 0 on external (hard) reset. Otherwise there would be an unknown period for the first WDTO after external reset, which isn't acceptable. I believe the function that configures the WDTO in urboot is the only aspect where optiboot has shorter code (as optoboot drops the wdr) |
|
It looks like the lednop bootloaders for ATtiny13/A are bigger than 256 bytes, so I think it's best with a bootloader that doesn't flash the LED while programming, but can instead fit within 256 bytes. (Ralph Doncaster actually created a 64-byte (!) sized bootloader, picoboot. I'm not sure how "safe" this is compared to Urboot, but it's still impressive in its own right!) @stefanrueger could you add MicroCore as another "core" in the urboot repo that contains pre-compiled bootloaders for ATtiny13A with RXD=PB0/TXD=PB1 and RXD=PB1/TXD=PB0? I see no reason why not to add a bootloader option to MicroCore when a proper, failsafe bootloader can fit within 256 bytes! |
|
I've just pushed a commit to the MicroCore repo where I've added Urboot as an option in the Arduino tools menu. Using Urboot with the 9.6 MHz internal oscillator works like a charm, but I'm having issues getting the 4.8MHz, 1.2MHz, and 600kHz options to work. @mcuee can you test it on your hardware? If you want to use Arduino IDE directly, you'll have to install MicroCore using the boards manager install, and then replace the installed core files with the one found in the repo on Github. 4.8 MHz option: 1.2 MHz option: 600kHz option: |
|
If 9m6 Hz @ 115200 baud works like a charm, then so should 4m8 Hz @ 57600 baud. It's even the same bootloader bit for bit, just that the entire "world" is slower. Will be the same for 1m2 Hz @ 14400 baud with exactly the same bootloader, no need to recompile or reflash. Could you try these fuse settings to effect the correct F_CPU and then set the correct
Yes, cool stuff. I read at the source and think I understand how it works. True, safety is all shifted to the uploader (but there is an eor check sum every 4 command bytes); there is no download; baud rate is a fixed function of F_CPU (no code left for delay loops to slow baud rate down), uploader needs to be able to create that baud rate, but yes, actually very cool stuff. |
|
I am unhappy with the alphabetic order of the oscillator frequency directories in the urboot.hex github so thought of Similarly for the baud rates Do I miss some? |
|
Could also do Probably even neater (thinking out loud here) |
Yes that is the case for me. I only need to change the fuse setting in this case. Same for 250000 bps firmware which will run at 125000bps for 4.8MHz clock. |
|
The new names for the files and folder in the |
|
OK, a wider spread is needed than I imagined. How about the variation is in steps of 1.25% and has a range of 13 steps from -7.5% to 7.5%? Would that work? Coincidentally, 4500 = 4800-6.25% |
|
I have never seen an internal oscillator being faster than it should, only slower. And since UART can handle a few percent errors, it should be fine with 1.5 or 2% steps I think. How about: This should even cover the chips that "fell off the delivery truck" and sold on the black market. |
|
I read on a forum that some ATtiny13 chips are as bas as 10% off sometimes. Usually, the 4.8MHz one is the worst, because the default calibration value that gets automatically is for the 9.6 MHz one. Which means that in order get the 4.8MHz oscillator to be consistent, we'll have to read the second byte in the calibration register using Avrdude, and ideally write this to a fixed address so that the bootloader can load this value into its OSCCAL register. This isn't currently possible using Avrdude 7.1, but with the feature suggested in avrdudes/avrdude#1322, I think it should be possible. However, it's probably difficult to make ut fit within 256 bytes. |
TLDR; 2% stepping is too big, and 1% too conservative. 1.25% to 1.5% seem right Back of the envelope: if the onset of a transmitted bit is 25% of its width early or late comms start getting into murky waters. Errors accumulate over the 10 start, data and stop bits, so can afford 2.5% bit error rate, which is composed of (worst case) sender quantisation error, sender frequency error, receiver quantisation error and receiver frequency error. Assuming the host PC has perfect comms we should really not go above 2.5% for bootloader. The quantisation error can be finely controlled by urboot's SWIO, and it is set to 6000 ppm (0.6%) in |
That's interesting! Could make boundaries asymmetric. Is that documented somewhere? Is it plausible owing to the waty factory calibration and/or the workings of the |
Well, when thinking about it, I once had an ATtiny13 where the internal 4.8 MHz oscillator ran at ~5.0 MHz, but this was most likely because the 9.6MHz calibration value was automatically loaded. Again, the 9.6MHz oscillator is usually fine, it's just a few percent off. It's the 4.8MHz that's causing problems. And I haven't been able to use the bootloader with the internal 128kHz oscillator. Probably because this way too "off". The datasheet even states that its frequency varies with voltage, temperature and batch number. In other words, not very dependable. |
In the end, this may be the better way to go for users who want to run the urboot bootloader for ATtiny13A at 4.8MHz, even if the bootloader side can not fit in 256 Bytes. |
|
Other than this ATtiny13/13A, are there any other AVR MCUs have this type of two OSSCAL value for two internal oscillator frequency? |
How does the calibration byte come to be in flash in the first instance? Once the calibration byte has been written to flash, then the additional step (min 8 bytes code) in the bootloader to fetch that byte from that flash location and store it in Does the modified Do you have a natural flash address for the calibration byte? Another idea is to put a 8-byte subroutine at FLASHEND-6-8+1 (just below the 6-byte table at FLASHEND) Together with an Not pretty, but should work. Any external re-calibration procedure would write the two-byte opcode An alternative 6-byte solution is to simply have All things considered, I still prefer the bootloader not deal with |
|
I could be wrong but I think by Section 17.3, page 111 of the ATtiny13A datasheet The signature area of the ATtiny13A contains two bytes of calibration data for the internal oscillator. The calibration data in the high byte of address 0x00 is for use with the oscillator set to 9.6 MHz operation. During reset, this byte is automatically written into the OSCCAL register to ensure correct frequency of the oscillator. There is a separate calibration byte for the internal oscillator in 4.8 MHz mode of operation but this data is not loaded automatically. The hardware always loads the 9.6 MHz calibration data during reset. To use separate calibration data for the oscillator in 4.8 MHz mode the OSCCAL register must be updated by firmware. The calibration data for 4.8 MHz operation is located in the high byte at address 0x01 of the signature area. |
|
@mcuee Thanks for the explanation. OK, so the calibration value can come from the second calibration byte of the signature area. The suggestion is that some external mechanism (AVRDUDE?) reads that byte and copies it to flash, so that the bootloader does not need to go to the expense of reading the actual (second) calibration byte. Alternatively, some external calibration mechanism could measure the actual internal 4.8 MHz clock (you rig up your chip-scale atomic clock (check out the purchase price here) to twiddle a pin once a second, upload a sketch that computes the perfect calibration byte and stores that in the flash location). I was thinking aloud about the workflow and where to put that calibration value (a fixed flash location outside the bootloader, a fixed flash location within the bootloader, encoded as part of an |
|
Yes, what I was trying to say was that there is currently no easy way of getting hold of the second byte in the calibration register. If it was, it would be cool if it was possible to "inject" this into the existing bootloader in flash somehow. But even this value isn't always spot on, and the user would still have to choose a bootloader to match their now "slightly off" oscillator. BTW I'm pretty much finished implementing Urboot for MicroCore! I'll have to do a bit more testing (I can't get the bootloader to work when running at the internal 128kHz WDT oscillator), but I think I'm ready for a new MicroCore release very soon. Thank you so much @stefanrueger for your help, knowledge and last but not least, patience! A reliable bootloader for the ATtiny13 (or any classic ATtiny for that matter) would still be a far-fetched dream if it wasn't for your excellent Urboot bootloader.
|
|
This bootloader menu looks so cool! Note I have in the meantime pushed +/- 8.75% too.
The intl 128 kHz WDT oscillator too is notoriously off its nominal frequency. When I build a prototype PCB one of the things I routinely measure is the duration of the 1024 ms watchdog timeout against a GPS pps signal. My sample of 43 parts (mostly m328p) resulted in an average of 1049.6 ms +/- 39.33 ms (min of the sample was 979.8 ms and max was 1153.5 ms). Sooo, in my experience the frequency (not time) was typically between -6% and +1.4% off. My sample could be correlated by buying 10 pieces at a time (or so). The extremes were between -11.1% and +4.3% off. That asymmetry chimes with your experience of the internal RCs. |
|
Iirc on classic, the spec for the wdt and ulp oscillators (as appropriate)
often went unmentioned, but when thyme did let it slip it was like +/-30%
or something godawful like that. It is shall we say nit intended for any
sort or precision timing...
…____________
Spence Konde
Azzy’S Electronics
New products! Check them out at tindie.com/stores/DrAzzy
GitHub: github.com/SpenceKonde
ATTinyCore: Arduino support for almost every ATTiny microcontroller
Contact: ***@***.***
On Mon, Apr 10, 2023, 19:29 Stefan Rueger ***@***.***> wrote:
This bootloader menu looks so cool! Note I have in the meantime pushed +/-
8.75% too.
running at the internal 128kHz WDT oscillator
The intl 128 kHz WDT oscillator too is notoriously off its nominal
frequency. When I build a prototype PCB one of the things I routinely
measure is the duration of the 1024 ms watchdog timeout against a GPS pps
signal. My sample of 43 parts (mostly m328p) resulted in an average of
1049.6 ms +/- 39.33 ms (min of the sample was 979.8 ms and max was 1153.5
ms). Sooo, in my experience typically between -1.3% and +6.3% off. My
sample could be correlated by buying 10 pieces at a time (or so). The
maximum length was actually 12.5% off (hopeless), the minimum one -4.3%.
—
Reply to this email directly, view it on GitHub
<#19 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTXEW4WCLDDJXVK5ZNF5I3XASJUHANCNFSM6AAAAAAVL5753U>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
ulp = ultra low precision? 😉 |
|
I think the data sheets typically say sth about 10% for the factory calibrated(!) internal RCs, but I also suspect that these intervals are deliberately wider than reality. So would expect WDT to have similar behaviour in practice (same technolgy?) |
|
Ultra low power I think is the official nam
But yours is more accurate. (Kinda like the USI, the Useless Serial
Interface on some tinies)
+/-10% applies ro the hd osc, most sheets don't give tolerance for the low
speed on in the premodern era
…____________
Spence Konde
Azzy’S Electronics
New products! Check them out at tindie.com/stores/DrAzzy
GitHub: github.com/SpenceKonde
ATTinyCore: Arduino support for almost every ATTiny microcontroller
Contact: ***@***.***
On Mon, Apr 10, 2023, 19:37 Stefan Rueger ***@***.***> wrote:
ulp = ultra low precision? 😉
—
Reply to this email directly, view it on GitHub
<#19 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTXEWZFEXRI3MTHWVMFUJTXASKUJANCNFSM6AAAAAAVL5753U>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
So, unlike say the m328p, it's not possible to read the calibration bytes from software. Here how it's done for Atmega328P: The data sheet for the t13a only explains how to read the lock bits, the fuse low and fuse high byte from software, so presumably it's not possible to read the calibration byte from software. The longer I look at this the more I think that it is a bug in the design to allow fuses to be set to 4.8 MHz but not load the existing calibration byte for this into It might be possible to create bespoke bootloaders just for the t13/a internal 4.8 MHz oscillator but then there would need to be an agreed workflow for this and an agreed position of the byte in flash (which could be encoded into an |
|
Just wondering why you say "there is currently no easy way of getting hold of the second byte in the calibration register"? I can see that avrdude can do it. |
I am not so sure what you mean by "from software". But at least avrdude can read the two calibration bytes. |
|
Yes, but the microcontroller can't read calibration byte two on its own. It has to be done using an external programmer, and the value has to either be written to Flash or EEPROM. Urboot can't utilize this second byte by itself. A programmer has to read it, and then write the value somewhere so that the bootloader can utilize it without using too much flash space. A procedure like this would be difficult to implement in Arduino IDE's platform.txt. |
I see. I think @stefanrueger's idea of Then the template bootloader can be modified to utilize this value (input by the user). If it is difficult to do within MicroCore, this can be done by a utility which can be part of urboot. This utility can even integrate the first part (calling avrdude to read the second calibration byte). |
This is exactly why it makes Microchip's documentation so bitter. They say " To use separate calibration data for the oscillator in 4.8 MHz mode the OSCCAL register must be updated by firmware. The calibration data for 4.8 MHz operation is located in the high byte at address 0x01 of the signature area." Buy they don't say "It's actually impossible for the firmware to read the calibration data" and leave every single user to pick up the pieces for their failure to copy the 4.8 MHz calibration value into the
I don't think this is a reasonable effort and a reasonable avenue for the urboot project. The project will be better off concentrating on other issues. If someone really wants to use 4.8 MHz for a project they can set the fuses to internal 9.6 MHz (which gets the factory calibration byte loaded correctly at reset) and then set the system clock prescaler to 2 at the startup() of their sketch. The bootloader would run at 9.6 MHz (b/c it wouldn't have the code for dividing down the system clock). The only situation where this would be out of specs is for a voltage below 2.8 V where 9.6 MHz is at the verge of "overclocking". |
Fair enough. |
|
Cannot think of anything more I could do for classic parts, so have released version u7.7. It's been a quite positive experience to work with, in particular you @mcuee and @MCUdude on this project. I have implemented a few things that I probably wouldn't have had it not been suggested persistently by either of you (autobaud solved inspired by code from @nerdralph, repository of pre-compiled bootloaders, documentation, treating internal oscillators, find a way to deal with their notorious inaccuracy etc etc). So thank you for that and staying alongside in that journey. Closing this issue as completed. |
Unlike other AVRs, the internal oscillator in the ATtiny13/A runs at 9.6 MHz and is dividable down to 4.8 MHz, 1.2MHz, and 600kHz.
It would be great if these existed pre-compiled bootloaders for these clock speeds!
The text was updated successfully, but these errors were encountered: