Coding error in Customhttpapp.c Stack 5.42

[eagleeye]

This is what I have observed in the stack 5.42 code.

APP_CONFIG memory map in Stack 5.31
0x0000: NVM_VALIDATION_STRUCT
0x0006: APP_CONFIG

New stack 5.42
0x0000: Checksum
0x0001: APP_CONFIG 

maindemo.c (stack 5.42)

initappconfig() - demonstrates it is checking a validation byte
    // When a record is saved, first byte is written as 0x60 to indicate
       // that a valid record was saved.  Note that older stack versions
      // used 0x57.  This change has been made to so old EEPROM contents
      // will get overwritten.  The AppConfig() structure has been changed,
      // resulting in parameter misalignment if still using old EEPROM
      // contents.
      XEEReadArray(0x0000, &c, 1);

       if(c == 0x60u)
          XEEReadArray(0x0001, (BYTE*)&AppConfig, sizeof(AppConfig));


maindemo.c saveappconfig() (stack 5.42) -
   #if defined(EEPROM_CS_TRIS)
       XEEBeginWrite(0x0000);
       XEEWrite(0x60);
       XEEWriteArray((BYTE*)&AppConfig, sizeof(AppConfig));


CustomHttpapp.c - Reads from wrong location


   // Use current config in non-volatile memory as defaults
   #if defined(EEPROM_CS_TRIS)
      XEEReadArray(sizeof(NVM_VALIDATION_STRUCT), (BYTE*)&newAppConfig, sizeof(newAppConfig));
   #elif defined(SPIFLASH_CS_TRIS)
      SPIFlashReadArray(sizeof(NVM_VALIDATION_STRUCT), (BYTE*)&newAppConfig, sizeof(newAppConfig));
   #endif


Code should be

XEEReadArray(0x0001,(BYTE*)&newAppConfig, sizeof(newAppConfig));

Allan

[LubOlimex]

Hey there,

We actually don't use any of those functions since they refer to Microchip EEPROM memory on their boards. We mount different memory and never got to use the functions listed.

Regards,
Lub/OLIMEX

[eagleeye]

Hey there,

We actually don't use any of those functions since they refer to Microchip EEPROM memory on their boards. We mount different memory and never got to use the functions listed.

Regards,
Lub/OLIMEX

Understood, unfortunately, it IS USED on the PIC-WEB.
PIC-WEB uses a different EEPROM memory chip (AT45DB011). Microchip provided C logic
is used to store the network configuration to Olimex's chip. Every time
you make a network config change, it is written to Olimex's chip utilizing existing
Microchip C code.

If the user follows the instructions and presses the RESTORE defaults buttons,
they will end up with garbage for fixed IP.

The logic was changed on the maindemo.c but was not changed in customhttpapp.c
for stack 5.42



Allan

[LubOlimex]

Hey Allan,

I showed this thread to the programmer handling the PIC-WEB examples. He is implementing new features (UART terminal in the web page among them) at the moment. He asked what is the connection between the static IP change and the EEPROM configuration? What RESTORE you speak of - holding the BUT button (4 seconds at least) before power up/reset and then releasing it?

Please detail the information given, since we fail to see the problem.

Best regards,
Lub/OLIMEX

[eagleeye]

Hi
What I am saying is that the default example code from Microchip as of Stack 5.42
is now writing all saved information to your EEPROM chip in -SaveAppConfig()

the microchip example is writing the APP_CONFIG structure to EEPROM location 0001
and a simple check byte to location 0000. So app_config starts from 0001.

In customhttpapp.c when the APP_config is restored For DISPLAY, during HTTPPostConfig(void)
it is getting the APP_CONFIG from location 0006 instead of location 0001

Sorry about the Restore to defaults button issue. That was my mistake.

If you build the default application (at least in my case, I have downloaded and did it a few times)

you will NEVER be able to save any network config because the HTTPPOSTCONFIG stores the
user input, in struct "newappconfig". This is never passed to the new saveappconfig() function
because this new function does not have any parameters.. It uses a Globally declared AppConfig.

So you have to add



    XEEBeginWrite(0x0000);
       XEEWrite(0x60);
       XEEWriteArray((BYTE*)&newAppConfig, sizeof(newAppConfig));

Before it redirects to \protect\reboot.htm
at the end of the function.


Maybe I have a wrong copy of the example code but I have looked through it many
times and I have done the above to correct the issue.


Allan

[LubOlimex]

Thank you, Allan!

Indeed, there was a problem when trying to save network settings via the web interface in PIC-WEB! Also your workaround works flawlessly.

This is now updated and also there is a new UART/UEXT section of the example web page which allows receiving and sending commands over the UEXT.

Best regards,
Lub/OLIMEX

[SHIBBY]

Hi,

It looks like line 645 on CustomHTTPApp.c hasn't been updated despite Allan's warning. I've faced the same issue with the latest version of the example code: the NVM reading starts at a wrong adress. It's not a big issue as long as you update every settings on the same web page, otherwise if you just modify some parts of it the unmodified variables will end up having garbage in it and saved in NVM.

So, XEEReadArray(sizeof(NVM_VALIDATION_STRUCT), (BYTE*)&newAppConfig, sizeof(newAppConfig)); must be replaced by XEEReadArray(0x0001,(BYTE*)&newAppConfig, sizeof(newAppConfig));.

[SHIBBY]

There's another error I didn't notice until now, which will cause unnecessary EEPROM writings which is probably the result of a misunderstanding of what eagleeye wrote here:
on CustomHTTPApp.c at line 748, when saving new settings on the EEPROM, SaveAppConfig() function is called (which is useless since it won't save new user settings). You've added eagleeye's patch after that call, but you forgot to remove or comment it.

Code Select Expand

// All parsing complete!  Save new settings and force a reboot
#ifdef OLIMEX
SaveAppConfig(); //<- it should be removed or commented
// + Thanks to Allan ("eagleeye" in Olimex forum) for this fix +
XEEBeginWrite(0x0000);
XEEWrite(0x60);
XEEWriteArray((BYTE*)&newAppConfig, sizeof(newAppConfig));
// - Thanks to Allan ("eagleeye" in Olimex forum) for this fix -

[toozie21]

Hi,

It looks like line 645 on CustomHTTPApp.c hasn't been updated despite Allan's warning. I've faced the same issue with the latest version of the example code: the NVM reading starts at a wrong adress. It's not a big issue as long as you update every settings on the same web page, otherwise if you just modify some parts of it the unmodified variables will end up having garbage in it and saved in NVM.

So, XEEReadArray(sizeof(NVM_VALIDATION_STRUCT), (BYTE*)&newAppConfig, sizeof(newAppConfig)); must be replaced by XEEReadArray(0x0001,(BYTE*)&newAppConfig, sizeof(newAppConfig));.

BINGO!!!  I have been struggling with this same issue for about 5 weeks (putzing around in the evenings).  I tried all sort of workarounds, but the bottomline was that I was able to make changes via the serial interface fine, but as soon as I tried to make a change on the webpage, it would hose everything up.

Thank you for posting it, it saved my bacon!!