HttpsUploadCert example

[SeeCwriter]

In the HttpsUploadCert example on a NANO with v3.3.5 of the tools, on bootup function CheckNVSettings() is called, and the debug messages indicate that it always formats flask disk.

Code: Select all

 : Formatting flash drive...
NV Settings Saved
 : Default certificate and key size problems
NANO54415SX-E9 : Setting up new default storage info

I added my own debug printf()'s and determined that argument returnToFactory is always 0 and NV_Settings.STDEFFSVerifyKey is always zero.
I verified that the flash file system is initialized successfully prior to calling CheckNVSetting(). And the project's Compcode setting is 0x4000 0x700000.

[SeeCwriter]

Still trying to figure out why NV_Settings is always zeros after a reboot. Looking through the code it appears that the NV_Settings structure is saved as raw data, not as a file, since it does not use fs_write. Does that mean that the NV_Settings structure is written to a different area of flash than the reserved area defined by Compcode?

[TomNB]

Yes, that is correct. If using an example with NV_Settings, it is saved the the User Parameters Area, which is a single sector of flash stored as raw data, no file system.

[SeeCwriter]

That's fine. As I understand it, the User Parameters area is not the area after the high flash memory address set in Compcode, which is 0x700000. That area is a file system area. I use that area to store SNMP configuration files. If correct, why does CheckNVSettings() format the flash drive when invalid data is in the NV_Settings structure, which I think is a different area of memory?
This snippet is from CheckNVSettings.

Code: Select all

    if ( (NV_Settings.STDEFFSVerifyKey != STD_EFFS_VERIFY_KEY) || returnToFactory )
    {
        debug_iprintf("Formatting Flash Drive...\r\n");
        int rc = fs_format(NOR_DRV_NUM);
        if (rc != FS_NOERR) debug_iprintf("*** ERROR Formatting Flash Drive: %d\r\n", rc);
        NV_Settings.STDEFFSVerifyKey = STD_EFFS_VERIFY_KEY;
        if (SaveUserParameters(&NV_Settings, sizeof(NV_Settings)) != 0) { iprintf("NV Settings Saved\r\n"); }
    }
    else
    {
        debug_iprintf("STD_EFFS_VERIFY_KEY is Valid\r\n");
    }

[Jon]

Hi SeeCwriter,

For that particular example, the files that are uploaded are stored in flash, but the settings themselves are stored in the user params space. After you upload the files, if you hit "F" in the serial prompt, you should be able to see this. The values stored in the NV_SettingsStruct in this example are the certificate source, the cert length, and the key length.

I just checked this example and it seems to be working on my end. Did you have another example loaded on this device that also used NV_Settings? To be sure, it might be worth adding

FlashErase((void *)&UserParamBase, (FlashAppBase - UserParamBase));

once just to clear the entire UserParam space, then removing that line and reloading the app. If you still get the failed check, we'll need to see what the key values are as opposed to what they should be.

Kind Regards,
Jon

[SeeCwriter]

I haven't tried to upload any files yet. I'm trying to figure out why the default settings that are supposedly saved don't appear to be saved or are unable to be read. On bootup, CheckNVSettings is called right after ethernet initialization, and parameter NV_Settings.STDEFFSVerifyKey is always zero. So the flash drive is formatted and NV_Settings.STDEFFSVerifyKey is initialized and saved. Yet on the next bootup, it does the same thing.

[Jon]

Hi SeeCwriter,

Have you tried adding the flasherase() call that I mentioned in my previous message? I'm wondering if you have stale user param data in there that is written past the old user param data and is causing some issues. This flasherase() call will delete all of the user param space. After which, you can remove it, and the device should function as expected.

Kind Regards,
Jon

[SeeCwriter]

I'm sorry, I got busy with something else and forgot. I just tried the FlashErase, and it didn't make a difference.

I'm curious as to how much of example HttpUploadCert is required to be able to upload certificates & keys. I've implemented TLS certificates with v2.9.5 on the MOD5441X, and I only needed to add one source file with 6 functions and a single webpage. Whereas the v3.x example has 11 source files and 10 html files. The 3.x version seems way more elaborate.

[Jon]

Hi SeeCwriter,

Hm, okay. Would you mind sending me your project as is and the .bin your generating? If you don’t mind opening a ticket and attaching it, I’ll be sure to pick it up and take it. I want to run it on the board I have here and see if I'm getting the same thing.

For the example, the majority of the files are used to manage the flash file system. You have 4 that are used to manage the web interface:

certifcatekey.cpp
configweb.cpp
formtools.cpp
post.cpp

ssluser.cpp manages using the flash based cert and key or the default one that's provided.

You could probably manage to trim a lot of this down. If you just wanted to store the cert in user params directly, you could forgo the file system all together. Also, if you're not really interested in managing a default cert, you can get rid of the various checks there. You could also trim down the web interface. The app is designed to give folks something they could use more directly in their applications, though, and for a lot of our customers, the extra functionality is helpful.

Kind Regards,
Jon

[SeeCwriter]

Before I send you the project I wanted to delete the project and recreated it to make sure I did it correctly. I had forgotten that the example program has none of the EFFS files, such as includes "effs_std.h" in main.cpp. The only place I found the effs files was in nburn/examples/_common/EFFS/STD/src. Adding that path to the project in "C/C++ General->Paths and Symbols->Includes" did not work, so I copied the files to the project. So this time, it no longer formats the flash drive on each bootup.

The only difference I can think of is that, I used the EFFS files from existing projects, which some are from v2.8.3. But they look identical.