- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
}
Solved! Go to Solution.
- Labels:
-
FlashEEPROM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
You may also want to check out our sample android code from the below thread.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
"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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
You may also want to check out our sample android code from the below thread.