CYW20376S EPROM bleappfwu_writeMem API does not work

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
ThYo_2228536
Level 3
Level 3
First like received First like given

When trying the OTA update using Wiced Smark SDK and a CYW20376S

which is a module with internal EPROM. I can't get the bleappfwu_writeMem to work.

refer to ws_upgrade_store_to_nv inside ws_upgrade.c sample file.

I didn't see the following warning so I assume writing to NVRAM should be possible.

void ws_can_write(void)

{

   if ((Config_DS_Location != nv_loc_len[ws_upgrade_active_nv_type].ds1_loc) &&

                 (Config_DS_Location != nv_loc_len[ws_upgrade_active_nv_type].ds2_loc))

         {

             // If active DS is neither DS1 nor DS2 we expect to see, fail the download.

             ble_trace0("WARNING: Upgrade will fail - active DS is not one of the expected locations.\n");

             ble_trace0("WARNING: Are ConfigDSLocation and DLConfigVSLocation in the .btp set up as in nv_loc_len[]?\n");

         }

}

What I am not sure if wether I need to change the BTP file or update nv_loc_len ?

Can you help ?

// Recommended offsets for EEPROM

// --------------------------------------------------------------------------------------------------------------------

// |  SS1 (256b @ 0)  |  SS2 (256b @ 0x100)  |  VS1 (1024b @ 0x140)  | DS1 (30.5Kb @ 0x580)  | DS2 (30.5Kb @ 0x8000)  |

// --------------------------------------------------------------------------------------------------------------------

// Recommended offsets for Serial Flash. All sections have to be on a 4K sector boundary.

// Ensure that the .btp file has the same values as the values below:

// ConfigDSLocation = <ds1_location>

// DLConfigVSLocation = <vs_location1>

// DLConfigVSLength = <vs_length1>

// The following is the layout of the SF.

// -------------------------------------------------------------------------------------------------------------------------------------------

// |  SS1 (4K @ 0)  |  SS2 (4K @ 0x1000)  |  VS1 (4K @ 0x2000)  | VS2 (4K @ 0x3000)  | DS1 (24K @ 0x4000)  | DS2 (24K @ 0xA000)  |  UNUSED

// -------------------------------------------------------------------------------------------------------------------------------------------

// For reference only.

// UINT32 ss_locations[2]       = {0, 0x1000};

// UINT32 vs_location1          = 0x2000;     // VS section occupies 1 sector

// UINT32 vs_length1            = 0x1000;     // 4K = 1 SF sector

// UINT32 vs_location2          = 0x3000;     // Double buffer for VS for failsafe storage.

// UINT32 vs_length2            = 0x1000;     // 4K = 1 SF sector = vs_length1

// NV locations and lengths. Ensure that the BTP file has the same values for the parameters in the

// inline comment on the right.

const WS_UPGRADE_NV_LOC_LEN nv_loc_len[2] =

{

    {

        /* .ss_loc = */     {0, 256},

        /* .ds1_loc = */    0x580,         // ConfigDSLocation

        /* .ds1_len = */    0x7A00,        // ~31KB

        /* .ds2_loc = */    0x8000,

        /* .ds2_len = */    0x7A00,        // ~31KB

        /* .vs1_loc = */    0x140,         // DLConfigVSLocation

        /* .vs1_len = */    0x400,         // DLConfigVSLength

        /* .vs2_loc = */    0,             // No VS2 for EEPROMS

        /* .vs2_len = */    0              // No VS2 for EEPROMS

    },

    // We are assuming that we have a 64KByte Serial Flash. If the SF is larger, you may change ds1_len, ds2_loc, ds2_len

    // accordingly.

    {

        /* .ss_loc = */      {0, 0x1000},

        /* .ds1_loc = */     0x4000,          // ConfigDSLocation

        /* .ds1_len = */     0x6000,

        /* .ds2_loc = */     0xA000,

        /* .ds2_len = */     0x6000,

        /* .vs1_loc = */     0x2000,          // DLConfigVSLocation

        /* .vs1_len = */     0x1000,          // DLConfigVSLength

        /* .vs2_loc = */     0x3000,

        /* .vs2_len = */     0x1000

    },

};

The FW is build using 20736_EEPROM.btp file

