freescale_flash_loader.c, troubles getting it to work on 52235evb

[alager]

This is the code I've tried:

Code:

void update_my_flash_vars(char *unitid){ unsigned long address = 0x4403f7ff; //0x4403f800; char * foo ="test characters"; flash_init(); flash_page_erase((unsigned long *)address,(unsigned long)0); //0x4403f800 is the last flash page         //0x800 bytes (2k)long. fill it with zeros         //flash_write((unsigned long *)address, (unsigned long*)unitid); flash_write((unsigned long *)address, (unsigned long*)foo);}

But all I get is this error on the console:
Access Error -- PC = 0x0000F982
Error on operand write

Access Error -- PC = 0x0000F9CE
Error on operand write

From the xMap file:
#>00038040          ___DATA_ROM (linker command file)
I should have plenty of space to do this.  And I don't think that the addresses are interfering.

The process is supposed to be:
1. init the flash
2. erase a page()
3. write to a page()
What am I doing wrong?

I'm using the Internich code rev 2.0. 

Thanks,
Aaron

[DarrenSteadman]

Ok sorry I probably didn't explain very well.

Basically the addresses on the on-chip flash must be dword aligned. Therefore the address must be divisible by 4 and produce an integer result.

The address you are trying to write to 0x3f7ff is 260095 in decimal which when you divide by 4 comes out as 65023.75 which as you can see is not an integer, therefore it will not work properly.

Strangely in your example code you have commented out an address at the top which is dword aligned and therefore should work correctly.

unsigned long address = 0x4403f7ff; //0x4403f800;

On every write you must check the alignment of the address first and align it if it needs to be.

Say for example you start at address 0x3f800 which is aligned and you write one byte this will move the address to 0x3f801 which is not dword aligned, if you used this address then you would get the error you are seeing, however if before you do the next write you align the address to the next dword boundary I.E 0x3f804 then everything will be fine.

To get the most out of your memory it's best to try and do your writes so that everything is naturally dword aligned else you will end up wasting space in flash because of having to leave blank space.

Hope this makes more sense

[alager]

Update:
So it seems that there is a conflict between the flash writing system and printf or uart in the tcp_lite by internich.  I put the flash routines BEFORE all my debug print statements, and it works.

Thanks for all the help.

Aaron

[alager]

Thank you, I did miss that point.
It's still not working, BUT I have a good clue to share now.  If I use the terminal interface, I can call the  flash_erase() function from freescale_flash_loader.c, and it works fine.  But if I call flash_erase() from a function that is initiated by a web page, then I get a dialog box in the debugger:
Exception vector name: Address Error
and the debugger stack is pointing to timer_isr.

Any ideas?

Thanks,
Aaron

[DarrenSteadman]

I had the same problems, it turned out it was because the addresses have to be aligned. I think it's 16 byte alignment, it tells you in the datasheet. I basically had to go through the code and when ever I did a write then I would re-align the address afterwards before I did the next write to keep it on the correct boundary

[alager]

I guess I'm just dense.  I totally don't understand what you mean. 
From my code above I'm erasing then writing to address 0x3f7ff.
Since I'm passing the address to the function as a value, not a pointer, it can't get modified.
What else am I missing?  Maybe an example would make it clearer to me.

Thanks,
Aaron

[admin]

The first time I tried to program flash memory of the MCF52233 in-application I was getting an 'Access error' exception. Turned out writes to flash have to go through the back door. See here:
Relevant forum thread

Regards,
- scifi

[alager]

yeah, I found this thread and I am currently trying to get the code that Rich wrote to work.  But I'm still getting errors.
Does it matter if my code is past 0x20000 and on the second page?
My code ends at 0x35630, and the routines that Rich wrote are residing in that latter half of flash.

Aaron