Reply
Posts: 238
Registered: ‎10-03-2015

Migrating to 2.3.0

I was trying to migrate to the 2.3.0 stack and GCC toolchain from 2.0.3. I started with the SOC Empty project as a template then moved my project over. The app compiled ok, but calls to the stack caused the module to reset immediately. For example, if I called:

 

gecko_cmd_le_gap_set_mode(le_gap_general_discoverable, le_gap_undirected_connectable)

 

Next I simply tried the "Empty" project as-is and that too had the same issue. Finally, I tried the iBeacon example and that DID work oddly enough. I could not see what was different about the Empty project that would cause this. 

 

 

One other thing I noticed is that the bin size for my app went from 177k to 236k? Seems like a big jump no? Did the stack grow considerably?

Posts: 2,597
Registered: ‎09-01-2015

Re: Migrating to 2.3.0

>>my app went from 177k to 236k?

 

The stack has grown but not that much. I just checked that the size of the *.bin file for thermometer example built with GCC is about 158 kB. 

 

What is the target HW in your tests?

Posts: 238
Registered: ‎10-03-2015

Re: Migrating to 2.3.0

BGM121

Posts: 238
Registered: ‎10-03-2015

Re: Migrating to 2.3.0

After I migrated using the iBeacon example as a template I have the same issue. What I stated above is still accurate however in that the Empty project does not work "out of box" and the iBeacon does. However as soon as I move my code over to the iBeacon example I get the reset issue when calling stack functions. Gotta be something simple.

 

 

Posts: 238
Registered: ‎10-03-2015

Re: Migrating to 2.3.0

 

Having a number of issues. Let me just list them and perhaps there is a common thread to some of them...

 

1. Module resetting when starting advertising.

 

There are other circumstances that the module resets when advertising starts, but one case where I can reliably reproduce the issue is if I initialize I2C and then try to advertise. This causes the module to reset 100% of the time. Strange right? I tried a BGM111 module with the same code and no issues. Bad PCB4302A board?

 

2. GPIO Interrupts not working.

 

Any simple GPIO interrupt will not fire. Outputs do work. Same goes for the BGM111. Incidentally, any 2.1 or later stack has the same issue for me. 2.0.3 is fine.

 

3. Build size is much larger. +58K

 

I have not investigated this much, but there appears to be a standard folder added to the project "bgapi" and I would expect some of the added size comes from this. Why is this folder now added to projects?

 

4. Compiling does not automatically re-generate the gatt source files.

 

