SpenceKonde / ATTinyCore

Arduino core for ATtiny 1634, 828, x313, x4, x41, x5, x61, x7 and x8

Other

1.57k stars 305 forks source link

Can attinycore (with optiboot) program with rs485? #393

Closed bzroom closed 4 years ago

bzroom commented 4 years ago

I found AttinyCore through Optiboot's site. https://github.com/SodaqMoja/optiboot/blob/master/README.rs485

I'm trying to upload via rs485. I have already burned the bootloader with optiboot. I am using an Attiny1634.

It seems like i might need to recompile optiboot with rs485 enabled but i'm looking through the optiboot source and i'm not seeing any mention of rs485.

Is programming via rs485 supported?

If not, any idea how i can program through rs485? It is essential to my application.

Otherwise, attinycore is working great so far!

Thank you!

bertmelis commented 4 years ago

What do you mean with RS485? It's an electrical specification so with the proper circuit it is possible yes.

bzroom commented 4 years ago

Thanks for your reply, but i dont think it's as simple as that. Can you show me what that circuit would look like?

If you check the link i posted in my original comment you can see that rs485 programming requires an additional pin and support from the bootloader. rs485 is not just plain serial. There is an additional direction pin that must be used.

I dont see any reference to this direction pin or how to set it up in optiboot. Can you show me an example or documentation of how to do it?

Please.

Thank you.

SpenceKonde commented 4 years ago

So this is the half-duplex RS485, where there's an additional pin to enable transmittion?

The bootloader does not support that. The latest optiboot also does not support it. What program are you even hoping to use to upload it? Does avrdude support it?

I'm not sure if the STK500 protocol is amenable to that - but it doesn't look impossible, assuming avrdude can be told to use that pin too, or you have another upload tool that does. You'd also have the problem of how to reset into the bootloader, since you don't have the DTR pin for autoreset....

SpenceKonde commented 4 years ago

Oooooh! actually checked your link. Yeah, the version of optiboot I am using doesn't have that. I will see if I can steal that bit of code - it doesn't look too hard to add!

Upon doing so, I'd be happy to build a binary with it for you (at least on windows, setting up the build environment is a pain in the ass) to test (I don't have the tools to test it) - the reset thing will be an issue though. Without figuring out how to deal with that, it will be awkward to use. Maybe I should also increase the time the bootloader runs after reset to 8 seconds?

If I get this working, what pin do you want me to use for your binary? Any other special requests for it? I can also change the pin used for the LED if you want.

No plans to include pre-built binaries for this in the release, though.

bzroom commented 4 years ago

Thank you for looking into it.

I'm on windows and i can try to setup the build environment to test it, if you have setup instructions. I also have linux if that's easier.

It would be nice if the reset time was a configurable build option like the rs485 direction pin. 8 seconds is probably a bit too long for my preference. Maybe 2 seconds?

I plan to just power on the device at "exactly the right time" for programming, and not use the automatic reset mechanisms. My application is embedded deep in the machine. I use rs485 to communicate with the attiny so thats why i wanted to program with the same interface. I have a way to isolate power to only the mcu during programming.

Any pin should be ok for me to test but if i had to pick i might try PC0 or PB3. Which pin is currently used for an LED? I didn't notice that, and i dont currently have an led hooked up to my mcu.

Here are all the settings i'm using when flashing the boot loader: Board: attiny1634 (optiboot) Clock: 8mhz internal >4v BOD: disabled Save eeprom: retained LTO: enabled Bootloader: Uart0 Millis: enabled

Thank you so much for looking into it. It seems like my other option at this point is to use xboot with an atmega but i'd like to avoid that constraint if possible.

Thanks again!

bzroom commented 4 years ago

Hi Spece,

I was wondering if you had any chance to look at this or if there's anything I can do to help?

Thank you again. :)

On Sat, Mar 7, 2020, 2:19 PM Spence Konde (aka Dr. Azzy) < notifications@github.com> wrote:

Oooooh! actually checked your link. Yeah, the version of optiboot I am using doesn't have that. I will see if I can steal that bit of code - it doesn't look too hard to add!

Upon doing so, I'd be happy to build a binary with it for you to test (I don't have the tools to test it) - the reset thing will be an issue though. Without figuring out how to deal with that, it will be awkward to use. Maybe I should also increase the time the bootloader runs after reset to 8 seconds?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SpenceKonde/ATTinyCore/issues/393?email_source=notifications&email_token=ABKVCNZZKSZTPUMLNT7E2BTRGLB7VA5CNFSM4LDO6Y7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOEGYZY#issuecomment-596143207, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKVCN23RBZ3MBMPLN2WULLRGLB7VANCNFSM4LDO6Y7A .

SpenceKonde commented 4 years ago

