How to count the number of uploads ?

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

Dear all,

 

I am programming the tiny via usbasp and avrdude, namely intel.hex file and it works well, fast... I would like to follow how many uploads I have done... how would somebody approach this with another tiny as a counter ?  

 

Looking forward to any ideas how to approach this.

 

BR.

 

 

Bravo!!!

Last Edited: Fri. Jun 19, 2020 - 09:53 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For any particular reason?

 

You would have to modify the tools and/or the embedded code to ensure that everything always maintained this - so if you ever used a different tool, or forgot to include the necessaries in the embedded code, or it didn't work, you'd lose everything.

 

Probably the easiest & most reliable method is just to stick a label or tie a tag on the board, and write on that.

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Fri. Jun 19, 2020 - 10:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mu234 wrote:

Dear all,

 

I am programming the tiny via usbasp  

 

 

BR.

 

 


Make a counter inside your usbasp which increment at every successfull load and save the counter value inside eeprom

I don't know why I'm still doing this hobby

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

I'd go for simplicity:

// program.cmd
avrdude ... stuf ...
echo %DATE% %TIME% >> prog.log

In DOS the >> operator means "append to existing file"

 

Here is an example of something similar in action:

D:\>type test.cmd
@echo off
echo hello
echo %DATE% %TIME% >> prog.log
D:\>test
hello

D:\>test
hello

D:\>test
hello

D:\>type prog.log
19/06/2020 13:48:45.69
19/06/2020 13:48:47.85
19/06/2020 13:48:49.72

Apart from the fact that this tells me I ran the command three times it also tells me WHEN I ran the command on each of those three occasions.

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

Used to be that avrdude supported that:

 

-y
    Tells AVRDUDE to use the last four bytes of the connected parts’ EEPROM
    memory to track the number of times the device has been erased. When this
    option is used and the ‘-e’ flag is specified to generate a chip erase, the previous
    counter will be saved before the chip erase, it is then incremented, and written
    back after the erase cycle completes. Presumably, the device would only be
    erased just before being programmed, and thus, this can be utilized to give an
    indication of how many erase-rewrite cycles the part has undergone. Since the
    FLASH memory can only endure a finite number of erase-rewrite cycles, one
    can use this option to track when a part is nearing the limit. The typical limit
    for Atmel AVR FLASH is 1000 cycles. Of course, if the application needs the
    last four bytes of EEPROM memory, this option should not be used.
-Y cycles
    Instructs AVRDUDE to initialize the erase-rewrite cycle counter residing at the
    last four bytes of EEPROM memory to the specified value. If the application
    needs the last four bytes of EEPROM memory, this option should not be used.

I don't know which version was the last to support this.

 

You could recreate the functionality yourself with a wrapper script:

  • read last four bytes of eeprom, interpret as 32-bit integer counter
  • increment counter
  • upload new code (erase-rewrite)
  • write counter to last four bytes of eeprom

 

EDIT:  A quick review of the older versions' documentation here:

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

... shows that the feature was removed beginning with v6.0.1.  The last version which supported it was v5.9.  You could always roll back to v5.9, but you will lose the benefit of any new features which were added after that, and any bug fixes as well.

 

Note, the changelog doesn't actually show this as having been removed until 6.1, but I'm fairly confident that 5.9 was the last to feature it.  Curiously, the usage message when invoking avrdude without any command line options remains right up until the current version 6.3, but it is not actually supported.

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Fri. Jun 19, 2020 - 05:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:

You could recreate the functionality yourself with a wrapper script:

  • read last four bytes of eeprom, interpret as 32-bit integer counter
  • increment counter
  • upload new code (erase-rewrite)
  • write counter to last four bytes of eeprom

Why would you need 4 bytes for this, if the flash can only be written 10k times? 

Wouldn't a two byte (uint16_t) be enough?

 

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

ki0bk wrote:

Why would you need 4 bytes for this, if the flash can only be written 10k times? 

Wouldn't a two byte (uint16_t) be enough?

