ATtiny40 and avr-g++/gcc

Go To Last Post
31 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm using avr-g++ (4.9.2) on Linux on a ATtiny40 and am convinced there is something fundamentally wrong with either the support for ATtiny40 ICs in this compiler version, the specific IC I am using, or the ATtiny40 in general.

 

Is anybody using a similar configuration with a ATtiny40 with a non-trivial build reliably?

 

I've previously been using an ATtiny84A with a cross-platform codebase (ARM and AVR) and it's been working fine.

 

I've had no end of problems trying to port it to an ATtiny40. Certain images when flashed appear to not start at all, and others work fine, with seemingly small changes determining whether it will work or not:

 

- Switching between -Os and -O.

- Calling the exact same function one more time than usual. For example a bit-bang SPI-style send called ten times works fine, but eleven times fails.

- The number of exported symbols in a certain file going beyond a certain number (eg. I can include functions A and C, A and B, B and C, but not A, B, and C- even if I never call them).

- I don't believe it's related to stack size but can't be sure. My program RAM usage is obscenely low (<16 bytes) so I don't think so.

- It isn't program size. I've had 3K programs work, and 512b programs fail.

- I've tried all-in-once style builds versus the usual linked ones. Doesn't seem to make it worse or better, but can break a working program, or make a broken one work.

- Bits of code that follow different paths to the same result can have different outcomes.

- The same program flashed multiple times tends to either work or not, ie. it almost always works, or always fails. It generally isn't random, but seems to be based off the particular image that I have built.

 

I haven't been able to get a stable tracewrites working (this is the bit of code giving me hassle), and I can't guarantee whether setting an output on a pin is even going to work in any build, which is making it hard to diagnose.

 

I can't put together a minimal example that breaks it, but have generated many examples using the existing codebase that will break/fix with a trivial change that should make no difference (eg. toggling pins that were just toggled previously). I realise this means I can't eliminate potential fault in the existing codebase, but I have run into problems with so many changes in unrelated areas that should have done nothing that caused the image to fail to work that this is unlikely to be the sole cause. This is especially true with the same code running fine on an ARM and an ATtiny84A with no hassle.

 

It is really starting to look like an IC fault or the compiler is simply not capable of building reliably for the IC. The former seems possible as the behaviour is consistent with parts of the flash being faulty. The latter seems possible as it seems certain combinations of code, rather than the nature of the code itself, determines whether a working build will run. I'd like to figure out which is the case.

 

So... is anyone else having luck with this combination? Is the ATtiny40 just awful, is the compiler support incomplete, or is my specific IC bad? Am I the only one trying to work with it with avr-gcC? Please let me know if you've had better luck than I, and how your setup compares to mine.

 

Just a note for anyone considering using an ATtiny40:

 

- It uses TPI, which is just awful to work with. I had no idea TPI even existed. What a way to learn.

- No serial programming.

- No self-programming. Don't be fooled by the mention of "Self programming" in the datasheet. All that section says is that it is unsupported.

- It is seriously picky about programming voltage. I've had repeated failures with flashing using 5V through a Schottky, that were solved by removing the Schottky.