Oh, dang, I was going to do this wasn't I...

On Fri, Mar 13, 2020 at 10:30 PM bzroom notifications@github.com wrote:

Hi Spece,

I was wondering if you had any chance to look at this or if there's anything I can do to help?

Thank you again. :)

On Sat, Mar 7, 2020, 2:19 PM Spence Konde (aka Dr. Azzy) < notifications@github.com> wrote:

Oooooh! actually checked your link. Yeah, the version of optiboot I am using doesn't have that. I will see if I can steal that bit of code - it doesn't look too hard to add!

Upon doing so, I'd be happy to build a binary with it for you to test (I don't have the tools to test it) - the reset thing will be an issue though. Without figuring out how to deal with that, it will be awkward to use. Maybe I should also increase the time the bootloader runs after reset to 8 seconds?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/SpenceKonde/ATTinyCore/issues/393?email_source=notifications&email_token=ABKVCNZZKSZTPUMLNT7E2BTRGLB7VA5CNFSM4LDO6Y7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOEGYZY#issuecomment-596143207 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/ABKVCN23RBZ3MBMPLN2WULLRGLB7VANCNFSM4LDO6Y7A

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SpenceKonde/ATTinyCore/issues/393#issuecomment-598999490, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTXEWYNL6LGYVNE3FMB333RHLT4NANCNFSM4LDO6Y7A .

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: spencekonde@gmail.com

SpenceKonde commented 4 years ago

Support for this added by commit fdf2527fd956d48ffed363b9a9e17b1c9fb0bc78 I put the compiled binaries you requested here (as I said above, compiled "special" bootloaders don't go into master) https://github.com/SpenceKonde/ATTinyCore/tree/rs485bootloader_issue_393/avr/bootloaders/optiboot (the ones with RS485 in the name).

Let me know if they work - I'll build it, but I sure ain't testing it, even if I had the hardware, which I don't. C0 is normally the LED, so built noLED with RS485 on C0 and B3, and with LED on C0 and RS485 on B3. Looks like they fit in the same number of pages as the other version, too, so no need to change boards,txt, just manual flash (ie, "burn bootloader" with normal settings and "verbose upload" enabled, copy the avrdude invocation out of the console window (which will have full path to avrdude and it's config file), change the path of the .hex file to path to the modified one I linked to, and paste into command prompt/etc

bzroom commented 4 years ago

You're the man! I'll test it today.

Thank you.

On Thu, Mar 19, 2020, 12:10 AM Spence Konde (aka Dr. Azzy) < notifications@github.com> wrote:

Support for this added by commit fdf2527 https://github.com/SpenceKonde/ATTinyCore/commit/fdf2527fd956d48ffed363b9a9e17b1c9fb0bc78 I put the compiled binaries you requested here (as I said above, compiled "special" bootloaders don't go into master)

https://github.com/SpenceKonde/ATTinyCore/tree/rs485bootloader_issue_393/avr/bootloaders/optiboot (the ones with RS485 in the name).

Let me know if they work - I'll build it, but I sure ain't testing it, even if I had the hardware, which I don't. C0 is normally the LED, so build noLED with RS485 on C0 and B3, and with LED on C0 and RS485 on it. Looks like they fit in the same number of pages as the other version, too.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SpenceKonde/ATTinyCore/issues/393#issuecomment-601022817, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKVCN3NJEMSDFETV25YLATRIHAO5ANCNFSM4LDO6Y7A .

SpenceKonde commented 4 years ago

standby, i forgot something, it won't work after first upload....

SpenceKonde commented 4 years ago

That was considerably harder than I thought it would be.... I should have just hacked this on, rather than trying to do it more systematically - could have done something more rewarding like... oh... right, we're in the middle of a hundred-year plague and have been ordered to stay at home and leave only for groceries to avoid contracting or spreading it... Maybe that's why I've been spending so much time writing code for other people for free...

They're in here: https://github.com/SpenceKonde/ATTinyCore/tree/rs485bootloader_issue_393/avr/bootloaders/optiboot/special - I built with 2/4/8s timeouts. 1) because by that point, it was trivial to build a couple more, and 2) because I think you're going to find 2S hard to time if using the Arduino IDE to upload.

You wanted active LOW transmitter, right, like that guy's code does? While I was in there, I added an option to invert the logic too (that was easy, compared to how much time I spent fumbling around with the reset cause handling....)

Let me know if they work - That guy's implementation of RS485 will hopefully be good enough to actually work (the question is whether it might start sending too fast - no idea whether it will, only thought of it because the new megaavr parts have hardware support for controlling linedrivers for that, and the datasheet noted that they give 1 bit-time of space on either side of a character, if that phrasing makes sense.

