Smart Bluetooth Forum Discussions
Anyone know why my application (based off of hello_sensor) corrupts serial flash? I download and run my app to the dev board over USB. USB is also my source of power.
After running my app, I remove power and when I attempt to download again I get the following:
Detecting device...
********* Detection Failure *************
+------------------------------------------------------------------------------------------+
| The BCM20706 was not detected. Verify that the device is connected, power-cycle if |
| necessary, and retry. |
| Please see Appendix sections in the Quick Start Guide for common com port problems. |
+------------------------------------------------------------------------------------------+
When I re-plug my board into USB, I must press and hold SW3 then press SW1 before I can download again.
I know its my app because this does not happen when I run hello_sensor but I have know idea what I'm doing to cause this as I am not writing to NVRAM.
Thanks,
Dave
Show LessFrom the MBT command I can control BCM20737S transmit data and Receive data, MBT LE_Receiver can sum all received data packets but I don't know how many data packets another BCM20737S have sent out, does anyone know how to test PER of BCM20737S or how to calculate datapackets when BCM20737S get into LE_Transmitter mode ?
Show LessHi,
in this document: BCM20736S Sleep Example Firmware is a tool to measure the power consumemation. How can i get this tool? It is available in the SDK? How it works? I want to optimize my code for the BCM20736S.
kind regards,
martin
Show LessHi,
I am facing an issue that my system reset occur when I receive the data on UART (85 byte stream). I'm using as describe:
1- In UART receive Interrupt function bytes are taken from FIFO
2- Parser is looking for specific Bytes from interface module
3- on receiving right data it is push in array of 85
4- when array gets full variable is set for transmission over notification API
5-watch dog is reset on receiving every byte
Please let me know what is going wrong in my system and how to fix it. my code is as below:
Have a nice day!
Kind Regards,
Ghalib
Code is as below: ws_upgrade_uart.c
extern UINT8 hrm_char1;
static UINT8 num_bytes_received = 0;
extern UINT8 over_above;
extern UINT8 buffer[10];
extern UINT8 noti_tx;
extern UINT8 hrm_chk[100];
void ws_upgrade_uart_interrupt_callback(void* unused)
{
char readbyte;
int send_status = FALSE;
// empty the FIFO
while(puart_rxFifoNotEmpty() && puart_read(&readbyte))
{
buffer[num_bytes_received ]=readbyte;
if (buffer[num_bytes_received] > 0xf7)// FD=247
{
if (buffer[num_bytes_received] == 0xf8 ) //wave block
{
inc_dec++;
}
else if (buffer[num_bytes_received] == 0xfe)
{
//do nothing
}
else if ((buffer[num_bytes_received] == 0xf9) || (buffer[num_bytes_received] == 0xfa)) //value block
{
//do nothing
}
else if (buffer[num_bytes_received] == 0xfc) //status block (transmitted once per second)
{
}
else if (buffer[num_bytes_received] == 0xff)
{
//Status = buf;
}
}
if (inc_dec == 2 && buffer[num_bytes_received - 3] == 0xf8)
{
inc_dec--;
hrm_char1=buffer[num_bytes_received - 1];
num_bytes_received = 0;
if (noti_tx == 0 )
hrm_chk[over_above++]=hrm_char1;
if (over_above == 32)
{
noti_tx++;
over_above=0;
}
}
else if(num_bytes_received>7)
{
inc_dec=0;
num_bytes_received = 0;
}
// Received all - do something with it.
num_bytes_received++;
wdog_restart();
}// while ends
// clear the interrupt
P_UART_INT_CLEAR(P_UART_ISR_RX_AFF_MASK);
// enable UART interrupt in the Main Interrupt Controller and RX Almost Full in the UART Interrupt Controller
P_UART_INT_ENABLE |= P_UART_ISR_RX_AFF_MASK;
if (send_status)
{
ws_upgrade_uart_send_status(WS_UPGRADE_EVENT_OK);
}
// make sure that watch dog is ok
}
code heart_rate_monitor.c
UINT8 hrm_chk[35];
UINT8 hrm_char1;
UINT8 buffer[10];
UINT8 over_above;
UINT8 noti_tx=0;
void heart_rate_monitor_FineTimeout(UINT32 count)
{
if (config_var == 0)
{
ECG_config();
config_var++;
}
if (noti_tx == 1)
{
bleprofile_sendNotification(hrmAppState->blehrm_hrm_hdl, hrm_chk, (sizeof(hrm_chk)));
noti_tx = 0;
}
}
Show LessHi Sir,
There are "mia_isResetReasonPor" to get wake up reason for PoR or deep sleep,
additionally, is there any way to get the reset reason for PoR or WatchDog ?
Show Less
Other than using the WICED Studio, how can we create a own programmer for this device? What are all the interface can be used? Any protocol level details on how the boot code is sent? Any examples?
Show LessHello everyone,
I am trying to interface the AD8232 Heart Rate Monitor with CYW920737 TAG-04 to implement a simple cardiac monitor.
The pins of AD8232 are: (1) output that can be connected to P0 (analog input of CYW20737 TAG-04), (2) GND, (3) 3.3 V, (4) LO-, (5) LO+. 4 and 5 are leads off detection that can be connected to digital GPIO pins.
My question (A): after reading WICED Smart Tag hardware user manual & CYW20737 SoC datasheet, a) when the circuit is powered on USB cable mode not battery, I did not find the a ground pin for (2) and output voltage pin for (3), any ideas on how to hoop these pins up to CYW20737?
Second question: which pins are suitable for digital Inputs to be hooked up to LO- and LO+? like P3 and P4 would work?
Then, I can define two digital input pins:
#define GPIO_PIN_P0 0 // analog input of the heart monitor
#define GPIO_PIN_P3 3 //digital input from LO-, should be set LOW (enabled)
#define GPIO_PIN_P4 4 //digital input from LO+, should be set LOW (enabled)
// define the settings for digital inputs and configure them
#define GPIO_SETTING GPIO_INPUT_LOW | GPIO_INPUT_HIGH
gpio_configurePin(GPIO_PIN/8, GPIO_PIN_P3, GPIO_EN_INT_LEVEL_HIGH | GPIO_PULL_DOWN | GPIO_INPUT_ENABLE, GPIO_PIN_OUTPUT_LOW);
gpio_configurePin(GPIO_PIN/8, GPIO_PIN_P4, GPIO_EN_INT_LEVEL_HIGH | GPIO_PULL_DOWN | GPIO_INPUT_ENABLE, GPIO_PIN_OUTPUT_LOW);
//set up an interrupt (rising) if GPIO_PIN_P3 or GPIO_PIN_P4 is HIGH, send interrupt
gpio_configurePin(GPIO_PIN/8, GPIO_PIN_P3, GPIO_EN_INT_RISING_EDGE, GPIO_PIN_OUTPUT_LOW);
gpio_configurePin(GPIO_PIN/8, GPIO_PIN_P4, GPIO_EN_INT_RISING_EDGE, GPIO_PIN_OUTPUT_LOW);
Also, (C) to get 3.3 output voltage to be able to power the AD8232. Do I need to change the tiny resistors RFB1 to = 470K ohm and RF2 to= 150Kohm , C2 = 100 pF as suggested in the Hardware User Manual?
Then, I can use Heart Rate Monitor App example on WICED Smart IDE : first by including:
#include "adc.h" // added to enable converting analog Input to digital
#include "gpiodriver.h" // added to enable using P0 and P1 pins
and adding some commands to handle ADC conversions: before the line: blehrm_connDown();
Also, inside the function: heart_rate_monitor_create(void), we add:
// configuring the ADC converter
adc_config();
and set the sampling frequency and reference voltage for ECG signal by adding the following commands:
// Setting the sampling frequency to be 11.7 KHz
ADC_SAMPLE_FREQUENCY sample_frequency = ADC_SAMPLE_FREQUENCY_MEDIUM_LOW; // instantiate an onject.
adc_setAdcSampleFrequency(sample_frequency); // setting the sampling freq
UINT32 refVoltageInMicroVolts = 10; // setting the reference voltage for the ECG
ADC_INPUT_CHANNEL_SEL referenceInput = GPIO_PIN_P0; // selecting the input channel
adc_adcCalibrate(refVoltageInMicroVolts, referenceInput);
ADC_INPUT_RANGE_SEL input_range = ADC_RANGE_0_3P6V;
Also, in the main program, I need to read the ADC voltage by calling:
UNIT32 ADC_reading = application_read_adc_voltage()
and Reads the voltage from any ADC channel from Po of the GPIO:
application_read_Adc_voltage_from_gpio(UINT32 GPIO_PIN_P0)
Does this seem right?
Your advice is highly appreciated.
Show LessHello,
I used the instructions in the "WICED-Secure-Over-the-Air-Firmware-Upgrade.pdf" document and the example code from "ota_secure_firmware_upgrade" to add secure over the air firmware upgrade to my project. I believe I've followed all the required steps and added all the required code and hooks to my project. However, when I attempt to do a firmware upgrade using the WsSecOtaUpgrade.exe application, I see the progress bar get nearly to the end, only to fail with a "Verification Failed" error.
I'm not really too sure where to look to solve this one. Any guidance you can provide would be greatly appreciated.
Thanks,
Chris Ingraham
Show LessHi,
I am finding some weird issues with the Advertisement on the 20737 chip.
Using hello_sensor and a TI RF sniffer I can see the adv packets being transmitted, however sometimes if I reset or power cycle the sensor I only seem to get adv packets for around 5 - 10 seconds and then the RF stops......packet sniffer does not see any RF data.
When the module does work I have left it to run without access to a client to see what would happen. What I have noticed is that the HIGH ADV stops and then the LOW ADV starts and runs as expected (300 seconds). The ADV Interrupt Stopped interrupt handler is then called and the module is instructed to start advertising LOW....sometimes it continues to advertise for 5 - 10 seconds and other times the advertisement does not start at all. The application does not appear to have crashed as the background messages continue to be transmitted on the uart.
This appeared as I have tried to control when advertisements are started, stopped, etc...using commands through the puart.
When I spotted this problem I reverted back to the default hello_sensor and noticed exactly the same problem.
So my question, has anyone else seen this problem, is it a problem, and does anyone have a solution.
p.s. I did see a thread where the sleep_enable = 0 and setting the crystal time to 5000.....I tried that and it actually made things worse.
I am using SDK 2.1.1
Thanks
Lloyd
Show Lesswrote that 12 of the 20 BCM20737S based boards we received, 2 exhibited a failure that appears to be similar to Advertisement seems to be flakey .
With a simple piece of example code the fault typically appears after 10s to 60s of sending Advertisements.
There are a number of issues we have with the problem:
- There are cases where we are unable to detect it when running the test, but the device does fail if we test it more often, so this seems to be a soft issue to some degree which makes testing difficult.
- There are too many unusable devices in our admittedly small sample.
- Going to deep sleep resolves the problem, but we need to send advertisements for a long time >30s which makes this an unusable strategy. Not to mention the fact that the chip is unreliable.
So we need at least a better testing method, and at best some mitigation strategy.