How do you use the eeprom in a KE02Z device?

[davetelling]

I see that the KE02 devices all have 256 bytes of eeprom, but some things are not clear. It appears that there are a bewildering number of options when using the flash/eeprom for data storage, and I was wondering if anyone could answer some questions.

1. I am using the IAR tools. If I want to store, for example, an array in flash or eeprom, do I have to explicitly specify a memory address, or is there a way to tell the compile/link process to place it in that memory space? The AVR has an intrinsic: __flash or __eeprom that handle this, but the ARM tools do not seem to have something similar.

2. Is it possible to write at the byte level, or are you required to write an entire block to change one byte?

[saipriyasubrama]

I have a similar question and I would like to know how you eventually ended up writing and reading from the EEPROM. I am using PE for my purpose. Thanks

[mjbcswitzerland]

Dave

Please see

http://www.utasker.com/kinetis/FRDM-KE02Z.html

and

http://www.utasker.com/kinetis/KE_EEPROM.html

You should find all practical details and can load a binary and experiment with reading, writing and deleting EEPROM and other Flash content.

To your specific questions:

1. With IAR one uses

__root const KINETIS_FLASH_CONFIGURATION __flash_config @ ".f_config"

to define that const data needs to be located in a section (KINETIS_FLASH_CONFIGURATION is a struct typedef here but any array can be used).

In the linker script one defines where the address range physically is:

place at address mem:FlashConfig_start__

{ readonly section .f_config };

Since the programmer will not be able to program the EEPROM (it uses different programming commands) and its address is at a high memory location I wouldn't do any initialisation like this - it is simpler to let the application save values to it (or prime it with values on first use).

2. You can write single bytes to this EEPROM but you have to delete always a pair of bytes (short word aligned) as smallest unit.

A chip erase will also erase the EEPROM content so most programming tools are a nuisance since they wipe out the EEPROM data each time a program is loaded - working with a boot loader solves this as noted in the links.

This is not "real" EEPROM since it is Flash and doesn't support changing values (or single bits) without first deleting, but it is pretty close, robust and easy to use.

Note that there is an IAR project in the reference linked to which solves all these details (and includes most other drivers etc. for the KE devices). Its Kinetis simulator also simulates the EEPROM and will warn of any mis-use.

Regards

Mark

http://www.utasker.com/kinetis.html

[davetelling]

Mark,

I was able to get the flash/eeprom functions working, and successfully programmed a byte at address 0x10000000. However - I cannot READ that value in my code. I declared a pointer:

#define eeprom_start 0x10000000

#define e2start ((volatile uint32_t*)(eeprom_start))

Then, in my code, I have a variable, eData:

uint32_t eData;

If I try to read it like this:

eData = *e2start;

I always get a hard fault interrupt (vector 03)

I also tried this:

#define e2start (*(volatile uint32_t*)(eeprom_start))

With this for the read code:

eData = e2start;

At no time am I getting a compiler or linker error, but when I run the code, and have a breakpoint at the line where I write to eeprom, I can see that the eeprom data are changed in the debugger when I click the "step through" button. If I then try the step-through on th enext line (where I try the read of 0x10000000) I go into an endless loop where it always hits the default isr, and the vector code is 03.

Once again, I'm stumped!

[mjbcswitzerland]

Dave

ulValue = *(unsigned long *)0x10000000;

is OK for reading the first 4 bytes of the EEPROM.

Beware that your code doesn't write the EEPROM each time it runs because this would be an illegal operation. You must never write a value to a byte that is not erased to 0xff.

Writing incorrectly to flash (EEPROM) may cause damage and it can also cause the flash controller to stop allowing reads to take place from it (since it "thinks" that it is damaged) - which may be a reason why the read is causing problems although the code is correct. (This would often be seen by the debugger since it will dsplay something like "----" at locations that can't be read (but it will depend on the debugger being used).

I would perform a chip erase and verify that you can read 0xffffffff from the address using the code, then program the byte and verify that you can then read the changed value, making sure that you avoid multiple writes.

Regards

Mark

http://www.utasker.com/kinetis.html

[davetelling]

Here is a screenshot of the section in question:

I have declared eData as uint32_t. I also tried with the eData variable a a byte and a 16-bit word, no difference (I did change the pointer definition appropriately). The disassembler shows that the EEPROM base address, 0x10000000 is placed into R0 (the first two instructions of the assembler for that line of C code)). At the instruction with the

green highlight, the value in R0 should change to the value at address 0x1000000, but instead, if I step into this instruction, it goes immediately to the default isr, with a vector of 3 (hard fault). Again, it almost looks as if there is some kind of "illegal address detector" set so that EEPROM address is not readable, but doesn't seem to have a problem with programming that same address. I am really confused by this!

[mjbcswitzerland]

Dave

The instruction looks OK but I would suggest trying the following:

1. Set a break point at the call to the erase routine.

2. Reset and run to this call.

3. Set the PC to the code after the call so that it loads R0 again with the address of the EEPROM.

4. See whether it then works.

If it does, it may man that the erase is leaving the EEPROM in an unreadable state.