Closing issue, but please do update me here...

bzroom commented 4 years ago

I believe it's almost working.

I suspect i need the transmitter HIGH. I didnt see the transmitter HIGH variants in the special build folder. Could you possibly pretty please build both variations for me?

From the data sheet: https://www.maxlinear.com/ds/sp481e_sp485e.pdf 1 RO Receiver output 2 RE Receiver output enable active LOW 3 DE Driver output enable active HIGH 4 DI Driver input 5 GND Ground connection

I burn the boot loader with this command: C:\Users\matt\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/bin/avrdude -CC:\Users\matt\AppData\Local\Arduino15\packages\ATTinyCore\hardware\avr\1.3.3/avrdude.conf -v -pattiny1634 -cstk500v1 -PCOM16 -b19200 -e -Uefuse:w:0b11111110:m -Uhfuse:w:0b11010110:m -Ulfuse:w:0xE2:m -Uflash:w:C:\tests\ATTinyCore-rs485bootloader_issue_393\avr\bootloaders\optiboot\**special\optiboot_attiny1634_8200000L_RS485_B3_noLED_8S.hex**:i

Then I use USBAsp programmer through rs485 and try to upload a simple sketch i get this output (Somewhat garbled):

`C:\Users\matt\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/bin/avrdude -CC:\Users\matt\AppData\Local\Arduino15\packages\ATTinyCore\hardware\avr\1.3.3/avrdude.conf -v -pattiny1634 -carduino -PCOM17 -b57600 -D -Uflash:w:C:\Users\matt\AppData\Local\Temp\arduino_build_824764/Fade.ino.hex:i

     System wide configuration file is "C:\Users\matt\AppData\Local\Arduino15\packages\ATTinyCore\hardware\avr\1.3.3/avrdude.conf"

     Using Port                    : COM17
     Using Programmer              : arduino
     Overriding Baud Rate          : 57600
     Setting bit clk period        : 5.0
     AVR Part                      : ATtiny1634
     Chip Erase delay              : 15000 us
     PAGEL                         : PD7
     BS2                           : PC2
     RESET disposition             : dedicated
     RETRY pulse                   : SCK
     serial program mode           : yes
     parallel program mode         : yes
     Timeout                       : 200
     StabDelay                     : 100
     CmdexeDelay                   : 25
     SyncLoops                     : 32
     ByteDelay                     : 0
     PollIndex                     : 3
     PollValue                     : 0x53
     Memory Detail                 :

                              Block Poll               Page                       Polled
       Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
       ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
       eeprom        65     5     4    0 no        256    4      0  3600  3600 0xff 0xff
       flash         65     6   128    0 yes     16384   32    512  4500  4500 0xff 0xff
       lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
       hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
       efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
       lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
       calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
       signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

     Programmer Type : Arduino
     Description     : Arduino

avrdude: stk500_recv(): programmer is not responding avrdude: stk500_recv(): programmer is not responding Hardware Version: 4744608 Firmware Version: 58.4611299 avrdude: stk500_recv(): programmer is not responding avrdude: stk500_recv(): programmer is not responding avrdude: stk500_recv(): programmer is not responding Vtarget : 420030.5 V (These values are way wrong) Varef : 0.3 V Oscillator : 921.600 kHz SCK period : 2169635.5 us

avrdude: stk500_recv(): programmer is not responding avrdude: stk500_recv(): programmer is not responding avrdude: stk500_initialize(): failed avrdude: initialization failed, rc=-1 Double check connections and try again, or use -F to override this check.

avrdude done. Thank you.`

If I change the wiring in any way then the output is much less. So i think it is somewhat connecting to the bootloader. But i suspect the issue is the transmitter needs to be HIGH active.

I'm sorry the formatting of this post is out of control. Github really does not like to show avr output.

Also, thank you for your hard work. It sounds like it kind of snowballed. I really appreciate it. Great support. Thank you.

SpenceKonde commented 4 years ago

https://github.com/SpenceKonde/ATTinyCore/tree/specialbootloaders/avr/bootloaders/optiboot/special

There - put it in a new branch (for special bootloaders in general). The ones you want have the _INV in the name.

bzroom commented 4 years ago

It seems to be working. I switched to a max485 breakout with all the passives and it's working.

The weird thing is, this is the one that works for me: optiboot\special\optiboot_attiny1634_8200000L_RS485_B3_noLED_8S.hex

This one does not work for me, even though both rs485 transceivers i'm using say "driver enable active HIGH": optiboot\special\optiboot_attiny1634_8200000L_RS485_B3INV_noLED_8S.hex

I'm not sure whats going wrong. I tried both and the "non INV" one seems to do the trick for me. It's possible that the INV confguration is backwards somehow.