DevicePreset "20736 EEPROM (64 byte pages)"

{

  ConfigFSOffset = 0

  DLReadWriteMode = "Cortex M3 HCI"

  DLWriteVerifyMode = "Write and verify"

  DLMaxWriteSize = 64

  DLSectorEraseMode = "Chip erase"

  DLDTRReset = 0

  DLPostResetDelay_ms = 100

  DLAutobaud = 0

  DLAutobaudRepeat = 1

  DLAutobaudRepeatDelay_ms = 200

  DLWaitForLaunchAnnounce = 0

  DLConfigReprogramIF_PLL = 0

  DLUsbBulkPipe = 0

  DLMinidriver = 1

  DLMinidriverPathUSB = "[MINIDRIVERS]\20732\usb.hex"

  DLMinidriverPathNET = "[MINIDRIVERS]\2072\uart.hex"

  DLMinidriverPathSDIO = "[MINIDRIVERS]\2072\sdio.hex"

  DLMinidriverPathUPRX = "[MINIDRIVERS]\20732\uart.hex"

  DLMinidriverPathUART = "[MINIDRIVERS]\20732\uart.hex"

  DLFirmware = 0

  DLFirmwareTargeting = "Standard"

  DLConfig = 1

  DLConfigTargeting = "EEPROM"

  ConfigPath = "[BTP_FOLDER]\A_20732A0-hello_sensor-rom-ram-spar.cgs"

  DLConfigFixedHeader = 1

  DLConfigFixedHeaderFromBurnImage = 0

  DLConfigOmitRF_PLL = 1

  DLConfigIncludeChargerConfig = 0

  DLConfigDFUKey = 4294967295

  DLConfigCrystalFreqMHzX10000 = 240000

  DLConfigOutputPowerAdjust = 40

  DLConfigImpedanceMatchTuning = 31

  DLConfigSerialControlBaudRate = 115200

  DLConfigEEPROMAccessSpeed = 100

  DLConfigVSOffset = 0

  ConfigDSLocation = 1408

  DLConfigSSLocation = 0

  DLConfigIncludeBTWSecurityKey = 0

  DLConfigVSLocation = 320

  DLConfigVSLength = 1024

  DLConfigRemoteDeviceCount = 0

  DLConfigBD_ADDRBase = "20736A1*****"

  DLConfigFixedBD_ADDRFlag = "Can change"

  OTAFWUAckAllRecords = 0

  OTAFWUUpdateFirmware = 1

  OTAFWUUpdateConfig = 1

}

0 Likes
1 Solution

Below is a picture of the eeprom layout. You need not erase anything or write twice. And OTA does not erase the nvram. Your new data should occupy SS2 and DS2 and they will become active sections.

Figure7.png

You may also want to check out our sample android code from the below thread.

SOTAFU for Android and iOS

View solution in original post

8 Replies
ThYo_2228536
Level 3
Level 3
First like received First like given

FYI  here are a few value that I was able to lo

20:30:26 - ws_can_write: DS:0580 SS:0000

ble_trace2 ("\ws_can_write: DS:%04x SS:%04x", Config_DS_Location, Config_SS_Location);

20:30:26 - E: Free bytes = 0x00003914

ble_trace1("E: Free bytes = 0x%08X", cfa_mm_MemFreeBytes());

20:33:36 - Active: 0x00000580, Upgrade: 0x00008000, UG length: 0x00007A00

UINT32 ws_upgrade_init_nv_locations(void)

{

    if ((Config_DS_Location != nv_loc_len[ws_upgrade_active_nv_type].ds1_loc) &&

            (Config_DS_Location != nv_loc_len[ws_upgrade_active_nv_type].ds2_loc))

    {

        // If active DS is neither DS1 nor DS2 we expect to see, fail the download.

        ble_trace0("Active DS is not DS1 and not DS2. Cannot upgrade.\n");

        return 0;

    }

    active_ds_location = Config_DS_Location;

    upgrade_ds_location = (active_ds_location == nv_loc_len[ws_upgrade_active_nv_type].ds1_loc) ?

        nv_loc_len[ws_upgrade_active_nv_type].ds2_loc : nv_loc_len[ws_upgrade_active_nv_type].ds1_loc;

    upgrade_ds_length   = (active_ds_location == nv_loc_len[ws_upgrade_active_nv_type].ds1_loc) ?

        nv_loc_len[ws_upgrade_active_nv_type].ds2_len   : nv_loc_len[ws_upgrade_active_nv_type].ds1_len;

    ble_trace3("Active: 0x%08X, Upgrade: 0x%08X, UG length: 0x%08X", active_ds_location, upgrade_ds_location, upgrade_ds_length);

    // ble_tracen(ss_data, sizeof(ss_data));

    return 1;

}

