Writing EEPROM does not appear to be persistent when using example AN4570. MC9SO8PA4

[gregoryberardi]

I am using the examples from AN4570. The example "EEPROM_ProgramUpto4Bytes". I am writing to location 0x3100 and the data is visible when using the "Memory Monitor" but when the chip is reset the data goes back to 0xFF.  I am erasing before writing and the functions are returning success. I am assuming that the BUSCLK is the 4MHz crystal that is clocking the chip (the datasheet is vague about this) so I have set FCLKDIV to 0x03 (3.6 to 4.6MHz). Any ideas on what I'm doing wrong?

[pavel_sadek]

Hi Gregory, Hu,

I have ordered PA4 sample to check your issue, I will be back soon with new reply

Pavel

[gregoryberardi]

Hello Pavel,

Thank you very much for the help!

[pavel_sadek]

Hi Gregory,

I have wired the sample with BDM and power source - looks ugly however works.

now I have loaded your latest code.

as I do not have anything hooked to the mcu, I had to replace your clock init whth

//hal_clk_init(); 

ICS_C3 = *(unsigned char*)0xFF6FU; //ICS trim

ICS_C2 &= (unsigned char)(~ ICS_C2_BDIV_MASK);

I have disabled the wdog, your code was missing the wdog unlock sequence which is not correct

WDOG_CNT = 0xC520; // write the 1st unlock word

WDOG_CNT = 0xD928; // write the 2nd unlock word

WDOG_CS1 = 0;

I am calling the eeprom functions from the main loop controled by global variable "operation" that I have made for this purpose.

hal_eeprom_write_4_bytes works ok on my side

hal_eeprom_erase_4_bytes is erasing only first sector (two bytes), you need to exclude the alignment control that you have placed there and erase in sequence both sectors  that belongs to memory space (4 bytes) you want to erase - take a look into AN at page 6; segmantation is sector or whole block...

I have tested the debugger for freezing, I have noticed it occurs when fast toggling between run and stop, it might be due to propagation delays in eclipse (I have quite fast PC so it is not so obvious here for the first sight), however there were no freezes when stepping (F5/F6) at all.

I have also enabled the EEPROM preservation to exclude eeprom overwriting when debug session toggling (it is in propoerties of Multilink connection).

so as a conclusion - I think your issue was the watchdog, then you need to update the erase function and it might be ok

Pavel

[gregoryberardi]

I was sent an message from another user. When I tried to reply to the user I got a bounce so I am putting the email here so that it might help them or others trying to work through this problem.

>>>>>>>>>

Hi Gregory,

This is Danilo, I'm also trying to use the PA4 in a new project but I'm concerned about the size of the routines to erase, read and write, EEPROM and FLASH memory.

I would like to know if you have success reducing the code transfered to ram memory in eeprom and falsh routines?

Could you share your progress testing the eeprom with the PA4?

I would appreciate any help.

Cheers,

Danilo

>>>>>>>>>>

Here is my response.

Hello Danilo,

All I'm doing is writing a 2 bytes. I was told that I needed to put the routine in RAM because I was in the same address space as FLASH. The actual condition is if you are mass erasing blocks of memory.  Here is the text from the application note AN4570;

"Some specific commands are not allowed to operate on EEPROM while some commands are running on flash block. For example, EEPROM read operation is not allowed while any flash command is running on the flash block. Another example is that it is not allowed to run code from flash to mass erase (erase block or erase all commands) EEPROM"

If you are doing this then you would need to run the code from ram. The example shown in that app note copies the whole routines to RAM but this requires 208 bytes, in my case, out of the 512 available. I was able to section out the few instructions that were being used to program which came to ~10 bytes. Instead of following their example, I used an array and put the code in there and used a pointer to the array to call the function and embedded it in the code. This worked but I didn't need to do this so I removed it from my code.

The actual issue I was having was that I could not prove that the EEPROM as persistent between boots. I was using the debugger to determine the values in EEPROM.  When you run a debugging session it erases all flash and EEPROM before it programs. I found a way to make codewarrior skip erasing EEPROM.

While doing this I found something that works!

Open "Debug Configurations..." from the "Run" menu item then "Edit" the "Connection". Click on the "Advanced Programming Options" and in there you will see that it is already populated with the addresses of the EEPROM (0x3100 to 0x313F)

I hope this helps!

[zbeehu]

It must close the watchdog?

[pavel_sadek]

Hi Hu

it was previously in the code,

if you are using the wdog:

be sure its period is long enough for flashing operation and

do wdog servicing just prior to flash operation launching

Pavel

[zbeehu]

i have another problem...

when i power to the PA4,the led will flash,while?

this PA4 was no program..

[pavel_sadek]

Hi Hu

please open another thread with this issue - oterwise nobody will find it

