Writing eeprom using JTAG

Hello Mastupristi,

Using CCS you can write a Startup GEL file that be used to program the Internal EEPROM. This is not possible through UNIFLASH or LMFlashProgrammer.

However do note that it may not be possible in every IDE to do so and even in CCS you would need to ensure that the steps required to ptogram EEPROM is in compliance with what the DataSheet and TIVAWare do in terms of Error check and proper initialization of EEPROM.

Regards

Amit

The need to wirte eeprom is for production purposes. All the production steps must be automated.

Is it possible to "execute" gel file from a command line software tool?

best regards

Hello Max,

I believe so that gel can be run from CCS in command line. I would move this thread to CCS Forum for the experts out there to help you out in building the same.

Regards

Amit

A common solution is to create a small kernel of code that runs on the MCU.  Download this kernel through JTAG.  download the EEPROM payload to SRAM (via JTAG).  Use JTAG to run the kernel which moves the payload from SRAM to EEPROM.  Then use JTAG to erase the kernel and download the final application.

I believe that LMFlash could do all of this with a little bit of command line scripting to handle the multiple steps.

Dexter

Hi,

For production we have embedded the default values into the program and at the first run it writes into EEPROM. This way we save time, extra programming phases,... (~15k/y).

Petrei

Find Petrei's suggestion best yet.

To be even clearer - those default values are written to EEPROM - at the first program run, "only."

This indicates that some (independent) counter or non-volatile memory is examined.  (i.e. to test/verify that a "first run" is in process.) 

Petrei - may we ask if you are able to use the, "default program state/status of the EEPROM itself" to test for that, "first run?"  (i.e. the raw/unprogrammed EEPROM is unlikely to contain the same "n" initial bytes as your default values.)

Thanks for sharing your neat, time/effort saving method.

Cordialement,

Petrei's method also has the advantage that should the EEPROM contents ever become corrupt and not recoverable then the default values in FLASH could be re-programmed to EEPROM as a fallback position. 

INTEGRIS Dexter said:

the default values in FLASH could be re-programmed to EEPROM as a fallback position. 

Thanks for that, Dexter - that's also great point - in my book.

