Using Parameter Block

[neil]

Hi Mark,
  The only parts of the parameter block we use in this current project is the NETWORK_PARAMETERS. We plan to use the flash memory to save/load this information. These network parameter block will only be modified with a direct connection to the unit, and not remotely. As this is the case , I cant see the benefit of having a swap parameter block, as the values are verified after being written.

A couple of things I want to check with yourself:

1. Looking at the application task there is a fnGetOurParameters() command. Does this check if there is a set of parameters in flash, and if valid will use these? Does this overwrite the default values at the top of the file (static const NETWORK_PARAMETERS network_default = {) ?

2. After the valid parameters are loaded, or default used  how do I gain access to active values, is it through pointer temp_pars?

3. When it comes to change the NETWORK_PARAMETERS values, can I simply place new values in these, and call  fnSaveNewPars(SAVE_NEW_PARAMETERS);  ?

4.The does the processor have to be reset for new values to take place?

Many Thanks
Neil

[mark]

Hi Neil

fnGetOurParameters() is application demo code and so is an example of how to work with parameters. It checks first for temporary parameters (to be loaded to see if they operate correctly - these will be deleted if not validated within 3 minutes) and then for valid ones and, if neither found, will load the default set from the code.

Also the use of a temporary block is demo project specific and could be simplified. There are two copies of the parameters in SRAM (temp_pars and parameters). This allows the temporary ones to be individually modified, reset and adjusted before the being actually committed to the working set.

Some of the parameters may be modified directly in temp_pars and some directly in parameters so you can decide which are handled how and you can also remove an non-required set.

When network parameters are changed, the demo project changes them first in the backup temp_pars and saves these as temp values. It then resets and "tries" using the temporary values until the timeout or the user confirms that they are correct. It is also possible to change then directly in network (and directly save as valid)  and they will immediately be used (without a reset). In this case it is useful to also call fnDeleteArp() to clear the local ARP table otherwise it may conain a few values no longer valid for the new network and these could cause some problems until they time out.

Regards

Mark

[neil]

Hi Mark,
  Thanks for the reply.

I see within ethernet task that fnGetEthernetPars(); gets called (which is in application.c), which in turn loads active parameters in variable network.

If I want to change them (looking at the fnSaveNewPars(..) within debug.c code), I can simply modify the network variables, and call the following:


   fnSetPar((unsigned short)(PAR_NETWORK), (unsigned char *)&network, sizeof(NETWORK_PARAMETERS));

Is this correct, and if I havent saved anything before, do I need to save the PAR_DEVICE too (even though I am not using them)?

As this info will be sent only once at inhouse setup, then a restart will be the way we will go.

Thanks
Neil

[mark]

Hi Neil

Yes, you are correct, a routine is needed to supply the Ethernet settings. Where the settings are taken from is however up to the application specific content of fnGetEthernetPart().

fnSetPar() can be used as you suggest to save parameters directly to FLASH. If you are not using any more parameters, this all that you need to save.

Remember that the parameters will always occupy at least a page in memory (2k in the Coldfire internal RAM FLASH) so it may be worth still reserving some other variables if required. Since the MAC address should never be lost, it would however then be recommended to use a swap block. For one-time setting a swap block is not needed since the saved data has no risk of being lost when modifying something in the block.

The uParameterSystem is also discussed in the following document: http://www.utasker.com/docs/uTasker/uTaskerFileSystem_3.PDF (from page 9).

Regards

Mark

PS. Again I recommend playing around with this in the simulator since it is much more practical that programming FLASH on the board to test such stuff.

[neil]

Hi Mark,
 Thanks for the reply.

1. I looked at the uFilesystem manual as you mentioned, but cant see anywhere where it mentions the 2K of RAM it uses.

2. Looking at applications.c, does the code load PARS and NETWORK into the 2K during the fnGetEthernetPars() routine?

3.After the parameter are loaded, into RAM, are the PARS variables then accessable from *parameters?

4. As I dont need the PARS information , I assume I can replace these with my own, and simply use the same method for accessing them as in application.c?

Regards
Neil

I would then modify TEMPPARS, and add my own structures?

[mark]

Hi Neil

My mistake, I didn't mean to write RAM but wanted to write FLASH!!

The content of the parameters is defined in application.h so can be modified to suit the application.

Sorry about the confusion..

Regards

Mark

[neil]

Hi Mark,
  When it loads the parameter block, doesnt it have to load it into RAM before using it?

Neil

[mark]

Hi Neil

This depends on the FLASH type and the application.

The demo always loads it to a local copy and works with the local copy. This is also compatible with parameters in external SPI FLASH since these can not be addresses directly (with a pointer) and so have to be fetched before use. When internal FLASH is used, it is also possible to set a struct pointer to their location in the FLASH and work with them directly (of course they are const values in this case and they can not be modified directly, as a local copy can be).

Regards

Mark

[neil]

Hi Mark,
   I have a routine which sends down the network setup, starting at the MAC address, then the parameter block is updated to FLASH. I reset the processor board, in turn the network settings are sent through the serial port.

Here is my code: (I am not using the swap method, and parameters are in FLASH)

   //Ptr buffer holds network settings
    uMemcpy((CHAR*)&network.ucOurMAC,&Ptr[0], MAC_LENGTH+IPV4_LENGTH+IPV4_LENGTH+IPV4_LENGTH+IPV4_LENGTH);
    fnSetPar((unsigned short)(PAR_NETWORK), (unsigned char *)&network, sizeof(NETWORK_PARAMETERS));

  DisplayNewSettings(); //this dispays all settings in 'network' . At this point all values are what they should be


The values printed out after the fnSetPar() command displays the correct values. But If I reset the board, the NETWORK values are only sometimes correct. It seems that the information is not always saved.

Neil

[mark]

Hi Neil

I think that the problem is that the new parameters are writing 'on-top' of the old ones. This means that when changing bits to '0' it seems to be fine but when trying to change bits to '1' they stay at zero (due to FLASH characteristics).

Reading the document http://www.utasker.com/docs/uTasker/uTaskerFileSystem_3.PDF there is a note on page 9/14 that it is necessary to delete before modifying parameters and that there is a risk of losing data if a reset occurs between the delete and the write.

It is however possible to know whether the data is good by checking the return value from fnGetPar() - eg. fnGetPar(TEMPORARY_PARAM_SET, Ptr, MAC_LENGTH+IPV4_LENGTH+IPV4_LENGTH+IPV4_LENGTH+IPV4_LENGTH);
A negative value means the values are not valid and so were not copied.

Note that in a single block parameter system the parameters are marked always as temporary and not as validated (this is because only in a swap block system can one be validated and the other temporary - therefore this is adequate to inform that there is something there...).

You should therefore be able to solve the problem like this:

    uMemcpy((CHAR*)&network.ucOurMAC,&Ptr[0], MAC_LENGTH+IPV4_LENGTH+IPV4_LENGTH+IPV4_LENGTH+IPV4_LENGTH);
    fnDelPar(INVALIDATE_TEST_PARAMETER_BLOCK);
    fnSetPar((unsigned short)(PAR_NETWORK), (unsigned char *)&network, sizeof(NETWORK_PARAMETERS));

Note that ALL parameters are deleted with fnDelPar() so you need to write ALL back again - best in one fnSetPar() to ensure that they are only marked as valid once all have really been saved.

Regards

Mark

[neil]

Hi Mark,
  Thanks , I will give it a try.

Is it okay to add to the parameter structure (I would add at the end, and will only be 10 bytes)? Or would it be okay to add the 10 bytes to the end of the network structure? I plan to give every board its unique ID, along with the MAC address. This will be set up only once during in house setting up.

Neil

[mark]

Hi Neil

I would add to the parameter structure. (Network + application) and save them all together as one block.

Regards

Mark