Auto increment product serial number

Hi all,I'm up to some projects involving product identification.
The MCUs I'm working on include those with and without internal EEPROM.I'm thinking of storing a table that contains product serial number either inside the flash ROM or EEPROM.And make these specific bytes auto-increment when I burn the program into each MCU.But I don't know how to do it.
I have the Microchip's official device ICD2,and a third-party programer - ISPro that's only compatible of burning PIC16F87x(A).I can either burn the Hex code into the MCUs with ICD2 in MPLAB or with the ISPro in its dedicated software by importing the Hex file.
I'm not really good at PC software programing,so you can't count on me in writing a supervising plug-in for MPLAB that detects each burning process and modify its destination file.That seems way too complicated.But I would like to hear some advice and get to know how many ways there are to realize my intention.Any information will be appreciable.My gratitude in advance.

I would suggest you need to do some PC programming, for a start is ISPro capable of accepting command line parameters?.

Assuming it is?, you could write a PC program that changes the HEX file, then calls ISPro to blow the PIC - this running in a continuous loop would program every PIC with a different serial number.

To make changing the HEX file simple you need to have the serial number stored at a particular address - probably the very top of memory?. It would be simple then for a PC program to locate and change the required line in the HEX file.

Presumably if you had a production programmer it would allow you to do this anyway?.

Thanks for your suggestions,Nigel.Sorry to tell you that ISPro doesn't have a custom software interface.It's just a programer that picks hex files and burns them into the selected MCUs in ISP mode.There's a EEPROM window in its management window.I can read and write the EEPROM seperately but cannot save the read data or import a binary file into its write buffer.It's totally closed.Perhaps MPLAB is also closed like this.
However,I think there must still be some way I can intercept their burning commands and detect the "complete" status.I may write a program to monitor such changes,even locate the destination file.After each completion this program modifies the serial number and saves the file.
I have done some visual basic programing previously.Is VB capable of doing this?I think I may not be the first one that faces this problem.I wonder what others did when this happend to them.

As the 16F87x is capable of writing to it's own program space, you could write a serial number after it has been programmed. If you put 4 (or more/less) retl 0 in the last locations of the program space, you can check for them being zero at power up and jump to a receive serial number routine. This would be fairly simple to implement in VB using the MSComm control.

Alternatively, you could use something like ic-prog to program your chips and modify it manually each time. If you store the serial number in locations 1 through 3 then it would be fairly quick and convenient.

I.E.


HTH

Mike.

Alex_rcpilot said:

Thanks for your suggestions,Nigel.Sorry to tell you that ISPro doesn't have a custom software interface.It's just a programer that picks hex files and burns them into the selected MCUs in ISP mode.

Click to expand...

I wasn't refering to a 'custom software interface', just simple command line parameters.

If you could run the program and pass it the filename as a parameter like "ispro text.hex", when it would blow the chip with the passed file.

One possibility is my software WinPicProg, which has such a command line capability. But perhaps even more use, it will also detect a changed HEX file and automatically reload and program the PIC. The automatic reloading and automatic programming are switched ON by 'Auto-Update' in the Options Menu, and 'Auto-Prog', a tick box on the main screen.

It works, quite simply, by looking to see if the time/date code on the file has changed.

Thanks,Pommie.The idea for 16F87x is really good.I think I can use it in devices with such MCUs.But the second suggestion was just what I need to avoid.Changing the bytes manually will take too much extra work.

And thank you Nigel,too.oops,my mistake.You were talking about a command line.There're no command lines.But there are setting menus.This software normally works in this way,given an MPLAB generated hex file:Open the hex file in the 'File/Open' menu>select chip type>click on 'auto prog'.The parameters for 'auto prog' can be set by ticking the following options:Update hex file,detect chip ID,erase,empty check,write program,verify,wirte data(EEPROM),verify data(EEPROM),write configuration and run target board.I usually leave the empty check,EEPROM options as well as configuration options deselected.

A friend of mine told me that he had seen someone posting related items in a forum,refering to a .NUM file.He didn't say how exactly this file was used.Obviously it's not executable,but it worked and the hex file was changed after each write operation,plus his device was ICD2.I'm suspecting if there's an interface for such .NUM files in MPLAB.Anyway,doing some PC programing is inevitable.

By the way,Nigel.Where did you get the signature picture?It ressembles the character "Method" in traditional Chinese,but there are 2 redundant points in the middle.Looks interesting.

Alex_rcpilot said:

By the way,Nigel.Where did you get the signature picture?It ressembles the character "Method" in traditional Chinese,but there are 2 redundant points in the middle.Looks interesting.

Click to expand...

It's the Kanji character for 'jitsu', as in 'Ju Jitsu', as you say it means 'method', 'way', 'technique' etc.