20:52:43 - Checking readable attribute ff05

20:52:43 -

20:52:43 -  permission check retCode = 00

20:52:43 - ws_upgrade_store_to_nv 1020 60   <- address, len

20:52:43 - WS_UPGRADE_NV_IS_EEPROM

20:52:43 - ws_upgrade_store_to_nv v: 0xFF0083FC  <- v address

20:52:43 - Could not write to mvram!

20:52:43 - f02001016070477e48006800f0400070

20:52:43 - 477c48016821f0400101607047794801

20:52:43 - 6841f040010160704770b57248046825

20:52:43 - 7835b97248062204f10a0108

0 Likes

I am referring to ws_upgrade.c of the ota_firmware_upgrade sample app. Your selection of the location and length of SS and DS are correct based on a 64Kbyte eeprom of the sip module. The eeprom could be corrupted. Can you do a recovery of it? And can you do a download of the wiced_sense2 FW onto your module? What is the size of your application binary? It should be lower than 30Kbyte.

0 Likes

Bin file is 17 KB

Hex file is 34 KB

I can flash and download the APP just fine.

I tried on multiple board and they all give the

same result. Where does

permission check retCode = 00

log entry is coming from. Is the EPROM in

a read only state ?

My SDK include wiced_sense app but not

wiced_sense2

I am using Wiced SDK 2.2.0

0 Likes

"retcode" is a kind of diagnostic message, and 00 means that permission is allowed and there is no issue.

I am a little confused here and so let's take a step back.

i) You are trying to perform an OTA of your app on your product (module based)

ii) You encountered errors and claimed that bleappfwu_writeMem did not worked

iii) You were able to download your app onto the module, but OTA failed on several of them after that

Can you do a clean and rebuild you application? Download it onto a module and then perform an OTA. Can you

post the log trace?

I noted that you are using 2.2.0. Can you upgrade to 2.2.3?

I tried the ota_fw_upgrade app on my tag boards and there weren't any issue.

How to recover WICED Sense2

0 Likes

i) yes

ii) the return code is not in line with a success code

do I need to erase the chunk of eprom I want to write too prior to writing to it ?

If so what value should I use. I noticed a bunch of 0xFF at the end

iii) I guess I was able to upload once on one module but not any more.

I tried to use 2.2.3 on windows but same results.

I dumped and compared what I sent from Android and received on the device and all the data matches.

I then dump to uart the data read while trying to compute the CRC check. Either the data is from an older write

or there were mismatched during the write operation.

0 Likes

Can you do the following?

1) recover the epprom with advice from the below thread

2) download the app via the SDK as normal

3) perform an OTA via win7, with a broadcom-based BT dongle

Attached the log for (2) and (3). And use sdk 2.2.3.

Rebooting/Recovery of a BCM20737S **HELP**

I do not have a Windows BLE USB dongle and I am not planning to use Windows OS to perform OTA.

I am using Android.

I purchased 150 module and they all behave the same.

FW is flashed one time only then I am trying to update a FW over the air.

I verified that all data sent from Android and received inside FW matches.

I am dumping all data I am writing  group in a 60  byte buffer and I am doing the same during verification steps

when trying to read all 20 byte and grouping them in a 60 byte buffer as well.

The app can be programmed using WICED and RX.TX,GND and 3.3V pin along with FTDI mini module just fine all the time.

The error I am getting when writing to the EPROM is

LEFWU_ERR_UNKNOWN

What a useful error message....

// The error codes returned by FWU - same as std HID handshake

enum

{

    LEFWU_SUCCESS             = 0x00,

    LEFWU_ERR_NOT_READY       = 0x01,

    LEFWU_ERR_INVALID_CMD     = 0x02,