Probably, but the 10K limit is a manufacture spec, guaranteed across all other (i.e. temperature, voltage, endurance) specs.  That is, I should be able to count on the 10,000th write for 100 years at 25°C, or 20 years at 85°C.  We've all seen threads over the years testing the limits of flash and eeprom endurance, which go well beyond 10K cycles.  For non-production units, it would be nice to count beyond 65,535.

 

Mind you, 24bits is likely enough (16M+), but the feature was added to avrdude at a time when 24-bit integers were not really a thing in the world of GCC.  If creating one's own wrapper script to accomplish the same thing, one could choose whichever width one wanted.  However, for compatibility with older versions of avrdude, 32-bit would be needed.  Otherwise, a 16-bit counter set to 0x0001 would read as 0xFFFF0001, or 4,294,901,761.

 

EDIT: typo

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Sat. Jun 20, 2020 - 04:09 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 how would somebody approach this with another tiny as a counter ?  

Well, lots of software approaches suggested above, but I have to admit my first thought was to do this with hardware...

Lots of ways to solve any problem...

 

You need to decide how you are going to read the data back from the micro that does the counting.

You could use an LCD, a graphics LCD, a 7-Seg LED display, a USART link to a PC running a terminal program (what a hassle for this project), or a Bluetooth module that shows the data  on your cell phone, or a WiFi module that posts the data on a web page, or a piezo beeper that sends you the data in Morse Code, or, or, or...

 

Which of those you use will determine how many I/O pins you need, and how much memory you need.

As a general rule, it is wise to start with a big micro and develop your code.

If you then really want to port the project to a tiny micro, so be it.

If you are only making one or a couple of the project boards, then the differential cost for starting with a decent sized micro is very small compared to the hassle of being 90% done with your project and running out of memory or I/O pins.

 

Developing your project on an Arduino Nano platform might be a good approach.

It has lots of memory and I/O pins, plus the power supply by-pass caps, USB interface, an LED, a reset PB switch, etc., all in a very small form factor, and all for only several USD.

You can use any programming language and environment you wish to use.

 

My thought was to put a micro, (or Nano), on a small PCB with an incoming signal programming header and an outgoing, (pass through), programming header.

The micro watches the Reset\ pin, (through a resistive divider, if needed), to monitor the Reset\ line for the initiation of programming signal.

Count those and keep the number in the micro's EEPROM.

If necessary one could watch another programming pin to see when the programming episode had finished, so as to more easily identify when to increment the counter.

 

The project is basically a "man-in-the-middle" monitoring the ISP signal (s) and incrementing the counter as needed.

 

There are certainly several details to work out, making it a worthwhile undertaking from a learning perspective.

How to detect the start of a new programming episode?

How to display the data?

How to store the data in the micro's EEPROM?

How to power the project, (From the programmer, from the target, with its own power supply)?

How to reset the counter, is desired?

How to lay out the incoming and outgoing ISP headers, correctly.

Etc.

 

JC

 

Edit: Typo

Last Edited: Sat. Jun 20, 2020 - 02:17 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

paper and pencil.

Ross McKenzie ValuSoft Melbourne Australia

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

Thank you, but I am preparing the individual programming setup where I will keep the log of programming. 

 

BR

Bravo!!!

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

Yeah, this looks like one of the best ideas, now I have to work on how to read/program/flash the USBasp via the Arduino.

 

BTW Has anyone done that?

 

BR.

Bravo!!!

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

Thanks, thats all good, but I am not going to have the access to the computer, but rather only to the programming device that I am building, hence the option of counting, etc.

 

BR.

Bravo!!!

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

Thanks, this is very optimistic idea, I like it, what I need to think now is how to write "this" information to the tiny belong that will be keeping the log of counting?

 

I guess this could be done via the command of SPI, namely the Slave Select and have two tinies in parallel?. 

 

Has any of you done that yet, has any experiences with having more than one uC on SPI ?

 

BR.

 

 

 

 

Bravo!!!

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

OOOUUUU, this is a lot of "do", but you are right, it is important how to do from start to end.

 

Indeed, the question of HW is important, so far, my idea is to light the LED once certain number is reached... eg. RED.

 

