Smart Bluetooth Forum Discussions

Hi,

I have an interrupt set up to fire on the falling edge, however when I trigger a level change on the pin, it fires for both the rising and the falling edge. any ideas what may be causing this? my pin set up is as below

//configure interrupt pin

    gpio_configurePin(GPIO_PORT(pin),GPIO_PIN(pin),

    GPIO_EN_INT_FALLING_EDGE,

    GPIO_PIN_OUTPUT_LOW);

UINT16 interrupt_handler_mask[3] = {0,0,0};

interrupt_handler_mask[0] = ((1 << GPIO_PIN(DIAL)));

gpio_registerForInterrupt(interrupt_handler_mask, measure_dose, NULL);

and all the interrupt does for now is just print a debug message to console.

As a follow on to the discussion here: Very long SPI Transfer on the BCM20737​

I also have this question, and would like to offer the beginning of a solution:

I'd like to make my own buffer of maybe 512 bytes, and a head + tail variable.

my spi_long_tx(); would then

calculate length=head-tail

transmit up to 14 bytes to the spi hardware,

increment tail by up to 14

and if length >14,

     set spiffy2_TxAELevel to 4 (or so)

     enable SPI interrupt (spiffy2_IntEnable) just for Tx Almost Empty

then the interrupt service routine for SPI would

-check if head > tail

send the next up to 10 bytes to spi hardware

increment tail accordingly

and if now head==tail, disable the almost empty interrupt.

what we now need from Broadcom is

a) full description of the SPI interrupt bits

b) a possibility to register an interrupt service routine for the SPI interrupts

That information is available for PUART, why not for SPI2?

while you're at it, please give us a list of what is critical for the Bluetooth stack, and what we should not be using at all,

and some documentation on the rest of the stuff.

That interrupt service routines should never be blocking and should complete within a few cycles, I think goes without saying, and whoever breaks the bluetooth stack with these methods only has himself to blame, not broadcom 😉

eg. can we use the systick timer? interrupt? or is it used (sometimes?) in the stack?

The BCM20737 really is awesome, and if only we had a little more documentation and access to its inner workings, it would really be an incredible chip to put into any IoT design!!

I tried the connection between my hello_client-application and a smartphone,

but there is a strange problem:

The application is sending ADV with the default name of the device.

But if the device is running, there are no more ADVs received by my phone.

It seems like the ADVs are only sent while the create-function is called.

After it, there are no more ADVs.

After that, I tried to set the ADV-Data like I did on other devices (no hello_clients)

like this:

     // Fill GATT-DB
     // Device name
     memset(db_name.pdu, 0x00, (size_t)HELLO_CLIENT_NAME_LENGTH_U8);
     (void)snprintf(macString, sizeof(macString) ,"%02X%02X%02X%02X%02X%02X", macAddr[5], macAddr[4], macAddr[3], macAddr[2], macAddr[1], macAddr[0]);
     (void)snprintf((char *)db_name.pdu, (size_t)HELLO_CLIENT_NAME_LENGTH_U8,"%s_%s", HELLO_CLIENT_DEVICE_NAME, macString);
     db_name.len = HELLO_CLIENT_NAME_LENGTH_U8;
     /*@-compdef@*/
     (void)bleprofile_WriteHandle(0x0016, &db_name);
     /*@=compdef@*/

     // advertise first vendor specific service
     if (sizeof(hello_client_uuid_main_service) == 16) {
          // total length should be less than 31 bytes
          BLE_ADV_FIELD adv[3];
          BLE_ADV_FIELD scr[1];

          /*@-usedef@*/
          // flags
          adv[0].len     = 1 + 1;
          adv[0].val     = ADV_FLAGS;
          adv[0].data[0] = (UINT8)(LE_LIMITED_DISCOVERABLE | BR_EDR_NOT_SUPPORTED);

          adv[1].len     = 16 + 1;
          adv[1].val     = ADV_SERVICE_UUID128_COMP;
          memcpy(adv[1].data, &hello_client_uuid_main_service[0], 16);

          // Tx power level
          adv[2].len     = TX_POWER_LEN+1;
          adv[2].val     = ADV_TX_POWER_LEVEL;
          adv[2].data[0] = bleprofile_p_cfg->tx_power_level;

          // name
          scr[0].len      = HELLO_CLIENT_NAME_LENGTH_U8 + 1;
          scr[0].val      = ADV_LOCAL_NAME_COMP;
          memcpy(scr[0].data, (char *)db_name.pdu, (size_t)(scr[0].len - 1));
          /*@=usedef@*/

          bleprofile_GenerateADVData(adv, 3);
          bleprofile_GenerateScanRspData(scr, 1);
     }

With that changes, ADV will be sent all the time, but there is no name visible.

WICED Smart Explerer is showning the MAC-Address and in the lower line "Device name not available"

nRF Master Control Panel is showing as name "n/a" and also the MAC-Address.

Also the device-name is still visible while starting. After the application is running, the name is lost.

My application is scanning and advertising at the same time, but even if i stop scanning, this won't change anything.

Is there something else called after the create-function?

Is there something else interferring to the ADV-Data?

I'm using the 920736S (the module)

with SDK 2.2.1 on Ubuntu.

There has been alot of inquiries recently related to our support of the new EN 300 328 1.8.1 regulatory changes in Europe: The Clock is Ticking! Are you ready for ETSI EN 300 328 v1.8.1?

Our current means of in house self-certification for this directive seems to be a concern for some of our partners, so I thought it would make sense to provide some of the details behind our decision.

Essentially, CE (RTTE) compliance for EN 300 328 v1.8.1 can be self-declared based on internal (what we provide) or external test data and there is no requirement to test using an outside test house. The RTTE directive Annex II explains this in detail and is included below. Additionally, Involvement of a Notified Body Opinion is not required either.

ANNEX II

CONFORMITY ASSESSMENT PROCEDURE REFERRED TO IN ARTICLE 10(3)

Module A (internal production control)

1. This module describes the procedure whereby the manufacturer or his authorised representative established within the Community, who carries out the obligations laid down in point 2, ensures and declares that the products concerned satisfy the requirements of this Directive that apply to them. The manufacturer or his authorised representative established within the Community must affix the CE marking to each product and draw up a written declaration of conformity.

2. The manufacturer must establish the technical documentation described in point 4 and he or his authorised representative established within the Community must keep it for a period ending at least 10 years after the last product has been manufactured at the disposal of the relevant national authorities of any Member State for inspection purposes.

3. Where neither the manufacturer nor his authorised representative is established within the Community, the obligation to keep the technical documentation available is the responsibility of the person who places the product on the Community market.

4. The technical documentation must enable the conformity of the product with the essential requirements to be assessed. It must cover the design, manufacture and operation of the product, in particular:

- a general description of the product,

- conceptual design and manufacturing drawings and schemes of components, sub-assemblies, circuits, etc.,

- descriptions and explanations necessary for the understanding of said drawings and schemes and the operation of the product,

- a list of the standards referred to in Article 5, applied in full or in part, and descriptions and explanations of the solutions adopted to meet the essential requirements of the Directive where such standards referred to in Article 5 have not been applied or do not exist,

- results of design calculations made, examinations carried out, etc.,

- test reports.

5. The manufacturer or his authorised representative must keep a copy of the declaration of conformity with the technical documentation.

6. The manufacturer must take all measures necessary in order that the manufacturing process ensures compliance of the manufactured products with the technical documentation referred to in point 2 and with the requirements of this Directive that apply to them.

We are also looking into what would be required to have this certification done at an outside test facility, but according to the directive and details provided above, this is not a requirement.