as there is no real program it does not fetch the reset vector (PC is configured to 0xffff and imediatelly overflows) and continues by performing the area from 0000 (random behavior)

it is quite surpricing that ports are configured as outputs low (might be interpretation of some default register combination),

the periodicity of the flashing can be result of wdog triggring as it is enabled by default and apparently wdog is not services in erased / unprogrammed device.

You can hook a debugger there and by stepping see where the PC goes and what are the random instructions performed

Pavel

[zbeehu]

think you

[Monica]

Hello Gregory,

was this helpful? Please let us know :smileyhappy:

Best,

Monica.

[gregoryberardi]

Is it possible to just have the code

   NVM_FSTAT = 0x80;

   while (!(NVM_FSTAT & NVM_FSTAT_CCIF_MASK));

run in ram rather than the complete functions? This seems to be the only time that the eeprom is accessed and it would help me with my memory constraints.

Thanks again!

[pavel_sadek]

Hi

you can use just this fragment in RAM

be sure interrupts are disabled during this operation

Pavel

[gregoryberardi]

I have used just that small bit of code

   NVM_FSTAT = 0x80;

   while (!(NVM_FSTAT & NVM_FSTAT_CCIF_MASK));

and loaded it into an array that I call from the erase and write routines and it is still not writing the eeprom (I still see the values there when I write but when I power cycle it, the values are not retained).

Also, I am having problems with the debugger (https://community.freescale.com/thread/310757). This kind of issue keeps coming up. While I'm working on this code it will go off and say that it can't show the disassembly for the current instruction. Sometimes it just completely loses connection to the micro and needs to be started again. Any idea why I can't write the eeprom and why the debugger is doing this?

Thank you in advance!

[pavel_sadek]

Hi

I have ran your code on my PT60 TWR board - it is failing in hal_clk_init function,

I have excluded

// ICS_OSCSC_OSCOS= 0x01; // Output Select (1 Oscillator clock source is selected)

// while (ICS_OSCSC_OSCINIT == 0); /* waiting until oscillator is ready */

and flashed those 4 bytes into EEPROM space 0x3100

then I did a POR (I have disconnected the board completely to be sure)

and launched the code again with breakpoint at the beginning of main

the content of EEPROM is correct

this ICS setup seems to be the source of an issue of your debugger too.

I hope this will help

Pavel

[gregoryberardi]

I did comment out those two lines but my experience was very different.

Debug with no breakpoints.

Then I get;

Then I step into ~7 times and then I get

This is essentially the same as before. The only difference is that if I put a breakpoint on the line after the eeprom_init the debugger never reaches the breakpoint (same error as before) when I have those lines commented out. With those lines the debugger does reach the breakpoint.

This is the debug circuit on the board I am using.

The datasheet does not have any pull-ups or a capacitor. Could this be the source of the debugging issue?

Thank you for help!

[pavel_sadek]

Hi again,

well, Reset is connected according ref manual fig. 2.5, that is correct. BKGD/MS pin pullup is not recomended anywhere however it has internal one, so the additional pullup hooked externally should not cause any issue.

I would point you to errata document, it is available on S08P product summary page, there are 2 for different masks of PA4, so choose the correct one.

there are few issues and their workarounds  for Flash and Debugging mentioned

the raw code of yours works, this is proved by my last trial, so issue might be with missing workaround for your exact device (mask)

I do not have any PA4 device here to check.

Pavel

[gregoryberardi]

Hello Pavel,

I looked at the errata here (This is an N36F mask)

http://cache.freescale.com/files/microcontrollers/doc/errata/S08PA4_0N36F.pdf?fpsp=1&WT_TYPE=Errata&...

I can't see where any of the issues are germane to what I am seeing? The flash issues (NVM) are related to the EEPROM?

Thank you again for your help!

[pavel_sadek]

Hi

yes - EEPROM is non volatile memory, there are 2 errata to check.

your code works correctly with PT.

why is reset tied to 4V instead of 5V?

Pavel

[gregoryberardi]

Hello again Pavel,

What I mean is that, when you actually read the errata, all it talks about is protected "Flash". There is no indication that it affects EEPROM. Is EEPROM protected or partially protected? I never read anything, the second time I read it, that says that EEPROM is an issue.

I didn't see that 4V when I posted it. I can assure you that this board is not wired that way.

Thank you for your help.

[pavel_sadek]

Hi Gregory.

the EEEPROM has its protection too, it is stated on page 66 - 68 of reference manual, so it can be protected (or just partially protected - 32 / 64/ 96 or 128 bytes of size)

the workaround guides to use unprotected device

this errata / workaround does not apply to PT60, so you can test it on your PT60 twr board (same as I did successfully few days ago), that is why I feel this errata as a suspect.

Pavel