- avrdude with linuxgpio doesn't support TPI.

  - not even the latest version, hand-built.

  - there are some non-merged patches (davidm) out there that apparently supports it

  - they don't apply to the latest version.

  - when fixed, they don't actually work.

  - almost nobody seems to be using them. Searching for common error messages yields almost no results.

  - no luck even when using dedicated Pi pins and detached from the whole prototype.

  - even with the suggested resistor (which, let's be honest, is obviously a hack).

  - I was forced to revert to using a generic AVRASP, which with some struggling re voltage, could be made to work.

- No EEPROM. It's one of the few chips with *none*.

- You can probably forget about in-system programming with the need for dedicated hardware and the voltage pickiness, unless you happen to be running at 5V already.

 

And before someone suggests the 1634: That is an excellent suggestion. I almost went with it instead. Knowing what I do now, I would choose it over the 40. I really, really wish that I'd gotten one instead or at the same time as the 40. I only really need about 1K flash, so the 1634 seemed like overkill, but it's all down to the peripherals and hardware functionality.

 

Last Edited: Mon. Oct 2, 2017 - 10:09 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Which avr-g++ is this? Hopefully "Atmel toolchain for Linux" from atmel.com ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Which avr-g++ is this? Hopefully "Atmel toolchain for Linux" from atmel.com ?

 

Here's a familiar face. :)

 

Re avr-gcc, I'm afraid not. Debian Linux Stretch default avr-gcc.

 

Which I suspect is not the correct answer.

 

A quick search suggests the hounds might be about to be released on me. Should I seek refuge over here:

 

http://www.atmel.com/tools/ATMEL...

 

?

 

I'm just awaiting the confirmation email so I can download their offering. I'd make an account but their "Log in" link has never worked for me so I have to download as a guest each time, which means waiting for a confirmation email each time.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Atmel do, slowly but surely, push their "new device" work back from their "private branch" of GCC into the mainstream so your Debian build *might* be inline with their most up to date support. But I would suspect not. In which case getting it form the "horses mouth" probably makes sense.

 

One day there may be a future where Atmel/Microchip work directly on the GCC mainline and add "new device" support there directly. I believe that's what this whole "DFP" (Device Family Packs) thing is all about. But until then their branch is always going to be in advance (for devices in the last few years) of the FSF mainline.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Atmel do, slowly but surely, push their "new device" work back from their "private branch" of GCC into the mainstream

 

 

Huh, am I missing something?  My impression is, that since introduction of specs files, their inclination to push device support upstream has declined.

avrfreaks does not support Opera. Profile inactive.

Last Edited: Mon. Oct 2, 2017 - 06:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

..and on-topic:

 

Seems you are drowning in a sea of confusion, and therefore it's had so say anything specific or remote-diagnose your problems.

 

If you have a version that is NOT working, stay with that and try to locate the bug.  Switching back and forth, adding and removing source lines and popping the problen into and out of sight, will only add more of confusion.

 

My impression is that avr-gcc doesn't have much of reduced Tiny coverage; most users stick to asm or stick with "reasonable" cores.  As you are unter Linux, you can try to re-build the tools from source, e.g GCC v7.2, Binutils 2.29 and AVR-Libc trunk.  They should work find, support ATtiny40 without extra additions, and are stable (modulo small redTiny coverage).  Moreover, the newer compiler versions generate slightly better code, but still light years worse than experiences asm progger due to the crippled addressing modes...
 

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay, I've got a bit more information now. I am now 99% sure that it isn't a code problem.

 

While experimenting with the ATtiny40 I added a large number of #define options that move code around, changed how things work, and reorganised code structures. For example: I usually use a definition structure with my tracing library to provide calls to set outputs. One define I've added removes that code entirely, and replaces it with a set of defines. I've added in code that avoids memcpy, mutexes, changes the way data is sent, added multiple entry points to the transmission code (via a buffer, direct, etc), added some specific buffer tests. And so forth. As you can imagine, the particular combination changes the way it behaves massively, especially once you add optimisation into the mix, but the end result should be the same. This has been set up with a minimal test environment that does nothing but call into this library.

 

On the ATtiny40 it was extremely finicky about the particular combination used, and I usually had to tweak a few lines to get it to run at all. Well, I've finished moving my project back to an ATtiny84A. I've tried multiple combinations of the new options I've added, and every single combination worked perfectly, first time, no tweaking. I simply can't break it, no matter the combination of options I choose. The main project that uses this code also built fine and worked first time.

 

Size is no issue:

 

   text       data        bss        dec        hex    filename
    616          0         11        627        273    namehere.elf

 

Also, no asm in sight. C/C++-only.
    
So I'm on to chip fault (specific or general) or compiler shortcomings for the architecture.

 

clawson wrote:
Atmel do, slowly but surely, push their "new device" work back from their "private branch" of GCC into the mainstream so your Debian build *might* be inline with their most up to date support. But I would suspect not. In which case getting it form the "horses mouth" probably makes sense.

 

Thanks. I hadn't realised they actually supplied a viable Linux toolchain. When I was working on ATmegas I never really saw a reason to branch out from the distro avr-gcc, and when I dusted off my AVR knowledge and popped in the 84A I was quite fine with it as well. The 40 was the first AVR to actually give me significant problems.

 

This:

 

https://en.wikipedia.org/wiki/At...

 

Suggests a 2010 release for ATtiny40. avr-gcc suggests a 2014 release (that's shocking for a 2017 distro). But in any case, that's four years. But there are a lot of architectures, and it simply may not be well supported. Perhaps nobody uses it with my toolchain. The lack of support for the ATtiny40 in avrdude suggests that it might not be a popular IC for my toolchain. In any case I hadn't realised there was a viable build alternative, so I'll be testing this when the opportunity arises. It should narrow down where the fault is.

 

clawson wrote:
One day there may be a future where Atmel/Microchip work directly on the GCC mainline and add "new device" support there directly. I believe that's what this whole "DFP" (Device Family Packs) thing is all about. But until then their branch is always going to be in advance (for devices in the last few years) of the FSF mainline.

 

I couldn't find much information about DFPs in GCC, is this something happening on Atmel's branch?

SprinterSB wrote:
Seems you are drowning in a sea of confusion, and therefore it's had so say anything specific or remote-diagnose your problems.

If I can't get a minimal test program that demonstrates the problem in isolation that I can supply, it's going to be too hard for anyone to help. The best I can manage is a flaky setup using a small subset of the library I am using, and that is not going to be something that can be shared easily. So I am settling for gathering information on the environment to see if that gives me any leads. I appreciate that you're trying to figure out the best way to assist in this way though. :)

 

SprinterSB wrote:
If you have a version that is NOT working, stay with that and try to locate the bug.  Switching back and forth, adding and removing source lines and popping the problen into and out of sight, will only add more of confusion.

 

Thanks for the suggestion. I've tried this, from multiple starting configurations. I can't trust the outputs, the problem manifests in my trace library, no functioning debugger, and benign code changes that should not change the result do. I've done some pretty brutal debugging tasks in my career and have successfully tracked down genuine compiler bugs. The code in use is stable across multiple configurations, including across multiple ARM chips (Atmel SAM, once did  STM32 too) and the ATtiny84A. The current environment is too unstable to be viable. I'm at the point where the bigger options come into play, ie. solder a different ATtiny40, try a new toolchain, build my own toolchain (as you suggest below) or try another architecture (I'll probably order a 1634, 48/88, and/or dig out an ATmega328* I've almost certainly got lying around somewhere). Each should give me a clue as to where to look next. On a side note, don't the ATtiny*8s look awfully like the ATmega*8s? I swear one inspired the other.

 

SprinterSB wrote:
My impression is that avr-gcc doesn't have much of reduced Tiny coverage; most users stick to asm or stick with "reasonable" cores.  As you are unter Linux, you can try to re-build the tools from source, e.g GCC v7.2, Binutils 2.29 and AVR-Libc trunk.  They should work find, support ATtiny40 without extra additions, and are stable (modulo small redTiny coverage).  Moreover, the newer compiler versions generate slightly better code, but still light years worse than experiences asm progger due to the crippled addressing modes...

 
I've been down the build-a-cross-compiling-GCC path before, and it's pretty rough. It's an option though, and thankyou for the suggestion.

 

My experience with the 84A I just had lying around was quite positive. I have had issues with it in the past, but my task is much simpler this time and the limitations less restrictive. I'm beginning to suspect that the reduced-core ATtinys (eg. ATtiny20/40) might not be worth the pain, but I can't say that for sure quite yet.

 

Last Edited: Mon. Oct 2, 2017 - 10:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does it work with -O1 ?

International Theophysical Year seems to have been forgotten..
Anyone remember the song Jukebox Band?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

garthyd wrote:
SprinterSB wrote: If you have a version that is NOT working, stay with that and try to locate the bug. Switching back and forth, adding and removing source lines and popping the problen into and out of sight, will only add more of confusion. Thanks for the suggestion. I've tried this, ...

 

I realize from the rest of your explanation that this is a full "library" of stuff.

 

But it might have my interest more, and I'd guess for the gurus as well, if you narrow down a problem situation to a [hopefully] small complete test program that we can all build and examine.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

skeeve wrote:
Does it work with -O1 ?

 

Changing optimisations can change the result. Sometimes it causes a working program to fail, sometimes it causes a failing program to work. So: Yes, sometimes, for certain configurations; and No, it actually breaks it, for certain configurations. But ultimately: No, it still does not give me a reliable build.

 

A good suggestion though. I know there are parts of the avr-libc library that are dependent on optimisation settings.

 

theusch wrote:
I realize from the rest of your explanation that this is a full "library" of stuff.

 

I've got the library down to a subset, and even made changes so that the whole body is #included into a single file that is built directly as an option. I can't put together a minimal example that breaks it from the ground up.

 

theusch wrote:
But it might have my interest more, and I'd guess for the gurus as well, if you narrow down a problem situation to a [hopefully] small complete test program that we can all build and examine.

 

Thanks for the suggestion. :) This is the path I would prefer to follow, but I ran into problems. I have not been able to create a minimal test program that demonstrates the problem in isolation in a form that I can supply. I realise this means it is hard for anyone to help directly. I am settling for gathering information on the environment to see if that gives me any leads for the time being.

 

I do have one option that could produce such a test: Establish a program that won't run. Manually copy in the bodies of all of the included files, directly and indirectly, into a single file. Confirm it fails. Continually strip out code and manually apply preprocessor actions (ie. strip out dead code based on the known set of enabled macros), ensuring that it continues to fail. Try to extract everything I'm not comfortable sharing yet. Repeat until the code is as small as possible while still failing. This will be difficult as some changes that should cause no issues will. At the end it might have me sharing more code than I am comfortable sharing at this point, or be too large to be of interest to anyone for analysis. Although regardless of size, I'm sure someone will try to compile it on their setup and report on the results. Putting something like this together will be a slow, tedious process, and has many undesirable downsides. So this won't be my first option, but it might be something I can do once I've tried some other things.

 

I have a 1634 and 88 on the way and I should hopefully have in my hands and set up for use in the next few days. I already have a mostly-complete 1634 build, just nothing to test it on yet. A working 84A is nice, but knowing what happens with an 88 and a 1634 would give some clues. Will they both fail like the 40? Both work like the 84A? Each suggests a different type of problem. Suppose the 1634 works beautifully. Am I prepared to pay 20c extra per unit to have included EEPROM and self-programming, extra flash and SRAM, plus make the problems I've been encountering go away instantly? You bet I am. :)

 

I also want to try clawson's suggestion too, not just for this problem, but to evaluate it in general.

 

I'll post updates when I know more. I might be able to supply a reduced program that fails to run, depending on how the other options go.

 

Last Edited: Tue. Oct 3, 2017 - 10:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> I know there are parts of the avr-libc library that are dependent on optimisation settings.

 

No.  A library is a bunch of already compiled binary code, and this isn't affected by optimization settings at link time (because optimization flags are no multilib options, as opposed to -mmcu= which will select a different library incarnation).

 

Some of avr-libc sources use different approaches depending on optimization settings, but these will affect at build time of avr-libc, i.e. when you (re)build avr-libc with different CFLAGS or ASFLAGS.

 

Headers of avr-libc that can be included in application code are included and compiled at compile time as part of the application, of course.  delay stuff in one example.  But the vast majority of avr-libc is shipped as static library.
 

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB wrote:

> I know there are parts of the avr-libc library that are dependent on optimisation settings.

No.

 

My statement is not incorrect and does not need correction. It certainly does not warrant a one-word dismissal.

 

Confirmation of the effect of optimisation on delay.h in avr-libc can be found here:

 

http://www.nongnu.org/avr-libc/u...

 

Specifically:

 

"In order for these functions to work as intended, compiler optimizations must be enabled,"

 

However, if what I said was interpreted as strictly referring to the collection of object code in the library to the exclusion of the headers, then I could see how it would appear to be incorrect. Confusingly, this collection is *also* referred to as a library. However, I do not think it a reasonable assumption to assume that this is what was meant in this context.

 

For clarity I refer to the avr-libc library as a whole.

 

Last Edited: Wed. Oct 4, 2017 - 07:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

garthyd wrote:
It certainly does not warrant a one-word dismissal.
Georg-Johan's reply was not "one word". He actually said:

SprinterSB wrote:
delay stuff in one example

You may want to pay a little more attention to the replies before sniping.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

You may want to pay a little more attention to the replies before sniping.

 

I disagree with your characterisation of my reply and other matters in your post. I am genuinely surprised and saddened to read this. I do not wish to argue over these points.

 

I have recently taken delivery of a 1634 and 88 and will hopefully be able to post an update in the next few days.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a couple of ATtiny40 chips.   I don't think that I have ever played with them.   It is difficult to see what is attractive about this chip.

 

It has the brain-dead tiny4,5,9,10,20,40 core.   It needs 5V to program.   It has no debug.  It uses TPI.

 

The new ATtiny817 is a far more interesting chip.

The traditional tiny2313A, tiny4313,  tiny1634, ... have 32 registers.  Use ICSP at working voltages.   Have debugWIRE.  Have USART_MSPI.

 

If you publish suitable test suites for the Tiny40,   a few people might investigate.   I am able to program and run the hardware.

Not many members have the chip.

If several people verify a problem,  SprinterSB might help.

If there is only a vague description,  none of the GCC developers will even look at it.

 

But the real mystery is:   Why do you want to use a Tiny40?

 

David.

Last Edited: Wed. Oct 4, 2017 - 11:12 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
I have a couple of ATtiny40 chips.   I don't think that I have ever played with them.   It is difficult to see what is attractive about this chip.

 

For me, it was a relatively cheap 20-pin AVR with ADC and hardware-assisted I2C. You can probably tell from my first post in this thread that it came with more than a few negative surprises.

 

david.prentice wrote:
The new ATtiny817 is a far more interesting chip.

 

I looked at those. They look utterly amazing. The whole series does. They're cheap too. In theory they're perfect.

 

Digging around on that family presented some potential issues:

- No avrdude support even in the latest source.

- Not supported in the distro compiler I am using (but possibly a later version?). So, new compiler.

- Some difficulty finding a confirmed reliable way to flash them. Do I need a dedicated hardware programmer, a USB serial plus some Python code that apparently talks the protocol, confirmation that you can kludge an Xplained Mini to program it, or do I need to roll my own?

 

These aren't necessarily big problems in *general*, but they *are* problematic for where the project I am working on is right now. Apologies for glossing over the full explanation.

 

I almost bought an 817 Xplained Mini with my recent order, and only narrowly decided to leave it to a later purchase. There's a good chance I'll use one of the chips in this family in a future revision.

 

david.prentice wrote:
The traditional tiny2313A, tiny4313,  tiny1634, ... have 32 registers.  Use ICSP at working voltages.   Have debugWIRE.  Have USART_MSPI.

 

I need ADC, and I *think* that eliminates the *313s. I just received a 1634 today, hopefully will have it running soon.

 

david.prentice wrote:
If you publish suitable test suites for the Tiny40,   a few people might investigate.

 

I have not been able to create a minimal test program that demonstrates the problem in isolation in a form that I can supply. I realise this limits how people can help. If I do so, I'll be sure to post it.

 

david.prentice wrote:
If there is only a vague description,  none of the GCC developers will even look at it.

 

The distro version I am using appears a few years old, they would rightly direct me to the latest version. But if I could satisfy both that and get a test program together I could try that route.

 

david.prentice wrote:
But the real mystery is:   Why do you want to use a Tiny40?

 

I did. I'm not sure if I still do. Let's see how the 1634 goes at least. Stealing my prior comment: Am I prepared to pay 20c extra per unit to have included EEPROM and self-programming, extra flash and SRAM, plus make the problems I've been encountering go away instantly? You bet I am. :)

 

Thanks for all of the information, much appreciated. I'll hopefully have an interesting update soon.

 

Last Edited: Wed. Oct 4, 2017 - 12:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As a general rule, developing on a bigger AVR is more convenient. There is masses of cheap hardware for an ATmega328P because it is used in the Arduino Uno. You can buy an XMINI-328P cheaply.
.
Having got the project debugged, rebuild for a smaller, cheaper target chip.
.
If you have a problem, people will be willing to help when they have a 100% working 328p project to compare.
Cooperation works far better when both parties have a common 328p project to compare with.
There is less ideas communication failure.
.
David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OP missed the point of -O1 .

Sometimes the issue is undefined behavior.

That optimization settings matter hints at this.

-O0 follows the abstract machine,

but the code is bloated to unintelligibility,

-O1 also follows the abstract machine and is better for debugging.

My question was specific to -O1 .

Does it work for -O1 ?

 

If it does not work for -O1 ,

the assembly should be simple enough that you can examine it for correctness.

To be clear: C's idea of correctness, not yours.

If it is not correct and you have not told the compiler any lies,

you have found a compiler bug.

If the assembly is correct and does not work, you have found a bug elsewhere.

 

What asynchronous events occur?

Are the relevant variables declared volatile?

 

SPI strikes me as something for which timing might matter.

Optimization settings can affect timing,  That is often their purpose.

Is the attiny40 the master or the slave?

If master, be sure to handle /SS correctly.

If slave, be sure to handle /SS correctly.

Does the other SPI device like you?

 

 

OP seems to be ruing his choice of attiny40 and

might solve his immediate problem by changing chips.

Even if that works,

OP might sensibly want to know what is going on with his attiny40.

It might be a matter of curiosity.

It might be a matter of wanting to recognize it if it happens again.

International Theophysical Year seems to have been forgotten..
Anyone remember the song Jukebox Band?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have just realised that part of my initial comment may be causing confusion. When I said "bit-bang SPI-style send", I should have said: Bit-bang synchronous serial, output only. Output is on two lines: One clock, and one data. There is no SPI in use at this point and the protocol has no input. Apologies for any confusion caused by my poor choice of words.

 

david.prentice wrote:
As a general rule, developing on a bigger AVR is more convenient.
Having got the project debugged, rebuild for a smaller, cheaper target chip.

 

Thankyou for the advice. I agree entirely.

 

Believe it or not, the 84A *was* the bigger chip that got the proof of concept going. When things went really well, I decided to try to roll a whole bunch more new functionality in, and suddenly I didn't have enough pins.

 

david.prentice wrote:
There is masses of cheap hardware for an ATmega328P...

 

I've likely got a spare ATmega328* lying around somewhere if it comes to that. It's a fun chip that taught me a lot. I might still make a build for it. If I started again knowing what I do now, I might have done the original proof-of-concept on it, then worked down from there.

 

skeeve wrote:
My question was specific to -O1 .
Does it work for -O1 ?

 

-O1 exhibited the behaviour described in #10.

 

skeeve wrote:
What asynchronous events occur?
Are the relevant variables declared volatile?
SPI strikes me as something for which timing might matter.

 

In the smallest test case I've managed thus far: No interrupts, ISRs, SPI, or I2C use.

 

skeeve wrote:
OP seems to be ruing his choice of attiny40

 

To a point but will weigh up against the new ICs.

 

skeeve wrote:
OP might sensibly want to know what is going on with his attiny40.
It might be a matter of curiosity.
It might be a matter of wanting to recognize it if it happens again.

 

Both, but have to prioritise effort.

 

Last Edited: Wed. Oct 4, 2017 - 11:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, some mixed news. Might be worth a new thread once I've looked into it further. I'll share it here for now.

 

Got a 1634 into my circuit and could talk to it almost immediately, even without a direct connection between the programmer (Pi) and the IC. I was excited for a few, glorious moments.

 

And then I discovered there is something seriously wrong with writing to flash on the device. Reverting back to a simpler setup hasn't helped thus far.

 

At present, every write to flash fails to verify, but every read back of the flashed data returns back a consistent, wrong result that seems to have some data clobbered. On a hunch, I created a file that just consisted of bytes from 0 to 255 repeating and flashed that. Here's 256 bytes of that file.

 

0000000 0100 0302 0504 0706 0908 0b0a 0d0c 0f0e
0000020 1110 1312 1514 1716 1918 1b1a 1d1c 1f1e
0000040 2120 2322 2524 2726 2928 2b2a 2d2c 2f2e
0000060 3130 3332 3534 3736 3938 3b3a 3d3c 3f3e
0000100 4140 4342 4544 4746 4948 4b4a 4d4c 4f4e
0000120 5150 5352 5554 5756 5958 5b5a 5d5c 5f5e
0000140 6160 6362 6564 6766 6968 6b6a 6d6c 6f6e
0000160 7170 7372 7574 7776 7978 7b7a 7d7c 7f7e
0000200 8180 8382 8584 8786 8988 8b8a 8d8c 8f8e
0000220 9190 9392 9594 9796 9998 9b9a 9d9c 9f9e
0000240 a1a0 a3a2 a5a4 a7a6 a9a8 abaa adac afae
0000260 b1b0 b3b2 b5b4 b7b6 b9b8 bbba bdbc bfbe
0000300 c1c0 c3c2 c5c4 c7c6 c9c8 cbca cdcc cfce
0000320 d1d0 d3d2 d5d4 d7d6 d9d8 dbda dddc dfde
0000340 e1e0 e3e2 e5e4 e7e6 e9e8 ebea edec efee
0000360 f1f0 f3f2 f5f4 f7f6 f9f8 fbfa fdfc fffe

 

Here's 256 bytes of what I get back:

 

0000000 0100 0302 0504 0706 0908 0b0a 0d0c 0f0e
0000020 1110 1312 1514 1716 1918 1b1a 1d1c 1f1e
0000040 ffff ffff ffff ffff ffff ffff ffff ffff
0000060 ffff ffff ffff ffff ffff ffff ffff ffff
0000100 ffff ffff ffff ffff ffff ffff ffff ffff
0000120 ffff ffff ffff ffff ffff ffff ffff ffff
0000140 ffff ffff ffff ffff ffff ffff ffff ffff
0000160 ffff ffff ffff ffff ffff ffff ffff ffff
0000200 8180 8382 8584 8786 8988 8b8a 8d8c 8f8e
0000220 9190 9392 9594 9796 9998 9b9a 9d9c 9f9e
0000240 ffff ffff ffff ffff ffff ffff ffff ffff
0000260 ffff ffff ffff ffff ffff ffff ffff ffff
0000300 ffff ffff ffff ffff ffff ffff ffff ffff
0000320 ffff ffff ffff ffff ffff ffff ffff ffff
0000340 ffff ffff ffff ffff ffff ffff ffff ffff
0000360 ffff ffff ffff ffff ffff ffff ffff ffff

 

The pattern repeats. It seems that 32 bytes work, then 96 end up as 0xff, and the pattern repeats.

 

I can reliably write this data, and reliably get back these wrong results.

 

Writing the same pattern to EEPROM works every time. Verifies, reads back okay.

 

Counting downward gives a weird but similar result. Written:

 

0000000 feff fcfd fafb f8f9 f6f7 f4f5 f2f3 f0f1
0000020 eeef eced eaeb e8e9 e6e7 e4e5 e2e3 e0e1
0000040 dedf dcdd dadb d8d9 d6d7 d4d5 d2d3 d0d1
0000060 cecf cccd cacb c8c9 c6c7 c4c5 c2c3 c0c1
0000100 bebf bcbd babb b8b9 b6b7 b4b5 b2b3 b0b1
0000120 aeaf acad aaab a8a9 a6a7 a4a5 a2a3 a0a1
0000140 9e9f 9c9d 9a9b 9899 9697 9495 9293 9091
0000160 8e8f 8c8d 8a8b 8889 8687 8485 8283 8081
0000200 7e7f 7c7d 7a7b 7879 7677 7475 7273 7071
0000220 6e6f 6c6d 6a6b 6869 6667 6465 6263 6061
0000240 5e5f 5c5d 5a5b 5859 5657 5455 5253 5051
0000260 4e4f 4c4d 4a4b 4849 4647 4445 4243 4041
0000300 3e3f 3c3d 3a3b 3839 3637 3435 3233 3031
0000320 2e2f 2c2d 2a2b 2829 2627 2425 2223 2021
0000340 1e1f 1c1d 1a1b 1819 1617 1415 1213 1011
0000360 0e0f 0c0d 0a0b 0809 0607 0405 0203 0001

 

Read back:

 

0000000 9e9f 9c9d 9a9b 9899 9697 9495 9293 9091
0000020 8e8f 8c8d 8a8b 8889 8687 8485 8283 8081
0000040 ffff ffff ffff ffff ffff ffff ffff ffff
0000060 ffff ffff ffff ffff ffff ffff ffff ffff
0000100 ffff ffff ffff ffff ffff ffff ffff ffff
0000120 ffff ffff ffff ffff ffff ffff ffff ffff
0000140 ffff ffff ffff ffff ffff ffff ffff ffff
0000160 ffff ffff ffff ffff ffff ffff ffff ffff
0000200 1e1f 1c1d 1a1b 1819 1617 1415 1213 1011
0000220 0e0f 0c0d 0a0b 0809 0607 0405 0203 0001
0000240 ffff ffff ffff ffff ffff ffff ffff ffff
0000260 ffff ffff ffff ffff ffff ffff ffff ffff
0000300 ffff ffff ffff ffff ffff ffff ffff ffff
0000320 ffff ffff ffff ffff ffff ffff ffff ffff
0000340 ffff ffff ffff ffff ffff ffff ffff ffff
0000360 ffff ffff ffff ffff ffff ffff ffff ffff

 

It's like the bits have been masked with 0b10011111. Why would that be?

 

Bizarre.

 

I don't think this is signal-related. The reads are reliable, read/write to EEPROM is fine, and the error is consistent. Problem in the avrdude config (not sending the right commands) or something wrong with the flash maybe?

 

avrdude version 6.3 built from source, linuxgpio.

 

Anyway I still have plenty of things to try, but if this pattern reminds anyone of anything, please do share.

 

Last Edited: Thu. Oct 5, 2017 - 07:52 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Go on.   Please provide a "reproducible" situation.

 

The Tiny1634 has been widely used for several years.   ICSP works fine. debugWIRE works fine.

 

If you have a problem, specify:

1.  avrdude command line

2.  avrdude version

3.  the Linux version.

 

I would be far happier with a link to the actual avrdude executable from an official distribution and exactly where you obtained it.

 

I am sure that you are competent at building avrdude from source.    As far as I know,   Linux distributions vary in quality.

Linux users can advise on the particular AVR tools package that you are using.

I run Windows.    It is almost impossible to build on Windows.    I use the pre-built executables.

 

Oh,  the ATtiny1634 is a really nice chip.   I still reckon that you should develop on a mega328P.    The Uno or XMINI-328P are very convenient.

 

David.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Some quick answers for now, will add more later:

 

avrdude version 6.3 built from source.

http://www.nongnu.org/avrdude/

http://download.savannah.gnu.org...

 

When writing binary data:

avrdude -P gpio -c foo -p attiny1634 -U flash:w:data.raw:r

When reading binary data:

avrdude -P gpio -c foo -p attiny1634 -U flash:r:data.raw:r

 

When writing exe (not doing at present):

avrdude -P gpio -c foo -p attiny1634 -U flash:w:foo.hex:i

 

The Pi doing the programming:

Raspbian 7

Linux pi1 4.1.19-v7+ #858 SMP Tue Mar 15 15:56:00 GMT 2016 armv7l GNU/Linux

 

Here's a script to make the second set of data, target filename as sole argument.

 

#!/usr/bin/ruby -w
fh = File.open ARGV[0], "wb"
for j in 0 .. 15
  for i in 0 .. 255
    fh.write (255-i).chr
  end
end
fh.close

 

Replace "(255-i)" with "i" to make the first set.

 

I'm rewiring for a second setup (Debian Stretch, also 6.3, distro provided) using a generic USBASP, 5V. Runs avrdude 6.3 distro provided. Can provide details later when I've tried it.

 

Still trying things out, might be a fault in my setup somewhere.

 

 

Last Edited: Thu. Oct 5, 2017 - 08:53 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

garthyd wrote:
I can reliably write this data, and reliably get back these wrong results.
The error seems to suggest that something has got the wrong value for SPM_PAGESIZE. Is this avrdude you are using? If so what does the chip description in avrdude.conf look like for the chip you are trying to program? Do the numbers match those given in the datasheet?

 

If this is 1634 was the entry in avrdude.conf created by copying some other Tiny entry and fixing up things like signature byte values? If so it seems the SPM pagesize was over looked. For example here's an entry for tiny2313:

     memory "flash"
         paged           = yes;
         size            = 2048;
         page_size       = 32;
         num_pages       = 64;
         min_write_delay = 4500;
         max_write_delay = 4500;
         readback_p1     = 0xff;
         readback_p2     = 0xff;
...

So that one has 32 byte pages.

 

Your output looks like something that has been programmed as if it too has 32 byte pages.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Actually I just went hunting for an avrdude.conf that include 1634 and got to here:

 

https://github.com/SpenceKonde/A...

 

That seems to suggest the page size is 32:

 

https://github.com/SpenceKonde/A...

 

That is curious to have such a small page size in such a large (16K) device! Now I'm going to have to pull the datasheet....

 

EDIT: OK, so ignore that hunch - it was a red herring....

 

 

The 1634 really does have 512 pages that are 32 bytes each. So it is programming whole pages - it just appears to be skipping some!

Last Edited: Thu. Oct 5, 2017 - 08:58 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nice find.

 

Both the latest source and the distro-provided version in Debian Stretch have a page size of 32.

 

One of the files you've linked has 32, and the other 64. So, someone changed it in that branch?

 

Here's part of the flash section for the 1634 in the latest source:

 

    memory "flash"
        paged           = yes;
        size            = 16384;
        page_size       = 32;
        num_pages       = 512;
        min_write_delay = 4500;
        max_write_delay = 4500;
        readback_p1     = 0xff;
        readback_p2     = 0xff;

 

This is worrying though. Shouldn't this have tripped people up before me?

 

Will experiment with this soon.

 

Just saw your edit. Still, something I can dig into.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

garthyd wrote:
Shouldn't this have tripped people up before me?
Yes, which is why David said:

david.prentice wrote:
The Tiny1634 has been widely used for several years. ICSP works fine.

so there's something "local" going on here. You are almost certainly not the first to use avrdude to program 1634's. So by implication this must be working for others.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> You are almost certainly not the first to use avrdude to program 1634's. So by implication this must be working for others.

 

I had assumed that too. I was concerned at the ramifications of that assumption being incorrect.

 

Last Edited: Thu. Oct 5, 2017 - 09:25 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Generic USB ASP. Works for exactly one use of avrdude and have to disconnect/reconnect to get it working again.

 

Desktop PC

Debian Stretch

> uname -a
Linux namehere 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) x86_64 GNU/Linux

 