After the erase operation, check the flash status register to see whether it has any flags set that indicate that something was wrong with the operation that it performed - possibly it basically did the erase but signalled an error which needs to be cleared before the EEPROM can actually be used further.

Beware also that the flash programming setting has be match the bus speed (see FTMRH_FCLKDIV) and if this value is not set correctly it can damage the Flash/EEPROM, and possiblly cause other side effects. If for some reason your bus clock is lower than 800kHz it would also be illegal for Flash/EEPROM programming. Such details are checked/regulated automatically in the uTasker driver and so I never saw what may happen in case of things being out-of-specification.

Regards

Mark

[davetelling]

Mark,

I still get a hard fault - it's as if there is a setting somewhere that won't allow reading of that particular address area, but I haven't found anything. Obviously, the memory can be read by the debugger, because it shows the byte I programmed, so at this point, I'm not sure what to look for. Any ideas?

[mjbcswitzerland]

Dave

Did you try the binary at µTasker FRDM-KE02Z support to verify that it works correctly on your board (it is OK on my FRDM-KL02Z) ?

I didn' see problems with the way that you were accessing the EEPROM - it is simply memory mapped like all other Flash. In an emergency you could zip up your project so that I can check it for you.

If you need to move on to application programmig don't forget that there is a complete KE framework in the uTasker project which should already solve all of your problems, plus allow you to simulate the KE and board to quickly complete project work.

Regards

Mark

µTasker Kinetis support

[davetelling]

Mark,

I went to the link you provided, and did not see any binaries for EEPROM access, unless one of the three listed has that internally. If so, which is it?

[mjbcswitzerland]

Dave

Please see highlighted text - the last one is the same but operates as stand-alone so I would load the 3rd one with OpenSDA USB-MSD drag-and-drop to the board's hard-drive if you are on the Freedom board.

You can play with the EEPROM (and internal Flash) in the I/O sub-menu on the OpenSDA virtual COM at 115200 Baud (using a terminal emulator). See the KE02 EEPROM Interface page for details of the commands.

Regards

Mark

[davetelling]

Mark,

I got the binary working, with some interesting results.

In the I/O menu, the "md" command works at the byte level (using address 10000000), but if I try a 'w' or 'l' option, the system reboots to the splash screen. However, the "sd" commands works correctly with all three data sizes. So, this tells me that at least the hardware seems to be working OK, and I need to dig through my project to see why I'm getting the "hard fault" situation. I'll go through your post with the debugging ideas and see hwo that works out.

Thanks very much for helping with this - it seems that the ARM Cortex learning curve is steeper than I anticipated.

[mjbcswitzerland · Accepted solution]

Hi Dave

I am pleased that you tested this using the code that I posted because I didn't realise that half or long word accesses are not possible. I also get the same behavior and, if you check out the EEPROM discusion page, you will see that all tests are performed as byte accesses, where I never noticed this.

The "sd" (storage display) access is used for working with non-memory mapped memory (such as SPI Flash) and all such accesses are based on collecting the data in a byte-wise fashion, even if "sd l 10" is used. The long parameter just controls how the collected bytes are ordered for display purposes.

Checking through the user's guide I have found this statement:

"The flash memory is read as bytes"

There are others such as

"Single bit fault correction and double bit fault detection within a word during read operations"

which may confuse since "word" must mean "byte" in this context.

Each word (and again I suppose it actually means byte) uses ECC to allow correcting 1 bit (to extend the amount of write/erase cycles that can be achieved before the collective Flash cells fail). I imagine that when half- or long word accesses are performed it causes this ECC mechanism to fail and a hard fault to occur (or this area of memory really lacks non-byte access capability).

In any case, we now know that the EEPROM MAY only be accessed as bytes so any program using it must respect this requirement. (Now I also know this because I didn't before....I will update the discussion page to include this little detail...)

Regards

Mark

http://www.utasker.com/kinetis.html

[davetelling]

Mark,

OK, I went back through and made sure that everything was set up for byte-wide data. I used the IAR function for the EEPROM programming to program one byte, then read in eData as a byte, then erased the eeprom. All seems to be working now!

At this point, I just need to figure out how to set up my functions to correctly handle 16 and 32 bit data.

Thanks very much!

[davetelling]

Mark,

OK, I'll try it and see what happens. If it works OK, then that would seem to indicate either a project setting somewhere needs to be fixed, or my debugger has a bug. I'll post when I try your binary.

Thanks!

[davetelling]

Mark,

First of all, thanks for a detailed answer. I am a noob at ARM-based projects, so please bear with me as I figure this out. In the reference manual, it shows a 256 byte EEPROM starting at address 0x1000_0000, going to 0x1000_00ff. The flash memory range starts at 0x0000_0000, and ends at 0x07ff_ffff, so it looks like the flash and EEPROM have separate memory spaces. Are you saying that the EEPROM is actually flash memory, just being called something different?

[mjbcswitzerland]

Dave

I think that it is called Flash in the user's manual but optimised for EEPROM (like) functions by making its sector size very small.

Regards

Mark