I can't comment on the accuracy of it, and it's supposedly Japanese rather than Chinese, but they stole the same Kanji anyway .

I choose it as my avatar after a thread demanding I got one!, I picked this as I'm a 3rd Dan black belt in Ju Jitsu.

Nigel Goodwin said:

I can't comment on the accuracy of it, and it's supposedly Japanese rather than Chinese, but they stole the same Kanji anyway .

I choose it as my avatar after a thread demanding I got one!, I picked this as I'm a 3rd Dan black belt in Ju Jitsu.

Click to expand...

:shock: Never knew you were into Ju Jitsu,it's awesome though!

'they stole the same Kanji' ... who stole Kanji from whom?I seriously doubt that Chinese stole the Kanji from Japanese if that's what you were talking about.As the Chinese charactors have a much longer history than Kanji.The truth is obvious.

Back to the topic,could you give me some advice on how to intercept the event indicating an end of programing?I was thinking about monitoring the serial port with the ICD2 or ISPro under serial mode,rather than analizing RAM changes.Never tried operating an already opened serial port.I don't think I will succeed anyway. :wink:

Alex_rcpilot said:

'they stole the same Kanji' ... who stole Kanji from whom?I seriously doubt that Chinese stole the Kanji from Japanese if that's what you were talking about.As the Chinese charactors have a much longer history than Kanji.The truth is obvious.

Click to expand...

I've always been told that the Japanese 'stole' their Kanji from the Chinese, I know that Kanji is only one type of Japanese writing, I presume it's only one type of Chinese as well?.

Back to the topic,could you give me some advice on how to intercept the event indicating an end of programing?I was thinking about monitoring the serial port with the ICD2 or ISPro under serial mode,rather than analizing RAM changes.Never tried operating an already opened serial port.I don't think I will succeed anyway. :wink:

Click to expand...

Assuming they are both connected to the serial port, and certainly in the case of the ICD2, the actual programming is done by the PIC on board the programmer - so the end of transfer of data from the PC doesn't signify the end of programming, the PIC on the programmer still has to program the data it received.

As the PIC is going to need changing anyway, as you program each individual one, presumably you need some way to tell the PC the next chip is in place and ready to program?. Something as simple as 'Press Return when ready' is all that's required (or an external button?), and your PC program just needs to detect that.

Nigel Goodwin said:

I've always been told that the Japanese 'stole' their Kanji from the Chinese, I know that Kanji is only one type of Japanese writing, I presume it's only one type of Chinese as well?.

Click to expand...

The word "steal" really sounds exaggerated.Cultural exchanges take place all the time.It's common that one sees something useful from another culture and learns it.Even carrying it forward later.It was more like a peaceful culture exchange rather than hostile stealing in my opinion.Anyway,I was just curious about the avatar in the beginning.

Nigel Goodwin said:

Assuming they are both connected to the serial port, and certainly in the case of the ICD2, the actual programming is done by the PIC on board the programmer - so the end of transfer of data from the PC doesn't signify the end of programming, the PIC on the programmer still has to program the data it received.

As the PIC is going to need changing anyway, as you program each individual one, presumably you need some way to tell the PC the next chip is in place and ready to program?. Something as simple as 'Press Return when ready' is all that's required (or an external button?), and your PC program just needs to detect that.

Click to expand...

"the end of transfer of data from the PC doesn't signify the end of programming" yes,you're correct.Could you tell me whether the hex file will be used again later when the programer verifies the data?Actually my concern is when the hex file will be free for modification.I know how to modify files with visual basic.The software just needs to know when the file is available.And I really want this to be automatic.Perhaps I can prepare a button to switch the detection on and off.

Alex_rcpilot said:

Could you tell me whether the hex file will be used again later when the programer verifies the data?Actually my concern is when the hex file will be free for modification.I know how to modify files with visual basic.The software just needs to know when the file is available.And I really want this to be automatic.Perhaps I can prepare a button to switch the detection on and off.

Click to expand...

It obviously depends entirely on how the programmer software is written, my software WinPicProg loads the entire HEX file into a buffer, so verifies against the contents of the buffer.

I've no idea if your software would work in the same way or not?, I would suspect not though? - often programming software works a line at a time through the HEX file, particularly in the case of a true serial connection as you have. The PIC only has VERY limited amounts of RAM (GPR's), so it's normal to transfer a line at a time, which amount is easily stored in the PIC's memory.

This is one reason why WinPicProg is the fastest programming software around, it programs the PIC in a continuous stream, and also ONLY programs the required bytes - most program the entire device regardless.

Thank you Nigel.I think I better start analyzing the software and keep looking for solutions in process.I really don't want to buy a production programer for this simple purpose only.Your information is helpful.And I will keep an eye on this post to see if someone has got a far better way than writing a custom executable software.