ATtiny40 programming

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

Hello to all of you!

 

Some time ago I saw the ATTiny40 at an incredibly low price, about 0.18$ each unit. Now, I got a soic-20 breakout board to test them and play with them a bit. But I have found that this has been worse than I imagined. The interface to program it is the TPI, which I have did some research and I haven't seen a lot about it. Up to this time, the most valuable resource I found is an Arduino sketch that simulates this TPI interface. But, as you can see entering to that web site, is that the sketch was done to program a ATTiny10. It is adapted to program an ATTiny40, but I have found even less information about this chip and the TPI.

 

Now, I'm trying to debug what is the problem it does not work. I've dived on the datasheet of ATTiny40, trying to fix any error between the "documented protocol" and the protocol that is implemented on the arduino sketch. A big part of it is working, I am able to do a dump of all the ATTiny40 memory (I guess that is called the NVM). The programming sequence documented commands to do a "chip erase" following of the actual memory writing. But I can't even get working this chip erase instruction. I haven't modified the arduino sketch from the previous webpage, because the protocol seems to be exactly the same.

 

I have two chips and, when doing the memory dump of the first, I see this:

 

registers, SRAM
      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0010: 00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 E0 
0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0030: 00 00 00 00 00 00 03 00 00 8C 00 03 00 00 00 00 
0040: E9 58 5A 9C 1C A8 EE 53 1F 3B 16 15 A7 99 0B 96 
0050: A3 7B B6 01 57 46 CF 16 EE 56 CF 9D 5E CC D6 FD 
NVM lock
      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
3F00: FF FF 
configuration
      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
3F40: FF FF 
calibration
      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
3F80: 8C 02 
device ID
      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
3FC0: 1E 92 0E FF 
program
      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
4000: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
4010: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
4020: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
[...]

A positive thing is that the NVM lock seems to be all 1's, so according to the docummentation, it is writable. Doing a chip erase does not erase the memory, and the program memory is always at 1's level (all that 0xFF shown there)

 

But other chip I have shows a completly different behavior: The LSB bits on the NVM lock are 0's, so it shows a "programmed" state. Those bits should also be eraseable with a chip erase command, but the chip erase command does not changes anything. Also, the program memory is filled with 0's instead of 1's

 

registers, SRAM
      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0010: 00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 CF 
0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0030: 00 00 00 00 00 00 03 00 00 77 00 03 00 00 00 00 
0040: 4E D6 0E F1 DF EF 1F 67 BA DF 85 BA C7 F9 FD FB 
0050: 53 CC 6C BF AB BB 5F C9 74 FD 3B 6C 3C F4 F2 F9 
NVM lock
      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
3F00: FC FC 
configuration
      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
3F40: FF FF 
calibration
      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
3F80: 77 02 
device ID
      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
3FC0: 1E 92 0E FF 
program
      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
4000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
4010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
4020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
[...]

So, now my question is: Does anyone has had this issue with the ATtiny40 (or other ATtiny similar family as Attiny5/9/10/20). I don't know what is "normal" to be found on a new factory chip, if it should be filled with 0's or 1's. Am I missing something?

 

This topic has a solution.
Last Edited: Thu. Apr 8, 2021 - 08:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think that I have a Tiny20 and a Tiny40 somewhere.

 

Yes,   their peripherals are slighly better/different than the Tiny24 and Tiny461

 

But TPI is painful.    There is no OCD.    They run at 3V but you need 5V for TPI programming.

What do you really want to actually do with them?

 

The modern Tinys like Tiny817,  Tiny816 are much nicer in every way.

 

I suspect that you can get anything for $0.18 when the Distributor just wants to get rid of unpopular stock.

 

David.

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

david.prentice wrote:

I think that I have a Tiny20 and a Tiny40 somewhere.

 

Yes,   their peripherals are slighly better/different than the Tiny24 and Tiny461

 

But TPI is painful.    There is no OCD.    They run at 3V but you need 5V for TPI programming.

What do you really want to actually do with them?

 

The modern Tinys like Tiny817,  Tiny816 are much nicer in every way.

 

I suspect that you can get anything for $0.18 when the Distributor just wants to get rid of unpopular stock.

 

David.

 

I was trying to use it as an I2C slave to drive some leds. Just to try out them, not for a real project. But this problem arises just before uploading any code. I am not able to run an erase chip command on the attiny40 correctly. What programmer did you recommend to use? Do exist some alternative other than using the expensive Atmel ICE programmer?

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

TPI should work with SNAP, PicKit4 and ATMEL-ICE.

But there are Arduino sketches that can do the programming too.

 

I have used TWIS on a Tiny1634 (if I remember correctly)

It should work well on Tiny20 and Tiny40

 

As I said.    TPI is painful.    The ISP and debugWIRE on the traditional Tiny is nicer.

UPDI on modern Tiny is even better.

 

David.

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

 

Thanks, the SNAP programmer seems to be a good option regarding its price and capabilities. I will try to buy it. The USBASP option is viable or is not advisable even to try it?

 

Regarding to the Tiny40 and TPI, I have some more specific questions:

 

1: On one of the chips I am reading 0xFCFC as NVM Lock Bits. According to the datasheet, the bits number 0 and 1 are NVLB1 and NVLB2. Those bits are the least significant on the word 0xFCFC, so I supose that the value of those bits are 0 and 0 in this case, respectively

 

 

2: What is the "default" factory state for the chip. It is all the memory low (full of 0's) or high (full of 1's). Both chips shows a different memory content from factory. Is this common?

 

Last Edited: Sat. Feb 27, 2021 - 11:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is optional firmware for TPI on a USBASP but it uses the "wrong pins"

 

I suspect that someone has written USBASP firmware that uses the official Atmel pins.

Since I already have Atmel/Microchip programmer(s) I am not interested in the USBASP firmware.

 

David.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Just for reference I will leave my solution here:

 

I have updated the firmware of a cheap USBasp I bought using Arduino and the steps described here: https://www.electronics-lab.com/...

 

After this step, I've been able to upload code to the ATTiny40 using this wiring schema:

 

usbasp wiring with attiny40

 

The command used with avrdude is the following:

 

avrdude -p attiny40 -c usbasp -U flash:w:main.hex:i -F -P usb

 

Here is the code I used, incluying some makefile to help the developing process: https://gitlab.com/cambiadeso/at...

 

Thanks to everybody for the help.

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

Good work, and nice result. Well done.

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.