AVR Freaks

Grounding AO GPIO pins and not using a terminal connected to the virtual port made by Xplained port helped redusing the current consumption a lot. Now I'm getting about 2.6 uA sleep and 20 uA average running iBEACON example as is. Analysing the power with and oscilloscope reveals that each advertising cycle takes about 16 uAs thus power consumption is now 2.6 uA + 16/adv_int. Seems to be about the same connected and also timer wakeups take the same 16 uAs despite not having any TX/RX. A bit lower current during, but a bit longer time.

So now I have the sleep current close to the datasheet ERRATA value of 2 uA. But not the average one! BlueSDK 5.2 Release notes show iBeacon measurement of 14.7 uA average and datasheet about 13 uA. If I put my multimeter in 200 uA range, I can get similar 14+ uA figures with iBeacon. But then the voltage drop is so big, that trying to connect fails likely due to current jump. Even worse the device can jam into boot taking 3 mA all the time. All this is fixed going to 2 mA range (1 kohm -> 100 ohm), but then the average current is about 20 uA (occasionally 18+ uA).

Why does increasing resitance to power line decrease consumption so clearly? According to data sheet higher voltage yields smaller current due to switching regulator at VBAT, which takes most of the current. Or is it just fake by e.g. drawing current from peripherals etc. during voltage drops at peak currents? But there is a small effect also during sleep and then the voltage drop is minimal.

The code is just the iBEACON example. All I have done is to modify the connection and advertising interval.

In case CONNECTED (sorry can't get the code insertion to work):

                PRINT_H3("Conn.Interval: 0x%04X %dms\r\n", conn_params->conn_params.con_interval, (int)(conn_params->conn_params.con_interval*1.25));
                PRINT_H3("Conn. Latency: 0x%04X\r\n", conn_params->conn_params.con_latency);
                PRINT_H3("Supr. Timeout: 0x%04X\r\n", conn_params->conn_params.sup_to);

                at_ble_connection_params_t *connection_params = (at_ble_connection_params_t *)((void *)&params[50]);
                connection_params->con_intv_min=(int) (105/1.25); //1.25 ms each, min 20 ms for IOS
                connection_params->con_intv_max=(int) (125/1.25); //1.25 ms each, >min+20 ms and <2 s for IOS
                connection_params->con_latency=7; // The number of intervals we can skip
                connection_params->superv_to=5000/10; //10 ms each, 6 s max for IOS
                connection_params->ce_len_min=0;
                connection_params->ce_len_max=0;
                status = at_ble_connection_param_update(conn_params->handle, connection_params);
                PRINT_H3("Sending connection param update. Status : %d\r\n", status);

And under DISCONNECTED

                adv_int/=2; //1600 at first = 1 s
                if(adv_int < AT_BLE_ADV_INTERVAL_MIN)
                    adv_int = AT_BLE_ADV_INTERVAL_MAX;
                PRINT_H2("Start Advertising again at %dms\r\n", (int)(adv_int*0.625));
                adv_data[25] = adv_int*0.00625;
                adv_data[6] = 10;
                adv_data[7] = 20;
                status = at_ble_adv_data_set((uint8_t *)adv_data, 27, (uint8_t *)scan_rsp_data, 18);
                PRINT_H3("Status : %d\r\n", status);
                status = at_ble_adv_start(AT_BLE_ADV_TYPE_UNDIRECTED, AT_BLE_ADV_GEN_DISCOVERABLE, NULL, AT_BLE_ADV_FP_ANY, adv_int, 0, 0);

I'm still very confused about the current measuring. Now I'm testing with the LED on board. Turning it on increases current 30 uA in "MCU" and 3 mA in "peripheral" according to Data Analyzer. So is SAMB11 consuming 33 uA instead of 3 uA because it's sinking 3 mA through LP-GPIO? Or is the LED even directly connected to the pin toggled by LED_On/Off? Seems to need led_init in every resume in order to keep the LED on during ULP. For a while I was wondering how bgright the LED is with just 30 uA!

I'm also trying to get my own application to run with iBEACON, but have troubles with events/interrupts. I would like to do my own stuff at the same time the system resumes anyway in order to do the BLE RX/TX. I thought I had it working, but run into the same problem as you: no BLE output. The power consumptions looks just the same as it was transmitting, but nothing is seen on my phone.

I used the button callback on SW0 to create one event. It doesn't wake up from ULP, but activates when the system wakes up due to BLE interval. I also tried to setup a timeout for the at_ble_event_get. That works fine, but each timeout takes as much current as RX/TX cycle. So If I want to modify data and send it at 250 ms latency I have to wake up 8 Hz from ULP which takes 140 uA instead of just waking up each 250 ms with 70 uA.

Actually you can tell from the current peak, if it is transmitting or not. A slight difference in shape and height, but average current drawn is just the same. Setting latency higher than 0 in the connection shows that doing my callback + event from there makes the system use two time slots in a row. The first one is used for my event (nothing sent) and the second one is a real TX.