Author Topic: memory exception storing parameters in flash  (Read 4323 times)

Offline marcelo_

  • Newbie
  • *
  • Posts: 25
    • View Profile
memory exception storing parameters in flash
« on: July 08, 2010, 09:50:46 PM »
Hi Mark
I'm customizing the stored configuration parameters to my application's needs.
I extended the PARS structure/typedef with the necessary members, and also the webInterface logic to cope with them. All works fine, except when I do some changes and try to save the new parameter values, using the simulator.

The exception occurs at line 2395 of M5223X.c. The code there is as follows

   #ifdef _WINDOWS
    if (ulValue & ~(*(unsigned long*)ptrAdd)) {          // we check that we are not trying to program a bit from '0' to '1'
        *(unsigned char*)0 = 0;                                // this will fail so signal it when debugging
    }
    #endif

It's clear to me that the exception is intentional, because the application is trying to do an illegal operation. But the current demo code does not try to erase the flash prior to write the new conf, and I cannot find a suitable function to do that.
But the most intriguing thing is that I was playing some times with the conf before the customization attempt, without trouble.
Note: when I save the conf for the first time, all is OK, and checking the "flash file", it's as expected. The thing goes wrong when I try to save some new values, i.e, I'm trying to overwrite the flash. 

TIA
Regards
Marcelo


Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3188
    • View Profile
    • uTasker
Re: memory exception storing parameters in flash
« Reply #1 on: July 08, 2010, 10:28:48 PM »
Hi Marcelo

When using the uParameterSystem interface it should swap between 2 FLASH blocks and handle writing to the new block and deleting the old one. Parameters can also be saved temporarily and then both blocks are used - this is the validating state which lasts until the new set has been confirmed.

I could imagine such a problem when both blocks are occupied (one temp and one confirmed) but this would mean that the use of the temporary block is not correct - such an error would warn of this. There could however be other reasons.

I would do the following:
1) Let the error occur so that you can see the address of the location in the simulated FLASH (this is just a RAM location on the PC which will tend to remain the same). Note the value and also look at the content in a memory window (the start of the parameter blocks is easy to recognise due to the 0x5555 indication validity etc.).
2) Stop the simulator and delete the simulated FLASH content file.
3) Start again and monitor the use of the memory when saving once, twice, etc.

You should be able to see what the location is being used for and work out why it is being written a second time without being deleted in between. Maybe you also see that the area is overlapping with some other use?

Good luck

Regards

Mark


Offline marcelo_

  • Newbie
  • *
  • Posts: 25
    • View Profile
Re: memory exception storing parameters in flash
« Reply #2 on: July 08, 2010, 11:03:35 PM »
Thank you, Mark.

Because I need lots of parameters, I did my own web pages.
In that pages, when the user clicks the submit button, he/she can also set a checkbox to "write to flash immediately" ( no need to go to Lan config page ).
When the checkbox arrives on, the switch case ( in fnHandleWeb() ) simply calls  fnSaveNewPars(SAVE_NEW_PARAMETERS_VALIDATE);

I can see that is wrong: when I change some parameter values from my own pages and then do the complete cycle thru "save changes" and "validate changes" in the Lan config page, all went OK.

So, I will delete the "write now" checkboxes and may be move the save/validate buttons ( the commands ) to the main menu page, with a new alert field regarging changes are pending.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3188
    • View Profile
    • uTasker
Re: memory exception storing parameters in flash
« Reply #3 on: July 09, 2010, 09:37:44 AM »
Hi Marcelo

If you prefer not to use the validation technique you can also directly validate new parameters rather than saving them temporarily. See http://www.utasker.com/docs/uTasker/uTaskerFileSystem_3.PDF for details.

Regards

Mark