For my purposes I think this issue is closed.

Thank you again. This is an awesome repo you've put together.

bzroom commented 4 years ago

Hi Spence,

Everything is working well. I had a couple quick questions: 1) Have you ever thought about programming multiple devices on the same rs485? :P I was thinking the bootloader could be burned with some device id set. And then when the bootloader is accepting a program, it would only accept programs for a given device id.

2) Is there something preventing Serial.begin() from going over 1,000,000 baud? if i set to 2,000,000 baud then it acts as if i had called it with 1,000,000. There seems to be some kind of clamp in play.

Take care. Hope you are well. Thank you.

SpenceKonde commented 4 years ago

Hi, glad to hear it is working.

This would require significant overhead if the logic was in the bootloader, as well as a modified programming protocol (ie, modified avrdude). This is beyond the scope of my projects. A betterapproach might be if you could have the non-bootloader code detect this and do a software reset - but this is problematic on non-megaavr parts, as the only means available for this, short of hardware solutions to inject a pulse on reset pin is a watchdog reset - but that is also what is used to generate the timeout for optiboot, so it cant tell if it should run the bootloader or jump to app. The new megaavr parts (see megaTinyCore) have a software reset command, so this scheme would work there; they also have hardware rs485 support.
The maximum baud rate on an avr microcontroller is 1/8th the system clock - 8 samples per bit are required, and UBRR =0 means 1 sample per system clock. Note also that at high speeds the choice of baud rates is very limited - the next slowest is 500000 baud (UBRR=1) - anything between those wont work. I belive this situation is also much improved by the fractional baud rate generator on the new megaavr parts, though the maximum is still there.

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: spencekonde@gmail.com

On Wed, Apr 15, 2020, 01:32 bzroom notifications@github.com wrote:

Hi Spence,

Everything is working well. I had a couple quick questions:

1.

Have you ever thought about programming multiple devices on the same rs485? :P I was thinking the bootloader could be burned with some device id set. And then when the bootloader is accepting a program, it would only accept programs for a given device id. 2.

Is there something preventing Serial.begin() from going over 1,000,000 baud? if i set to 2,000,000 baud then it acts as if i had called it with 1,000,000. There seems to be some kind of clamp in play.

Take care. Hope you are well. Thank you.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/SpenceKonde/ATTinyCore/issues/393#issuecomment-613825819, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTXEW2QGRB6ZLDJNVXBD3TRMVBGJANCNFSM4LDO6Y7A .

bzroom commented 4 years ago

Thank you for the great answers.

