Self Reading and Writing of dsPIC33EP512GP504

[gdimops]

Hi all,
I am facing a problem on self Flash reading and writing of dsPIC33EP512GP504 microcontroller.
I have tried some code examples I found on the forum with no success. dsPIC33EP512GP504 has only 4 instructions for manipulating flash memory,
and I found no examples for this microcontroller. In particular it uses
FLASH_Write_DoubleWord,
FLASH_Read,
FLASH_Read_DoubleWord, and
FLASH_Erase.
I don't really know how to use these functions.

Any help would be great.
Regards, George

[darko.ilijevski]

Hello,

Unfortunately, we are not able to cover all the possible MCUs with examples, some things will require you to do some research on your own.
There is a lot of useful information on the specific datasheet, which deals only with the memory organisation of the specific MCU. You can find it HERE.
If you still have troubles after that, we will try to help you further.

Best regards

[gdimops]

Hi darko,
Thanks for your reply. Here is a piece of code that I came up with and it seems to work under some limitations:

// Declarations
far const code unsigned long RomBuffer[1024] = {0} absolute 0x6400; // multiple of 1024
unsigned long RamBuffer[1] = {0}; // Just 4 bytes. Doesn't really matter.
unsigned char someArray[10]; // 10 bytes

void ReadFunction()
{
FLASH_ReadDoubleWord(0x6800, RamBuffer); // Now read from Flash program memory. Store to RamBuffer.
someArray[0] = (unsigned char *)RamBuffer[0]; After Read it contains 'G' --> Correct !
someArray[1] = 0; //Null
}

void main()
{
if(RomBuffer[0]); //remove optimization
RamBuffer[0] = 'G'; // Now contains 'G'
FLASH_Erase(0x6800); //LIMITATION 1: Should be 1024 bytes past absolute address of RomBuffer which is 0x6400. If set to 0x6400 (starting address of RomBuffer) dsPIC resets.
I just declared a dummy rom buffer RomBuffer to provide known space so that I don't accidentally overwrite other program memory elsewhere.

FLASH_WriteDoubleWord(0x6800, RamBuffer); // 'G' is written to Flash program memory.
RamBuffer[0] = 0; // Now contains 0 (reset value)

ReadFunction(); //LIMITATION 2: Should be a seperate function. If substituted directly dsPIC resets unexpectedly. --> WHY??
}

Other than that, code reads and writes double words perfectly. Is there is any way to overcome these limitations ??

[darko.ilijevski]

Hello,

You sure made me dig through some datasheets on my own ( ) and here's what I have found out for you:

First of all, thanks for providing some code, as we have some material to work with, now.

- This is a quote from the device's datasheet :

Flash Memory is organised into ROWs of 64 instructions or 192 bytes.
RTSP allows the user to erage a PAGE of memory which consists of EIGHT ROWs
(512 instructions or 1536byts) at a time.
RTSP allows the user to program a ROW (64 instructions or 192 bytes) at a
time

You can see that I have been very accurate, I have even included the typo they've made. So, we have some flash memory, organized in pages of 1536 byts. RTSP is a MCU module that manages the FLASH memory operations. Another quote from our compiler's HELP file, regarding the Flash_Erase function :

The user should take care about the address alignment .
Depending on the chosen MCU, the block/row size may vary. Please refer to the appropriate datasheet.

- Now we can put 1 and 1 togehter and get... 3 ? Yeah, 3 - because this is 24bit math
We need to determine the start of each page in order to be able to properly set the erase function not to start at half a page (which is probably going to reset the MCU, as you have seen already). Let's say that the address starts at 0x0. The first erasable segment is at address 0x0. The next one is 1536 byts further, it means 0x0600. And the next is at 0x0C00. So - we can calculate that our block will start at n x 1536 bytes (or byts as MChip likes to call them).

- Next step - we know that the FLASH memory doesn't start at 0x0. We need the datasheet for this, too: page 49 states that the FLASH starts at 0x0200. Now we have our offset.

- We can now calculate the exact address that we can erase: 0x0200h + N x 0x0600h. Obviously, N needs to be a whole number.

- Consider now your case: You wanted to erase at 0x06400h. Let's see: 512 (0x200h) + N x 1536 (0x600h) = (25600-512) / 1536 = 16.3333 ! Since N has to be a whole number, this can't work. Let's try with the one that we know it works, 0x06800h : (26624-512) / 1536 = 17 ! The result is a whole number, thus we can erase at that location, as proved in your example

- Conclusion
To be able to erase some data at some address, the address has to fit the formula above. It can erase that much in one pass, be it half an array or way past the amount you need. It won't erase less. There's no way around those limitations - they are the result of the device's architecture. You will simply have to live with it.

There you have the whole theory behind this, sadly I do not have a device from that line at this moment, so I can't prove with some code, but your example should be proof enough. I hope it's more clear now what is going on with the flash erase / read / write.

Best regards

[gdimops]

Hi Darko,

Well I must say, that your answer covered all my questions, and much more. I putted your suggestions, (information would be better), to work on dsPIC33EP512GP504 and it is working exactly as you suggested. No more unexpected resets, and reading and writing occurs as predicted. No more magic numbers. . I tried to change starting erase address according to your methodology but I had a problem . Methodology doesn't work for certain multiples of starting erase address. For example for address 0x200 + (0x12 * 0x600) = 0x6E0 it doesn't work. Am I missing something ??

I just found out that start erase address works fine further up in program memory, say 0x200 + (0x36 * 0x600) = 0x14600. Maybe that's another device limitation, or the complexity of my project as I use about 270k of program memory (80%) as Visual TFT is involved and maybe I have allocation errors elsewhere in the project (I have to check that .

So Darko, in any case my problem is considered to be solved. I am happy with that.
Thank you very much. Your help is much appreciated.

[darko.ilijevski]

Hi,

I am glad I could help.

Yes, erasing memory when you work with the TFT project (e.g. a lot of pointers and memory locations hard to keep track of) is probably not the best idea to test this. Best would be to make a small test code, put it in a known location with the help of the #pragma orgall 0x200 linker directive, and then erasing the space that you know it's empty.

Regards.