Smart Bluetooth Forum Discussions
Hello,
We developed our product, HW and SW. We used BCM20737S. it was not at all easy. It was a long and difficult path (problem wirh library, ESD, etc....)
So now we have a good product, it works and it is not expensive. Good module.
Start with certification.
Start with read all document, etc...
Start with a authorized company for FCC certification.
Ok BCM20737S is not full certificated for FCC (because it has not metal shield).
Wait response from american colleagues of authorized company...
Result:
For our product we need to do follow certification:
CFR 47 part 15 Subpart B and
CFR 47 Part 15.247, 15.205, 15.209 subpart C
My questions:
1 . is it true? Do we need all of these steps for obtain FCC certifcation?
Our product is a normal portable product with a coin battery CR2450 and a simple half duplex serial comunication with module (module, two metal pin, diodes, capacitor and some resistance).
2. Delta approval = no certification? because, we spent less to certify products with chipset
Show LessWhen 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
}
Show LessI am working with BCM20737S and we have to keep track of time. We have an external 32.768KHz crystal and everything is setup according to the rtc_sample example. Every second I check the time using rtc_getRTCTime. The output is correct for a couple of minutes and then the clock is off by one second. I monitored the behavior of the system by printing the seconds. Bellow I have the debug log. The system gets the time from a different device and there is one second difference between the time in the
system and the PC running the debug viewer (plus the timezone difference). The difference is stable (1 second) until it reaches the point at 16:56:02. There I have for 2 different seconds the same value returned from the rtc_getRTCTime. I am not sure why this is happening. This happens after a couple of minutes after the time is synchronized and I can't see any type of periodic behavior so far.
In a thread I noticed that they were using the bleapputils_changeLPOSource(LPO_32KHZ_OSC, FALSE, 250); line to setup the crystal.
When I am using this command in the create function, I get the opposite effect, the clock is jumping a second every now and then. I am not sure if it is the driftRate wrong
and how to correctly set it up. I will disable to sleep to see if that helps but I must have the sleep enabled.
16:55:56 - 21:55:55
16:55:56 - CurrSec: 55
16:55:57 - 21:55:56
16:55:57 - CurrSec: 56
16:55:58 - 21:55:57
16:55:58 - CurrSec: 57
16:55:59 - 21:55:58
16:55:59 - CurrSec: 58
16:56:00 - 21:55:58
16:56:00 - CurrSec: 58
16:56:01 - 21:56:0
16:56:01 - CurrSec: 0
16:56:02 - 21:56:1
16:56:02 - CurrSec: 1
16:56:03 - 21:56:1
16:56:03 - CurrSec: 1
16:56:04 - 21:56:2
16:56:04 - CurrSec: 2
16:56:05 - 21:56:3
16:56:05 - CurrSec: 3
16:56:06 - 21:56:4
16:56:06 - CurrSec: 4
16:56:07 - 21:56:5
16:56:07 - CurrSec: 5
16:56:08 - 21:56:6
16:56:08 - CurrSec: 6
Show LessThe OTA upgrade can't work in the WIndows 10. The following is my setting:
OS: Windows 10 Version 1703
Hardware: Tag 3 EVB
Project: sample code - ota_secure_firmware_upgrade
I also disable the power save in the power management panel.
Here are my steps:
1. Create OTA signed file: The OTA signed file can create by WsRsaSign.exe
2. WsRsaSign command: WsRsaSign rsa.pri BLE_LVDT_NEW-BCM920737TAG_Q32-rom-ram-Wiced-release.ota.bin 3A20 1 0
The OTA app ID(0x3A20) is same in the hello_sensor.c.
The rsa.pri is create
3. Start OTA procedures
The OTA firmware upgrade stuck in the "Transfer step". The OTA step and command is working in my computer before the Windows automatically updates.Any help is appreciated.
Show Lesswe use Cypress 20737 SOC and based on hello-sensor for ur application
in some sensor query and calculation at timer thread (1sec-base).
However, we suddenly find that if user keeps pressing button without stop,
it will cause system reset. Is it that in timer thread, our app is too busy so that if keeping button-press,
SOC will spends more time on button behavior and delay the timer thread tasks.
so how can we handle this situation if it happens???
Show LessI'm using the ota_firmware_upgrade example code in WICED ide. I had to modify the target from BCM920737TAG_Q32 to the CYBLE_013025_EVAL target. This meant that I had to also change the GPIO_PIN_WP pin to -1 according to the platform.h file, but I am not sure if that is supposed to stay that way.
I compile the code, install, and see that it shows up on the Andriod WICED app. I then use the WsOtaUpgrade program provided in the peerapps folder, which notify's that it needs to upgrade because this project was made for compilers from 2012. I run the app in debug with a custom command input of the bin file, it launches, I confirm that the HELLO app is connected on ble, and I press start, and it does nothing. After stepping through the debugger, I see that it quits on line 406 of Win8Interface.ccp
hr = pSetDescr(hService, &m_descrClientConfig, &DescriptorValue, BLUETOOTH_GATT_FLAG_NONE);
where it times out.
I went onto the firmware of the chip and found that the hello_sensor_write_handler doesn't ever get used in the start process attempt.
How am I supposed to get this example code to work? It is something that I will need to be able to do if I am going to try and port it over into some of my other code.
Thanks.
Show Less- P_UART question
There may be two sets of P_UART pins
- P32 (Tx) and P33 (Rx)
- P0 (Tx) and P2 (Rx)
I have used P32/P33 for debug traces.
Would it be possible to use the following set-ups at the same time?
- Use P32/P32 for debug traces
- Use P0/P2 to interface with an MCU
I would like to be able to print debug messages while running an UART on P0/P2 with MCU.
2. Pull-up on P1
Also I believe P1 needs to be pulled up for the internal EEPROM's I2C. Are there any other pins that need to be pulled up?
3. Pull-down on HCI UART_RX
I believe that HCI UART_RX (Pin18) is pulled down internally. Do I need to pull down with an external resistor (10k)?
The WICED Sense kit shows the Pin18 is pulled down via 10k to the ground.
4. nCS on P26
Does SPI2 master control this pin at all (active low)?
Or it is used only for SPI2 slave?
5. Best way to communicated with MCU
- P-UART
- SPI
I believe SPI would provide a faster transfer.
P-UART may be easier to implement. However, we have an SPI working between 20737 and MCU. Does it still make sense to try to implement P-UART?
6. Schematic/layout review
Who can I contact for schematic/layout review in PM?
Thank you,
Andrew
Show LessThe application demonstrates A2DP Sink and HF profile usage, I found in the code that during playback the I2S clock is 1.411 MHz and during HF call the clock is 256 KHz, I would like to know how this switching is being done. Can anyone please help me here ?
Thank you,
Pravinkumar
Show LessWhen trying to build the hello_sensor-BCM920719EVAL_Q40 target I get the following error: "Failed to execute HCI Reset". D12 pulses once indicating the command was sent.
I followed the quickstart guide except for setting SW2 to position 3, as there does not seem to be a SW2.
I've attached a text log of the build output.
Show LessAre there any known code conversion problems in the WICED examples? All of the Example code is made for the old broadcom BCM92073(6/7) devices so I have to compile it to run on the CYBLE_013025_EVAL. When I look at the platform.h file for the different target types, the CYBLE model platform file does not have as many pins defined in it, and it doesn't show as having a write protect pin for NVRAM. I'm wondering if some of these differences cause any known misbehavior in the example code after non-defined defines are resolved.
Right now I am trying to get the ota_firmaware_upgrade and ota_secure_firmware_upgrade to work without success. I have also been trying to get some UART data back on those examples from the ble_trace data, but no uart data is coming through from them. I have also posted some other questions about this device here: Read Flash Memory from CYBLE-013025 Device
Cant get Cyble-013025 dev kit to run over the air firmware updates.
Show Less