Would it be possible to port the rs485 boot loading feature to the megaTinyCore? I hate to ask. :(

I wish I had known about megaTinyCore before I started my build. Now i am thinking about changing to attiny1616 (megaTinyCore), because it can run at 16mhz internal vs the 8mhz internal I have now. That should unlock 2Mbps for me.

Misc note about how I'm rs485 programming and power-on-reset. I am using the 8 seconds delay but, I think it can be much lower, maybe 0.

Steps to program:

Disconnect power to the target
Hit upload in the IDE
Wait until i see the programmer output (it's orange. avr stuff)
Then I connect power to my target mcu.

It appears that the bootloader sends some kind of signal on power-on which triggers the programming immediately. It's like the programmer is waiting for a response, and the bootloader sends that response immediately on power-on, and the programming happens immediately. I don't have any issues with timing when I do it that way.

Thank you!

SpenceKonde commented 4 years ago

Yes, the RS485 could be ported to megaTinyCore - would actually be a lot easier there, because there's hardware support. The pin for this is fixed (PB0 with default UART mapping). It's a better implementation too - it has a one-baud-period "guard bit" in case the transmitter has non-zero response time)

The delay cannot be 0. The response time may be very fast, but it is not instant; that "delay" is the WDT timeout used (this is what is used to time-out the bootloader, after which it resets, and the bootloader sees that it was a WDT reset, with PORF still set, it knows that this implies that the bootloader previously ran and timed out, and thus turns off WDT and jumps to application) It can of course be made shorter, but not zero.

I'm not sure what's happening behind the scenes - unless something is buffering the bits until it knows the device is connected (ie, by watching for RX being held high or something), it will not start programming until the programming system sends the command to initiate the programming process again. The bootloader doesn't send anything until it receives a command.

bzroom commented 4 years ago

For the Attiny 1634, 8mhz internal > 4v (running at 5v).

Is there any chance the rs485 bootloader would have timing issues?

If i load my sketch onto the mcu using the isp, "upload with programmer". The rs485 communication looks good up to 1mbps. But when I try to connect to the bootloader, the bootloader will get partway into the "writing" stage. and then stop. One time it stopped in the reading.

I remember you being surprised if it worked, and I was wondering what that was specifically and how I can test it.

Thank you again.

Is buying one of the boards the best way I can contribute to the project?

bzroom commented 4 years ago

If the reset pin is pulled to 5v through a 10k resistor, will that affect the power-on-reset and skip the bootloader?

SpenceKonde commented 4 years ago

Re: POR delay: No, the way it works when set to run at power on reset is by checking the POR bit in MCUSR. All we can do is make the wait shorter.

Oh - interesting.... Have you confirmed 100% success with 1mbps? Never a dropped or mangled character? And with the transmitter and sender trading off between send and transmit?

Also, my god that is a demanding transfer rate - may I ask what it is that leads you to require such a high transfer speed?

One thing that I think is a potential issue is that the bootloader asserts the direction pin almost immediately before each character, and then unasserts it - even if it might, almost immediately, reassert it. This differs from what your sketch probably does, in that I assume if sending a bunch of data, you'd set the dir pin, probably wait a short time, then start sending with it asserted the whole time. The fact that there is basically no delay between asserting the pin and starting the transmission is the part that worries me, here - not that it's constantly turning it on and off. This could probably be fixed with a short delay (the "Modern AVR" parts, like the ones that megaTinyCore supports, do have hardware support for a direction pin, and assert it one bit period before starting transmission - that sounds safe) , but doing that in a flash efficient way without that hardware support could be tricky - or maybe it wouldn't be; the main catch is that... I'm a bit busy at the moment (see below)

We're actually going to be launching a Patreon in the near future (the branded t-shirts for the cover photo have been delayed, but luckily the product and core launch that it is to coincide with are ALSO behind schedule, so I'm not nearly as pissed as I would have been (considering that I chose them explicitly because of their promised ship time - "rushordertees" is their totally inappropriate name, if you ever need custom printed t-shirts in a hurry, like, don't use those guys) - the core launch and accompanying breakout boards, I'm hoping, will generate enough buzz to help get some people checking it out. Meanwhile, a friend of mine is going to help me out with this thing called "Twitter" which apparently people are supposed to be using too.

The perks offered on Patreon will include varying levels of enhanced support - and one of those will include.... building custom bootloaders, as well as greater willingness to add features that can't or shouldn't go into main release. Also (more expensive) options targeted at people actually selling products based on these, who want hardware design reviews and that kind of thing... So that would be the best way to support the project. Especially since you seem to, ah, want one of the perks I am planning to offer (note that you're not the only one I've build bootloaders with weird options for). Of course, buying boards on Tindie is great - but if you're just doing it to support the project and the board will gather dust, that seems a bit silly, especially since boards are not pure profit - they take parts and labor. At some point I thought I'd had a paypal donate link somewhere, but I think that it may have been removed some time a while ago,...

bzroom commented 4 years ago

I'll be happy to sign up for your patreon and bootloader support when its available. :) in the meantime i'm trying to get a scope on the lines to figure out where exactly the issue is.

I'm reading remote analog signals trying to get high-ish bandwidth measurements.

I'm definitely interesting in looking at the mega-core. I dont think it has rs485 bootloader support right now. Also the reset pin thing was kind of alarming about the mega tiny core.

SpenceKonde commented 4 years ago

The reset pin thing is very unfortunate - though in your case, you don't need to use that pin as reset, even - if you have it starting only on POR, you could just rely on that and leave it as reset - you could also send it a command over serial, and have it react to that with a software reset, which will also run the bootloader (this presents the possibility of sending a command to reset, rather than powercycling!)

No RS485 bootloader support right now, though comparatively easy to add. Only one pin can be used - it's PB0 with default pins for Serial, PA4 in the alternate locations.You could also, if you chose to, use the hardware RS485 mode from sketch too, but if you're sending multiple bytes at a time, it might be faster to keep doing what you're doing.

Oh, and you can run the Modern AVR parts (I'm using that term because I discovered that "megaavr" as used in a lot of places in my doc and in arduino-land is not an official term according to microchip for these parts - in fact, "megaAVR" in it's official usage, it refers to any ATmega device) at 20MHz, not just 16 - so 2.5mbaud is theoretically achievable. Did you see the recent update to improve ADC read speed on megaTinyCore? Also describes a way to make analogRead() even faster, as long as the thing you are reading is either low impedance or you're just repeatedly reading the same thing. Oh, and on the 1614 (1-series parts with 16k or more of flash), they also have a second ADC (which the core doesn't bother with, because it's not very helpful in the paradigm of analogRead(), but would be great to put in free running mode (either with ADC0 also in that mode, or with ADC0 being used for analogRead() of some other analog signal. in the normal way. Cool stuff - I haven't had time to play wih it at all though

bzroom commented 4 years ago

My concern with the modern reset pin is I know in some rare cases the bootloader needs to be reprogrammed. If the pin is configured to reset and the bootloader is lost somehow. How is it recovered?

I'm considering designing a new board around the modern mcu in the future, but I'm pretty invested in this Attiny1634 build.

I'm ready to fully build out the project, but I'm struggling with the final integration testing of the bootloader. On the breadboard, and the first board i built it, worked fine. But each board after that has struggled with the bootloader. If I use the ISP, the rs485 in my sketch seems very stable. I havent tested that it's 100%, but I haven't noticed any errors.

I've probed all the lines and scoped the signals. Everything seems reasonable. I am using the 8mhz >4v internal oscillator i know can be risky for serial timing and could explain the difference between boards, but I think at the 57600 bootloader baud, oscillator error shouldn't be a problem.

In my sketch i'm not explicitly using any delay but i suspect the code causes enough delay to be sufficient: #define transmission(x) digitalWrite(rs485Transmit, HIGH); x; digitalWrite(rs485Transmit, LOW); transmission(Serial.println("data: " + String(data, DEC)));

I know this is not a robust packet protocol. :) Just testing at the moment.

bzroom commented 4 years ago

I was looking at the code, could it just be a couple calls to uartDelay() before the rs485 pin is asserted in optiboot? https://github.com/SpenceKonde/ATTinyCore/blob/4470b8a82a8179fb2e769dbc6f3937ed4d81cf71/avr/bootloaders/optiboot/optiboot.c#L1038

I might try to setup a build environment since I keep asking for little tweaks.

SpenceKonde commented 4 years ago

How would the bootloader be recovered? Well - for one thing, unlike the 1634, the bootloader on the 1614 is properly supported in hardware, so the bug that can kill the bootloader on a 1634 isn't present (though Bill Westfield suggested a clever way to fix it without even modifying the bootloader or the sketch, just by uploading a "safety shim" ahead of the actual sketch). It is very hard to actually break the bootloader on a chip that has hardware bootloader support. I am convinced that, if this can ever happen, it is extremely rare - the bootloader is not allowed to scribble over itself, or to anything that would change the boot process. Nobody has ever posted a dump of the flash contents of a chip with hardware bootloader support where the bootloader became "corrupt". Until I see a flash dump of a chip that used to have a working bootloader, which now does not, I maintain of the opinion that this is a myth, That said, if it is desired to change the fuses, or upload a different bootloader, well, that would be a problem (I just shipped out a replacement the other day for a board where I'd burned bootloader with UPDI as reset and set the BOD fuses wrong) - some people are working on a cheap HV programming tool (it's apparently not that hard) to reset the pin to UPDI - this is on my list too, but god only knows when I'll get a chance to look at it.

But why would you even need to turn the UPDI pin into reset? Right now you're powercycling it you said? Plus there is software reset, or setting interrupts on other pins to do a software reset... everyone would rather a hardware reset, of course, but it's not as indispensible as one thinks.

That's very strange, what you describe, though - Are you sure that the voltages they're getting are the same between when testing bootloader and testing communication while running sketch? (the speed to voltage curve is quite steep around there) If you can, at least for testing, I would be tempted to upload 8MHz bootloader, everything else same, and run it off 8MHz crystal, thus eliminating any chance that it could be a speed thing (say, you didn't previously have 1634R and now using plain 1634, are you? The R has a better-calibrated oscillator....

Re uartDelay() from other email - is that function even available for hardware serial builds?

In any event, I won't get to look at this for a few days - I really need to focus on a few more pressing matters that I've fallen way behind on...

On Sat, May 2, 2020 at 10:20 PM bzroom notifications@github.com wrote:

My concern with the modern reset pin is I know in some rare cases the bootloader needs to be reprogrammed. If the pin is configured to reset and the bootloader is lost somehow. How is it recovered?

I'm considering designing a new board around the modern mcu in the future, but I'm pretty invested in this Attiny1634 build.

I'm ready to fully build out the project, but I'm struggling with the final integration testing of the bootloader. On the breadboard, and the first board i built it, worked fine. But each board after that has struggled with the bootloader. If I use the ISP, the rs485 in my sketch seems very stable. I havent tested that it's 100%, but I haven't noticed any errors.

I've probed all the lines and scoped the signals. Everything seems reasonable. I am using the 8mhz >4v internal oscillator i know can be risky for serial timing and could explain the difference between boards, but I think at the 57600 bootloader baud, oscillator error shouldn't be a problem.

In my sketch i'm not explicitly using any delay but i suspect the code causes enough delay to be sufficient:

define transmission(x) digitalWrite(rs485Transmit, HIGH); x;

digitalWrite(rs485Transmit, LOW); transmission(Serial.println("data: " + String(data, DEC)));

I know this is not a robust packet protocol. :) Just testing at the moment.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/SpenceKonde/ATTinyCore/issues/393#issuecomment-623043510, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTXEW7S2H4GA5XVH4SPAUDRPTIFNANCNFSM4LDO6Y7A .

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: spencekonde@gmail.com

bzroom commented 4 years ago

Thanks for the feedback. Right now i have the reset pin tied to the power supply "power good" line. so if the power were "not good" it would hold the mcu in reset. I could probably use the onboard brownout detection instead. It sounds like it's best to leave that pin as a programmer. Only use software reset and internal BOD.

Regarding comparing bootloader to communication test: The bootloader is only running at 57600 I believe.* This should be more tolerate of voltage swing right?

I was able to get the optiboot build setup on my machine and make some changes, build a hex, and use it as a bootloader. The delay did not necessarily seem to help but i picked the delay time ...arbitrarily.

I should probably make a pull request but mainly I moved the uartDelay() out: ` // This value is probably not right

define UART_B_VALUE (((F_CPU/BAUD_RATE/16)))

void uartDelay() { asm volatile ( "ldi r25,%[count]\n" "1:dec r25\n" "brne 1b\n" "ret\n" ::[count] "M" (UART_B_VALUE) ); }`

And added the delay calls here: ` void putch(char ch) {

#ifdef RS485
   uint8_t x;
  do {
    x = UART_SRA;
  } while (!(x & _BV(UDRE0)));
  // clear transmitted flag
  x |= _BV(TXC0);
  UART_SRA = x;
  // put transceiver to output mode
  #ifdef RS485_INVERT
  RS485_PORT &= ~_BV(RS485);
  #else
  RS485_PORT |= _BV(RS485);
  #endif

  // short delay
   uartDelay();

  // put char
  UART_UDR = ch;
  // wait for char transmitted
  while (!(UART_SRA & _BV(TXC0)));

  // short delay
  uartDelay();

  // put transceiver to input mode
  #ifdef RS485_INVERT
  RS485_PORT |= _BV(RS485);
  #else
  RS485_PORT &= ~_BV(RS485);
  #endif

Still working on it though. :)

*Allegedly the arduino boot uses a slightly different baud rate but I dont think that's related here. https://github.com/PaulStoffregen/Teensyduino_Examples/blob/dc5f0e110cf367aa026e6b08715579be2048f619/USB_Serial/USBtoSerial/USBtoSerial.pde#L94

I am not using an R unfortunately. I wish I had caught that earlier and I'll look into. I just bought 20 1634's :)

I can try the oscillator but on the breadboard the circuit was working strong. Only on the fully baked pcb the rs485 started to breakdown when using the bootloader. It could entirely be my fault. I'll keep digging. I dont want to bug you. I appreciate all your responses.

bzroom commented 4 years ago

The bootloader is working again. :)

Didnt work: I tried the delay in putch. That didnt help. I tried the "transmission macro" and wrapped it around all streams of putch, with delay. That didnt help. I watch byte streams out of working device and non-working on the oscilloscope and they were nearly the same. (Photos attached)

Did work: I tried building the bootloader with baud 58824 based on Paul's comment here: https://github.com/PaulStoffregen/Teensyduino_Examples/blob/dc5f0e110cf367aa026e6b08715579be2048f619/USB_Serial/USBtoSerial/USBtoSerial.pde#L94

It's now working across all my hardware so far. I will dig more into the code changes to see if the delays are necessary or if merely the baud change fixed it. But I'm happy for now and gonna build out some more boards!

It does give this warning: optiboot.c:397:6: warning: #warning BAUD_RATE off by greater than 2% [-Wcpp] but seems to work. I wonder if it had anything to do with the 8mhz >4v setting.

To test the oscillator accuracy i used the scope:

Before the baud change, here's a 1mbps byte stream out of the device with working bootloader: 72.2khz byte peaks (This one was using a linear regulator with 5v in and out so theres some voltage drop happening here. But oddly this one worked.)

char bytes[] = { 255, 255, 255, 255 };
transmission(Serial.write(bytes, 4));

char bytes[] = { 85, 85, 85, 85 };
transmission(Serial.write(bytes, 4));

(

And the one who's bootloader was not working: 70.5khz byte peaks

So they did have slightly different oscillator frequencies which could explain why one was working and not the other. I'm going to build out a few more boards and ensure it's working across a larger range of devices.

Thank you so much.

I'm still gonna buy your patreon/donate/merch. :)

bzroom commented 4 years ago

Things have been going well. I added an oscillator to my circuit so i'll be testing with that soon.

I'm curious, is it possible to brick the 1634 with optiboot while burning the bootloader?

It seems like sometimes during programming it will say "this fuse has changed, do you want to set it back?" and when that happens, it seems like the device is likely bricked and cannot be burned or programmed again. Usually when i see that error, about the fuse value changing, i try to disconnect power and cancel the programming command and sometimes it can be recovered, but other times it seems like when i see that then the device is bricked and cannot be bootloaderburned with the ISP again.

This device was working fine then i went to try a new version of the bootloader. Got the fuse message, and now it will only ever say this when i try to burn the bootloader:

C:\Windows\System32>C:\Users\matt\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/bin/avrdude -CC:\Users\matt\AppData\Local\Arduino15\packages\ATTinyCore\hardware\avr\1.3.3/avrdude.conf -v -pattiny1634 -cstk500v1 -PCOM16 -b19200 -e -Uefuse:w:0b11111110:m -Uhfuse:w:0b11010110:m -Ulfuse:w:0xE2:m -Uflash:w:tests\ATTinyCore-specialbootloaders\avr\bootloaders\optiboot\special\optiboot_attiny1634_8200000L_RS485_B3_noLED_8S.hex:i

     System wide configuration file is "C:\Users\matt\AppData\Local\Arduino15\packages\ATTinyCore\hardware\avr\1.3.3/avrdude.conf"

     Using Port                    : COM16
     Using Programmer              : stk500v1
     Overriding Baud Rate          : 19200
     Setting bit clk period        : 5.0
     AVR Part                      : ATtiny1634
     Chip Erase delay              : 15000 us
     PAGEL                         : PD7
     BS2                           : PC2
     RESET disposition             : dedicated
     RETRY pulse                   : SCK
     serial program mode           : yes
     parallel program mode         : yes
     Timeout                       : 200
     StabDelay                     : 100
     CmdexeDelay                   : 25
     SyncLoops                     : 32
     ByteDelay                     : 0
     PollIndex                     : 3
     PollValue                     : 0x53
     Memory Detail                 :

                              Block Poll               Page                       Polled
       Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
       ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
       eeprom        65     5     4    0 no        256    4      0  3600  3600 0xff 0xff
       flash         65     6   128    0 yes     16384   32    512  4500  4500 0xff 0xff
       lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
       hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
       efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
       lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
       calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
       signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

     Programmer Type : STK500
     Description     : Atmel STK500 Version 1.x firmware
     Hardware Version: 2
     Firmware Version: 1.18
     Topcard         : Unknown
     Vtarget         : 0.0 V
     Varef           : 0.0 V
     Oscillator      : Off
     SCK period      : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.07s

avrdude: Device signature = 0x000000 (retrying)

Reading | ################################################## | 100% 0.06s

avrdude: Device signature = 0x000000 (retrying)

Reading | ################################################## | 100% 0.07s

avrdude: Device signature = 0x000000 avrdude: Yikes! Invalid device signature. Double check connections and try again, or use -F to override this check.

avrdude done. Thank you.

I think this is the last message before it died: optiboot\special\optiboot_attiny1634_8200000L_RS485_B3_noLED_8S.hex contains 16384 bytes avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.04s

avrdude: verifying ... avrdude: verification error, first mismatch at byte 0x3d80 0xc0 != 0x01 avrdude: verification error; content mismatch

avrdude: safemode: lfuse reads as 0 avrdude: safemode: hfuse reads as 0 avrdude: safemode: efuse reads as 0 avrdude: safemode: lfuse changed! Was e2, and is now 0 Would you like this fuse to be changed back? [y/n] ^C

bzroom commented 4 years ago

Sorry for the confusing updates. I believe the problem was the oscillator (I wasn't using 1634R).

Now I'm using a 16mhz external oscillator now and it's pretty solid. Here is a conversation at 2Mbps. (got a new scope too haha)

I'm using the bootloader as is. No adjustment needed to the timing. Sorry about the false alarm.

Thank you again.

SpenceKonde commented 4 years ago

Oh screw you! You got the 4-channel one?! (I have the SDS1202x)

SpenceKonde commented 4 years ago

Anyway, glad it's sorted - I am a firm beliver in external crystal whenever you do UART comms.

bzroom commented 4 years ago

Now I am too. Feel free to add me to the wall of victims of the internal oscillator.

This is a nice scope but it's way over kill for me. I ordered a ds213 but it never came so I got this one.

On Sun, May 24, 2020, 4:28 AM Spence Konde (aka Dr. Azzy) < notifications@github.com> wrote:

Anyway, glad it's sorted - I am a firm beliver in external crystal whenever you do UART comms.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SpenceKonde/ATTinyCore/issues/393#issuecomment-633216846, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKVCN3NYFGXAUR3SBP5ZF3RTEAEBANCNFSM4LDO6Y7A .