> avr-gcc --version

avr-gcc (GCC) 4.9.2

Copyright (C) 2014 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.  There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

 

> avrdude 2>&1| grep version

avrdude version 6.3, URL: <http://savannah.nongnu.org/proje...

 

Flashed:

> avrdude -c usbasp -p attiny1634 -U flash:w:countdown.raw:r

 

Read:

 

> avrdude -c usbasp -p attiny1634 -U flash:r:countdownr.raw:r

 

Data matches, no gaps. This setup doesn't have the same problems I was encountering on the Pi.

 

Wrote a simple led blinker and flashed it. Worked.

 

So divide-and-conquer from here. USBASP, voltage, circuit, distro, avrdude+config, etc etc. Then back to the larger tests with the original problem.

 

I think I'm done for the evening. Tired.

 

Let me know if you'd like updates and what you'd like to know. Next bit might take a while.

 

Thankyou for all of the good advice offered, much appreciated.

 

 

Last Edited: Thu. Oct 5, 2017 - 11:54 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A quick update.

 

I experienced multiple issues with flashing images to the ATtiny1634, but each could be solved in the end.

 

Using the generic USBASP with avrdude on the Pi worked fine, just as well as on the Debian Stretch box, although it only worked for the first flash per USB connect. I am informed that this is a firmware bug. There is a workaround that basically involves writing to the device more slowly. Details here: http://www.avrfreaks.net/forum/g...

 