    LEFWU_ERR_UNSUPPORTED_REQ = 0x03,

    LEFWU_ERR_INVALID_PARAM   = 0x04,

    LEFWU_ERR_UNKNOWN         = 0x0E,

    LEFWU_ERR_FATAL           = 0x0F

};

Do I need to erase the EPROM some code are doing this for Serial Flash ?

Is it mandatory to write 0xFF on the EPROM before being able to write something else ?

Is there a trick to write properly ?

Do I need to write twice ?

Do I need to wait between write ?

Do I need to write in a loop using a larger buffer along with the watch dog API call like what is done during the CRC verification loop ?

18:21:56 - 18:21:56 - total offset:0 buffer offset: 20 total:16085 len:20

18:21:57 - 18:21:57 -

18:21:57 - 18:21:57 - blecm evt handler:

18:21:57 - 18:21:57 - 13050140000200

18:21:57 - 18:21:57 -

18:21:57 - 18:21:57 - Checking readable attribute ff05

18:21:57 - 18:21:57 -

18:21:57 - 18:21:57 -  permission check retCode = 00

18:21:57 - 18:21:57 -

18:21:57 - 18:21:57 - total offset:0 buffer offset: 40 total:16085 len:20

18:21:57 - 18:21:57 - ws_upgrade_store_to_nv 0 60

18:21:57 - 18:21:57 - ws_upgrade_store_to_nv v: 0xFF008000 -16744448 <== v offset in hexa and in decimal all incrementing by 60 byte

18:21:57 - 18:21:57 - ws_upgrade_store_to_nv ret:LEFWU_ERR_UNKNOWN

18:21:57 - 18:21:57 - a21a006c3000001b3300000000000014    <-- byte written

18:21:57 - 18:21:57 - 1e0802b0040000000000000000720600

18:21:57 - 18:21:57 - 0b0000000001b30100176902000000b8

18:21:57 - 18:21:57 - 0400001bb7000a05005c4520

...

18:24:04 - 18:24:04 - total offset:16020 buffer offset: 40 total:16085 len:20

18:24:04 - 18:24:04 - ws_upgrade_store_to_nv 16020 60

18:24:04 - 18:24:04 - ws_upgrade_store_to_nv v: 0xFF00BE94 -16728428

18:24:04 - 18:24:04 - ws_upgrade_store_to_nv ret:LEFWU_ERR_UNKNOWN

18:24:04 - 18:24:04 - 4840f6c3fa0a4a0a4b22f00f021a60fe

18:24:04 - 18:24:04 - f79afbbde80840fef77cbb007a200000

18:24:04 - 18:24:04 - 7a20004c020000d80500004c7c200044

18:24:04 - 18:24:04 - 8220005c0c20000b04002582

18:24:04 - 18:24:04 - bc8104

18:24:04 - 18:24:04 -

18:24:04 - 18:24:04 - Checking readable attribute ff05

18:24:04 - 18:24:04 -

18:24:04 - 18:24:04 -  permission check retCode = 00

18:24:04 - 18:24:04 -

18:24:04 - 18:24:04 - total offset:16080 buffer offset: 0 total:16085 len:5

18:24:04 - 18:24:04 - ws_upgrade_store_to_nv 16080 5

18:24:04 - 18:24:04 - ws_upgrade_store_to_nv v: 0xFF00BED0 -16728368

18:24:04 - 18:24:04 - ws_upgrade_store_to_nv ret:LEFWU_ERR_UNKNOWN

18:24:04 - 18:24:04 - 2000fe0000    <- last 5 byte no a modulo of 20 byte

18:24:05 - 18:24:05 - ws_upgrade_verify

18:24:05 - 18:24:05 - ffffffffffffffffffffffffffffffff  <- reading all 0xFF

18:24:05 - 18:24:05 - ffffffffffffffffffffffffffffffff

18:24:05 - 18:24:05 - ffffffffffffffffffffffffffffffff

18:24:05 - 18:24:05 - ffffffffffffffffffffffff

0 Likes

Below is a picture of the eeprom layout. You need not erase anything or write twice. And OTA does not erase the nvram. Your new data should occupy SS2 and DS2 and they will become active sections.

Figure7.png

You may also want to check out our sample android code from the below thread.

SOTAFU for Android and iOS