Yet - does not your method suggest that if certain areas of the EEPROM are corrupted/not recoverable (and those programmed - per Petrei - just ONCE) - yet other areas of the EEPROM are more likely to function correctly?  (and those areas being potentially more heavily accessed/programmed than Petrei's "one-time only")

It would seem logically correct to assume that the EEPROM area - programmed just once - would prove more robust than all other EEPROM areas - subject to repeat programming.  Thus - reprogramming into an EEPROM already judged to have suffered corruption (and that in its least programmed area) - may not be, "best practice."

Have I missed something?   At first glance your idea seemed very neat - upon 2nd thought - issues/concern surface...

And - still unstated - best method to determine, "First time programming" of default EEPROM values?...

Dexter's method is the one I use.

Corruption and first time init are treated identically.  IE first time programming is seen as (and is treated as corruption).  Corruption is determined by comparing a version number to the current version in the program (This also provides a method to reset/init store when storage format changes or items are added or removed) and a checksum/CRC.  Usually I use a fletcher or a CRC rather than a naive checksum.

I also usually provide a mirror copy so a corrupted version can be corrected from an uncorrupted copy.

Different blocks can be used for groups of data tailored to uses (like single update vs frequent updates).  They can have different levels of protection. Multiple blocks do cost extra room for version/crc so some thought is required but that is art of our job.

There are some tyes of data where init/corrution can be ignored and left to the end user. 

For truly frequent data I use a hamming EDC code to allow skipping worn out cells if I have to.  If I have a choice though I use FRAM rather than EE.  FRAM has several advantages.  Most recent variants have effectively unlimited writes and the writes are considerably faster (mulltiple orders of magnitude) which eliminates some corruption sources and reduces others.  I still use the CRC/version technique.

Robert

Robert Adsett said:

Dexter's method is the one I use.

Much good detail here Robert - thanks - appreciated.

Yet remains the issue that if, "single use EEPROM" has been corrupted - does that not heighten the likelihood that other - more active areas of EEPROM - are as (or likely) even more vulnerable/suspect?  Your post while otherwise superbly detailed (we especially liked your description of hamming code & FRAM) was silent in that, "single use EEPROM" comparative corruption, probability regard...   (say that fast - three times...)

Hi,

First sorry for the late reply...

As for our implementation, for each parameter we have some limits, high and low, none of these has the default empty EEPROM value. We read a parameter and if not within limits, the default value is written, read/verified if correct and then moved to RAM for working purposes. If writing fails, an error is issued and treated.

The module receives from an external controller new values for operating with - these are tested against values in RAM and within limits - and if different than value in RAM but within limits, is a new value and a message is sent to be written, read/verified.

This way the module can start up with default values in case of errors or stored ones and work under new set of values received from  outside in case of errors. The errors are sent by external controller through internet to an operator.

Petrei

@cb1  I think we are considering different types of "corruption"

The type I think you are considering and trying to correct for yes, I think you are correct, once a region of memory is deemed unfit due to over-use (too many write cycles for example) then yes, I would not re-use that area of memory again.  However, since the device offers 500k (if I recall correctly) write cycles on EEPROM and 100k cycles on flash I have not had to worry about this over-use in my applications.

I am more interested in the EEPROM and how it reacts to power cycles.  If you read the datasheet and errata some care is required for these device on each startup to make sure that EEPROM state is recovered.  Fortunately the TivaWare API's take care of most of that for us.  However, it is still possible (at least in my head) that if power is removed at the wrong point during an EEPROM write the data write will not succeed and the value read back on subsequent restart will not be correct.    This is what I am trying to correct for.

@Dexter,

Very well stated - you nicely "teased out" my concern.  (I may require use of a template, too...)

As to your detail re: EEPROMs functioning under, "disturbed" power - our firm most always provides, back-up power (via Li Ion battery - not via hibernate) so that, "unwanted power disturbance" is hugely reduced and/or eliminated.

@Petrei,

Thanks much your clarification - due to the "minimization of special handling/operations" (i.e. Petrei's described method) our group will adopt & report results downstream.

Thanks to all - quite a resource lurks here...  (when Engineering 101 & 24 bit ADC (unpowered) do not seize {undeserved & unwanted} forum dilution/control!)   (just say'in...)

cb1- said:

To be even clearer - those default values are written to EEPROM - at the first program run, "only."

Unfortunately I cannot follow this suggestion: one of the things that need to be written into the EEPROM is the serial number.

That's why I was wondering if it was possible to automate the production steps, perhaps by running a gel file from the command line

best regards

max

Hello Max,

I thought so with the original post. This is not possible on TM4C123 (TM4C129 has the UNIQUEID register which is per device). So for the moment it can be done by CCS. As Dexter mentioned earlier, through the LMFlashProgrammer at most the 2 User Config words can be committed at command line

This can then be used to generate a Unique Serial ID or used as a Serial ID.

Regards

Amit

Hi,

What about the User1,2 registers? did you use them for some thing? can be written with LMFlash, either graphical  or command line with some sort of script. (There was the place for Ethernet local IP, on 123 there are free, unless…).

Maybe a better formulation from the beginning...

Petrei

Edit: I did not read completely the previous post...

In the eeprom I have to write a certain serial number, the production timestamp, and some other info generated at production time.

So I think Uer1,2 registers are not enough. the only solution I saw was to program the eeprom.

best regards

Hello Max

I am working on a gel file in CCS to do the same in debugger mode. I think it should be possible to use it in command line mode (that is a mode I haven't used so far)

I will post it when I complete coding and testing of it.

Regards

Amit

Amit Ashara said:

I am working on a gel file in CCS to do the same in debugger mode.

Good that - even better if such could be generalized into broader, more mature IDEs (IAR, Keil spring to mind).  And - might similar "already exist" w/in those other IDEs?  (if so - likely saves you time/effort - I don't know...)

As that "gel file" so often derails CCS users during, "lock-out/other programming/debug "adventures"" - it's poetic justice that gel now "bends" to better (finally) serve mankind.  (if/when your effort succeeds - "lands" here...)

Hello cb1,

Of course, other IDE's would have similar scripting interfaces. CCS is readily available to me so would be good to get one out, instead of holding all of them.

Regards

Amit

cb1- said:

Dexter's method is the one I use.

Much good detail here Robert - thanks - appreciated.

Yet remains the issue that if, "single use EEPROM" has been corrupted - does that not heighten the likelihood that other - more active areas of EEPROM - are as (or likely) even more vulnerable/suspect?  Your post while otherwise superbly detailed (we especially liked your description of hamming code & FRAM) was silent in that, "single use EEPROM" comparative corruption, probability regard...   (say that fast - three times...)

[/quote]

In my experience if any individual write is corrupted due to some external event rather than wear out then there is a possiblility other areas of EE are also corrupt.  That is why you have mirror copies of important blocks with something like a CRC. to detect corruption.  The hope is that one block will survive intact to use to restore the other.

On the other hand if you have an item that is truly only set once in production you do have the option of recording it in flash which would be more secure, particularly if the application program does not have the ability to self program flash.

One final note to the original poster, rather than do this as a download, I've always just made it part of the normal communication protocol.  Presumably you need that to read the serial number off of the device in any case and generally you will need to test that in production as well so adding the programming of the EE there instead of during program download is not usually a significant disadvantage.  Do consider using your flash though as well, scripting that should be straight forward and some programmers have the capability of adding items like serial numbers automattically according to what ever scheme you define.

 

Robert

Robert Adsett said:

In my experience if any individual write is corrupted due to some external event rather than wear out then there is a possiblility other areas of EE are also corrupt. 

For example, one possible corruption is that EMI causes the write address to be corrupted so the value is written to the wrong location. This will lead to a corruption in the original block (its check value will no longer be correct) and possibly in another block as well.

The worst case is that it will corrupt the mirror block. 

Robert

@Robert,

Both (your) recent posts raise good/valued points - thanks much - appreciated...

Especially like your 2nd writing - exploiting the communication/verify process...

Hello All,

I have completed the development and basic testing of the gel file in the CCS environment and I can now upload a test code and EEPROM initialization outside the test code.

Copy the following files

0804.eeprom.dat

to D:/eeprom.dat

and the following file

6177.tm4c123gh6pm.gel

to

C:\ti\ccsv5\ccs_base\emulation\gel\tm4c123gh6pm.gel

If you are using any other TM4C123 device then copy the OnFileLoaded section of the gel file to the appropriate gel file

The way it works is that the GEL on loading the program, copies the content of dat file to SRAM of the device and then uses the SRAM image of the content to program the EEPROM. The Syntax of the eeprom.dat file for user would be

1651 1 20000000 0 NUM_OF_EEPROM_WORDS*2+1 0
NUM_OF_EEPROM_WORDS
ADDR
DATA
ADDR
DATA

In the Gel File the user has to update the following

GEL_MemoryLoad(0x20000000, 0,NUM_OF_EEPROM_WORDS*2+1, "D:\\eeprom.dat");

In the attached dat and gel file the NUM_OF_EEPROM_WORDS is 6

The Gel file reads the number of words so that it can set the loop and then uses first the address to compute the EEPROM Location and next address to compute the value of EEPROM Data to be written to that location. This goes on till NUM_OF_EEPROM_WORDS is not completed.

Regards

Amit