As for direct ISP, in the end my local setup was fine. I tried multiple changes to do with the specific wiring, voltage, using a buffer IC, direct connections, and countless other configurations, but in the end it was all irrelevant. The bug was in avrdude, or more specifically the 1634 configuration shipped with it. Details here: http://www.avrfreaks.net/forum/a... (alternate link: http://www.entropicsoftware.com/...)

 

With writing to the device out of the way, I've found the ATtiny1634 a pleasant chip to work with. All of the tests from the 84A/40 testing that I threw at the 1634 worked, even using the distro-supplied avr-gcc/g++. Hardware TWI(I2C) on the 1634 is much easier to work with than TWI over USI on the 84A. I've now reached and passed feature parity with the 1634 compared to my 84A setup and am concentrating my efforts on the 1634.

 

I've abandoned the ATtiny40. I now have confirmation that the same environment and tests work fine with the 84A and 1634, yet cause repeated issues on the 40. It has become a matter of how much time I am willing to sink into getting the 40 working, which is now zero.

 

If I had to speculate, I would say the most likely reasons for the problems with the 40 could have been defective flash on my specific IC or incomplete support for the 40 in the distro avr-gcc. But it could just as well have been something else. If anyone is investigating the 40 in the future in a similar environment to mine, I am happy to share any details of my experience that you think might prove useful. Just ask.

 