Why, am I looking at AT Tiny, because I have few left and I do not need more to count the number of programming and turn the RED led on...

 

BUT, can you say more about this:

 

My thought was to put a micro, (or Nano), on a small PCB with an incoming signal programming header and an outgoing, (pass through), programming header.

The micro watches the Reset\ pin, (through a resistive divider, if needed), to monitor the Reset\ line for the initiation of programming signal.

Count those and keep the number in the micro's EEPROM.

If necessary one could watch another programming pin to see when the programming episode had finished, so as to more easily identify when to increment the counter.

 

The project is basically a "man-in-the-middle" monitoring the ISP signal (s) and incrementing the counter as needed.

 

If I  got you right, you are referring to the "reset pin" which could be used to read the number of programming? Indeed, this does not provide me the information whether the programming was successful, or does it? In this case I am wondering, is there a keyword or code command, something must be, that acknowledges that proper programming has been achieved, can that part of writing/reading, be read by the 2nd tiny? Indeed, in this case, I could distinguish between the number of tries and number of programmed uCs? Right.

 

BR.

 

Bravo!!!

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

It needs to b e automatic, not human "labour" involved...

 

BR

Bravo!!!

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

mu234 wrote:

Yeah, this looks like one of the best ideas, now I have to work on how to read/program/flash the USBasp via the Arduino.

 

USBASP is an open source project based on VUSB stack which been around for about 15 years so you can easily find "how it works".

Too many project that people had done with it.

 

But you don't have to bother about "how to read/program/flash" but just add a variable as counter and save it to eeprom at every succesfull programming.

And (only) if you need it you can dump that eeprom data thru UART (or else as you wish) via one of the USBASP command (eg: read SCK speed?).

So you don't need other chips to do it. 

 

I'm not Arduino fans so don't ask me how to do it with Arduino. It can be easily done with AVR Studio.

 

mu234 wrote:

BTW Has anyone done that?

 

Mostly nowadays USB moduls with chips that don't have USB peripheral is using VUSB stack.

So as I said too many people had done it.

 

Smith

I don't know why I'm still doing this hobby

Last Edited: Wed. Jun 24, 2020 - 06:23 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello all,

 

thank you again for your input, I have managed to put something together and it works perfectly.

 

In general,I am counting the number of RST when high, respectively the number of target uploads, which is what I wanted.
 

Eg. the RST is pulled high when the SPI is used to upload the program on the uC. I am reading this with the tiny and one of its pins. I have used the debounce to filter the noise, however, I am not sure, if it is necessary ... either way, when prototyping with the switch, it was essential... 

 

So far it looks the USBasp can power the tiny (used only for counting the number of programming) along the programing of the target, but, was thinking to put the tiny to sleep while there is no programming yet, wake it up just to count the RST, then go back to sleep, and allow the USBasp to finish the upload while the tiny is asleep. Let me know what do you think? Which vector would you use in ISR? PCINT0,

? Would it be smart to add counting++ in the ISR or in main loop. And should the be awaken in ISR or before? BTW I am storing the number of counting in the E2prom... 

 

looking forward to your comments, etc!

 

Bravo!!!

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

Hello !

OK the question of power is out , sleeping not require usb (2.0) provides much more current thaN needed.

But, this time I have figured that RST is not really the best way of looking at this, namely because it does not really work properly. For example, this solution also considers when I am only detecting the uC and accordingly it counts as if the programming was executed, but it was not. So, I guess I need to dig into the SPI protocol more and detect actual programming logic...

Anyone has an idea?

Best.

Bravo!!!

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

mu234 wrote:
provides much more current thaN needed.
I'm only a software engineer but I think you may have misunderstood the concept of current if you think it's a "push" rather than a "pull". Devices draw as much current as they require, either the PSU can cope or it can't. But PSU's don't "push the current out".
mu234 wrote:
Anyone has an idea?
Well it's already been explored at the top of this thread. The easy place to count programming sessions is on the PC side with the utility that puts the code into the AVR. You know whether you typed "avrdude" or not. With some scripting you can even determine if avrdude (or whatever) succeeded in delivering what it was asked to.