You have to manually run "Generate" from the project GUI (or whatever that *.isc" file is). I am not a fan of these GUI's and prefer to the edit the XML directly, but default projects will not create the gatt_db files when compiled. Also, I do not get the "constants" file that we used to get that lists characteristics and their offset value in the database. Do I have to manually setup a builder to use bgbuild? 

 

 

At this point I feel like just sticking with 2.0.3 because it seems to work really well and I don't have a lot of time to try sort through this right now. However, I was looking forward to 2.3.0 primarily for the OTA functionality. Using GCC, Can I create OTA files for 2.0.3? I ran the scripts included with 2.3.0 and I do get EBL files, but I also get the following error:

 

ERROR: No application properties found in the application image.

 

 

Posts: 2,597
Registered: ‎09-01-2015

Re: Migrating to 2.3.0

[ Edited ]

Hi @superpanda,

 

thanks for the feedback, we will try to answer all questions one by one.

 

To get started:

 

1. Module resetting when starting advertising.

 

We have identified that there's something wrong with the DCDC configurations and this is specific to the 2.3.0 SDK that was just released. As far as I know this issue is purely firmware issue and it does not exist in the previous SDKs. 

 

We are working on a patch and hopefully that can be released soon. In the meanwhile, one easy workaround to this issue is to decrease TX power level. By default, the TX power is set to maximum (for example, +8dBm with BGM111 or +3 dBm with BGM113). Try lowering the transmit power with command cmd_system_set_tx_power before starting any advertising or scanning.

 

2. GPIO Interrupts not working.

 

I assume you are trying to use interrupts via BGAPI? Have you tested configuring the GPIO and interrupts directly via emlib? This is the recommended way. In fact, many of the hardware-related BGAPI commands have been marked as deprecated and these will be removed in the next major release.

 

Posts: 238
Registered: ‎10-03-2015

Re: Migrating to 2.3.0

Noted on the TX power. I'll try that.

 

In fact I am using emlib for the interrupts. Works in 2.0.3 or earlier. Will not work with 2.1 or later. Segment of code below.

 

GPIO_PinModeSet(PULSE_PORT, PULSE_PIN, gpioModeInput, true);	
GPIO_ExtIntConfig(PULSE_PORT, PULSE_PIN, 0, false, true, true); NVIC_EnableIRQ(GPIO_EVEN_IRQn); NVIC_EnableIRQ(GPIO_ODD_IRQn); void GPIO_ODD_IRQHandler(void) { // Common GPIO interrupt handler gpioIrqHandler(); } void GPIO_EVEN_IRQHandler(void) { // Common GPIO interrupt handler gpioIrqHandler(); }
Posts: 2,597
Registered: ‎09-01-2015

Re: Migrating to 2.3.0

@superpanda I tested interrupts with a project built with GCC. I used very similar code as yours, a simple interrupt handler that toggles a LED when button is pressed.

 

The code works fine but I noticed that if I set a breakpoint in the gpioIrqHandler() the code execution does not stop there. This could be some issue related to GCC and breakpoints in interrupt context. I tried setting a breakpoint in the main loop and that works fine.

 

 

Posts: 238
Registered: ‎10-03-2015

Re: Migrating to 2.3.0

I don't know know what to say. Same code works in one stack and not the other. Makes no sense.
Posts: 2,597
Registered: ‎09-01-2015

Re: Migrating to 2.3.0

Problem solved! I changed optimization level to "none" and now the breakpoint set in my interrupt handler works fine.

Posts: 2,597
Registered: ‎09-01-2015

Re: Migrating to 2.3.0


superpanda wrote:

  

4. Compiling does not automatically re-generate the gatt source files.

 

You have to manually run "Generate" from the project GUI (or whatever that *.isc" file is). I am not a fan of these GUI's and prefer to the edit the XML directly, but default projects will not create the gatt_db files when compiled. Also, I do not get the "constants" file that we used to get that lists characteristics and their offset value in the database. Do I have to manually setup a builder to use bgbuild? 

  


Here's one trick you can try to bypass the GUI:

 

Create some dummy BGScript project where you define your GATT using the XML syntax. You can use one of the BGSCript examples as template, they are found in:

 

C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v1.0\app\bluetooth_2.3\examples_bgscript\

 

Edit the GATT XML so that the <gatt> tag is defined as follows:

<gatt header="gatt_db.h" out="gatt_db.c" prefix="gattdb_">

Now you can build the project with BGTool. You will see gatt_db.c / h generated in the project directory. Copy these files into your C project folder and continue working there.

 

If you check the content of gatt_db.h you will notice it includes same information as the constants file.

 

This is kind of a "hack" but the GATT XML is something that you don't need to change that often, so maybe it's worth the trouble. 

 

There could be some easier ways to do this but this is the first suggestion I have for now.

 

Highlighted
Posts: 5
Registered: ‎10-08-2015

Re: Migrating to 2.3.0

We ran into the same issue with the module resetting when starting to advertise.

Reducing TX power worked to prevent this reset as a temporary fix. Thanks. 

~Ryan

Posts: 15
Registered: ‎03-15-2017

Re: Migrating to 2.3.0

I'm also having the same issue. SOC-empty compiles but resets when run. iBeacon runs OK.

 

I've tried using the command cmd_system_set_tx_power although not successfully. I'm new to C, Simplicity Studio and the Silicon Labs micros so I'm sure either my syntax is wrong or I've loaded it in the wrong part of the program - the manual states that "This command should not be used while advertising, scanning or during connection" (The manual would be much more user friendly if it included examples!).

 

Would someone mind explaining the exact code to add and where to add it?

 

As a side note I've also tried installing Simplicity Studio to my MacBook Air using the 'Mac Installer' without success. I downloaded it a number of times to ensure the file wasn't corrupted. I get the error message below. Is the MacBook Air not supported?

 

MacBook Screen Shot 280317.png

 

 

Posts: 15
Registered: ‎03-15-2017

Re: Migrating to 2.3.0

Further to this, I've found that the iBeacon demo has the statement...

 

 

/* Set 0 dBm Transmit Power */
gecko_cmd_system_set_tx_power(0);

...in the main.c file just before the 'main' function, however if I copy this line (or series of lines) into the main.c file at roughly the same place, I get the error:

expected declaration specifiers or '...' before numeric constant	main.c	/soc-empty	line 97	C/C++ Problem

How do I go about setting the transmit power low?

 

Anyone?

 

 

Posts: 2,597
Registered: ‎09-01-2015

Re: Migrating to 2.3.0

@Bill_D can you upload the whole source file that does not build (main.c) ?

 

Based on the error it seems just some missing or duplicate opening bracket or similar.

 

In "Sco empty" example (or basically any other example), you can add the call to system_set_tx_power just below this line:

 

 

 case gecko_evt_system_boot_id:
gecko_cmd_system_set_tx_power(0); // added

 

 

Posts: 2,597
Registered: ‎09-01-2015

Re: Migrating to 2.3.0

@Bill_D regarding your installation problem with Mac: the installer file name looks odd to me. I just checked from our website (link below) that the installer name is SimplicityStudio-v4.dmg and not installstudio-v4.dmg.

 

http://www.silabs.com/products/development-tools/software/simplicity-studio

 

Perhaps you have downloaded the wrong file?

Posts: 15
Registered: ‎03-15-2017

Re: Migrating to 2.3.0

I moved the transmit power instruction to where you suggested (without changing it at all!) and the project compiles. Previously I was inserting it before the 'main' function. A number of places were tried. Simply moving it prevented the error!

 

Do you know what maximum power level can be set before the problem reoccurs? No problem if you don't as I can experiment here. It's a relief that the example project can now compile - it's hard enough to learn everything from scratch without having inbuilt errors to contend with!

 

I managed to install Simplicity Studio yesterday. I thought I'd retry one of the files I downloaded a couple of weeks ago and it worked. Originally I tried many times without success and downloaded the installation file 4 or 5 times. I even rebooted the laptop to see if that was the problem. The only thing I can think of that may have made the difference is that I updated macOS last week to 10.12.4. Once it recognised the file, the installation went smoothly.

 

Thanks very much for your help!

 

Posts: 155
Registered: ‎01-06-2013

Re: Migrating to 2.3.0

Hi!

Can you keep us updated - did you solve the reboot issue? When should we expect update with this fix?

 

PS: Just tested GPIO interrupts on 2.3.0+GCC - works fine

Posts: 2,597
Registered: ‎09-01-2015

Re: Migrating to 2.3.0

 


Bill_D wrote:

I moved the transmit power instruction to where you suggested (without changing it at all!) and the project compiles. Previously I was inserting it before the 'main' function. A number of places were tried. Simply moving it prevented the error!

 

 


Well this is C basics. The code you want to have executed needs to be inside some function. If you placed the code before main() function then I'm not surprised it failed to compile. Good to hear it works now!

 


 

Do you know what maximum power level can be set before the problem reoccurs? No problem if you don't as I can experiment here. It's a relief that the example project can now compile - it's hard enough to learn everything from scratch without having inbuilt errors to contend with!

  


There is no definite power level, it depends on what radio board you are working with and may vary even between units. For now, I suggest you try using power levels between 0..3 dBm. 

 

And to answer the question by @Alatar, the reason for the reboot issue has been identified and fixed internally, it is going to be solved in the next patch release that is coming soon.

Posts: 15
Registered: ‎03-15-2017

Re: Migrating to 2.3.0

Setting the transmit power level may need to be inside of a function, however I placed it where I did because that is approximately where it was located in the iBeacon example which does work (segment of code attached). It is placed well before the main function. Not sure what the difference is with the soc-empty project.

 

As for C basics, in addition to starting with Simplicity Studio, this is also my first C program. I'm learning the two together, so please forgive my ignorance of the basics.

 

  /* Set 0 dBm Transmit Power */
  gecko_cmd_system_set_tx_power(0);
  
  /* Set custom advertising data */
  gecko_cmd_le_gap_set_adv_data(0, len, pData);

  /* Set advertising parameters. 100ms advertisement interval. All channels used.
   * The first two parameters are minimum and maximum advertising interval, both in
   * units of (milliseconds * 1.6). The third parameter '7' sets advertising on all channels. */
  gecko_cmd_le_gap_set_adv_parameters(160,160,7);

  /* Start advertising in user mode and enable connections */
  gecko_cmd_le_gap_set_mode(le_gap_user_data, le_gap_non_connectable);

}

/**
 * @brief  Main function
 */
void main(void)
{
Posts: 2,597
Registered: ‎09-01-2015

Re: Migrating to 2.3.0

OK, in the iBeacon example you put the command inside the function bcnSetupAdvBeaconing() that is called at startup. It is called from the main() function.

 

This is the relevant part from iBeacon example, main.c :

    case gecko_evt_system_boot_id:
// you can add the set_tx_power command here... /* Initialize iBeacon ADV data */ bcnSetupAdvBeaconing(); // <= or alternatively the command can be put inside this one break;

 

 

Posts: 15
Registered: ‎03-15-2017

Re: Migrating to 2.3.0

Thanks for the heads up

Posts: 23
Registered: ‎12-12-2016

Re: Migrating to 2.3.0

I'm having a similar problem with GPIO interrupts. I'm using the callback function and used the example code. Here's how I have it set up:

/* Pin PF2 is configured to input with pull-up and filter */
GPIO_PinModeSet(gpioPortF, _BOOST_SW, gpioModeInputPullFilter, 1);
GPIO_ExtIntConfig(gpioPortF, _BOOST_SW, 0, true, true, true);
GPIOINT_CallbackRegister(_BOOST_SW, handle_button_change);

/* Pin PF3 is configured to input with pull-up and filter */
GPIO_PinModeSet(gpioPortF, _POWER_SW, gpioModeInputPullFilter, 1);
GPIO_ExtIntConfig(gpioPortF, _POWER_SW, 1, true, true, true);
GPIOINT_CallbackRegister(_POWER_SW, handle_button_change);

 

I can see that the function GPIOINT_IRQDispatcher is called whenever I press a key, but the function handle_button_change is never called. When I look at the pgioCallbacks array, I see the address of the function but the function callback(irqIdx) never gets implemented. I'm using the latest GCC compiler and created the project using soc-empty.

Posts: 2,597
Registered: ‎09-01-2015

Re: Migrating to 2.3.0

hi @inndessol,

 

I think the problem is here: (third line)

 

/* Pin PF2 is configured to input with pull-up and filter */
GPIO_PinModeSet(gpioPortF, _BOOST_SW, gpioModeInputPullFilter, 1);
GPIO_ExtIntConfig(gpioPortF, _BOOST_SW, 0, true, true, true);
GPIOINT_CallbackRegister(_BOOST_SW, handle_button_change);

 

You have configured PF2 as interrupt number 0 which is OK. But when calling GPIOINT_CallbackRegister the first parameter i s_BOOST_SW which is #defined to 2, right?

 

try changing the last line to:

GPIOINT_CallbackRegister(0, handle_button_change);

 

And same applies to the other interrupt. Please let me know if this helps to fix the issue.