Anyway, this might be the last update from me in this thread as the thread was originally about the ATtiny40, which I've now moved away from.

 

Last Edited: Thu. Oct 12, 2017 - 06:19 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I agree that t1634 is a pleasant chip to work with. But since you mention t84A you may have a look at t841 which is (almost?) pin compatible with the 84A and have a lot more goodies, like the 1634 (and even more).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

snigelen wrote:
I agree that t1634 is a pleasant chip to work with. But since you mention t84A you may have a look at t841 which is (almost?) pin compatible with the 84A and have a lot more goodies, like the 1634 (and even more).

 

Interesting. :) Thankyou for the suggestion. I had looked at the 841/441 briefly but your suggestion made me go back and check out the family properly. I see what you mean re pin compatibility, it looks like they took an 84a and jammed a bunch of extra peripherals in on top. With hardware TWI/I2C support it would have been a closer fit to my project than the 84A. The only box it doesn't tick is support in the latest avrdude. However, I did a quick search and found a post from you in 2014 talking about successfully flashing to the chip, so I know who to ask if I get one. ;)

 

I think if I'd gone with a 14-pin design the 441/841 would have been a close fit to what I needed. I probably would have developed on the 841 and settled on the 441. In any case I will keep the 841 in mind for any 14-pin AVR design I look at.

 

For this project I've settled on 20-pin (17 I/O), and even that involved cutting back some features. I think I've got the right balance of essential functionality now. I believe it likely I will be using a 1634 in the end.

 

Thankyou for pointing me toward the 841 family.