I started a project based on soc-empty. I added the SWO terminal code and the code to read the battery. This is a custom PCB - but no peripherials. So, it's a module, a couple of caps, and a debug connector.
Without starting advertisements, and just spinning on the gecko_wait event() after calling gecko_init(), the average current is around 9 uA. There is a spike happening about every 140 ms. When zoomed out, this spike looks to be about 10 uA, but when zoomed in it looks more like 75-100 uA. This happens without the RTCC enabled.
I understand the we should be in EM2 during the gecko_wait event(). So I think the question is what is happening every 140 ms?
Are you sure that the gecko_wait event is not returning at all during those spikes?
Most likely what you are seeing are the DC/DC refresh current spikes. What device did you select to generate the soc-empty where you are starting to build your project? You can generate a project for either a radio board or an individual OPN. This is done by selecting either a radio board or the underlying OPN when you expand the radio board.
The key difference is that selecting the radio board will add some more bits and pieces of code which may be undesired for a custom hw design. These would be things like:
If your starting point was the radio board then make sure that you remove these otherwise you can end up with floating pins or driving pieces of circuitry without you realizing it. Or then start from the OPN which will not add any of the radio board related code so it will be a much cleaner starting point.
I'm suspecting that you went with the radio board project and that could explain why your average is 9uA instead of something like 2-3uA which would be more expected.
Thanks for the response. I had created the project based on the radio board.
So I tried to bring up a project with only the BGM13P22 as a module only. A bare minimum skeleton is created, but it is too bare. No libraries, and the makefiles don't get created.
But I did look at what was created. The init_app.c and init_board.c are bare. So I went to the project that is building, and took everything out of those files, and no change. I also commented out the DC-DC initialization in init_mcu.c.
I had noticed before asking the first time that commenting out the SPI flash stuff did have an effect, but I can't get below 9 uA.
Edit: I need to wait til tomorrow for the schematic to see how the power pins are connected before experimenting with the power configuration.
No libraries, and the makefiles don't get created.
What do you mean no libraries? The Bluetooth library is linked against the project and the main.c is the same as for a soc-empty created for a radio board.
Commenting out the DC/DC configuration was probably not a good idea, I don't know what is the default configuration but it might not be a suitable on. I recommend that you look at this more closely at this and check your supply against what is recommended in the BGM13P datasheet. Also there is an application note on the DC/DC that you can refer to for additional information if needed.
You have to use the Commander and run 'commander device recover'. The commander can be found in C:\SiliconLabs\SimplicityStudio\v4\developer\adapter_packs\commander
Back to status normal. When I have advertising xmitting at 2 second intervals, seeing about 20 uA average. With no advertising, current is averaging about 9 uA. So the goal is to minimize this idle current. Jacking with the DC-DC, I bricked a module beyond repair (thanks for the help, BTW, but commander recover did not work). So, assuming no more bricking like that, what do you recommend as the next step. I have included the init files and a screen shot.
I'm still in the learning phase with the energy profiler (the whole thing, really). Why are the percentages shown in the profiler adding up to only about 40%. Thanks!
Why are the percentages shown in the profiler adding up to only about 40%.
I'm not 100% sure (I'll check with the studio team) but my guess is that the difference is from the sleep mode (EM2). As there is no code executing it won't show on that list.
Just for clarity sake could you create a soc-empty or iBeacon for the OPN as I suggested earlier? That would really ensure that there is nothing being messed up with hardware initialization (SPI Flash on the radio board, PTI). Don't add anything to it, just flash to your board as-is. If the profiler still shows high sleep current then please attach your schematics here and also a diagram of how you are connecting the WSTK to your board to measure the current. I'm assuming you have removed the radio board from the WSTK correct?
I ran updates for Simplicity Studio earlier today.
Project created on the OPN (BMG13P22F512GA) does not build.
Create soc-ibeacon on the BMG13P22 Bluetooth Module Radio Board (BRD4306A Rev A01)
Comment out the MX25_init() and other lines in init_board.c. That makes a big difference.
Comment out configEnablePti(). Does not change draw.
Comment out bcnSetupAdvBeaconing() in main().
This results in the same idle current I was seeing.
The board is connected to the Cortex connector on the debug adapter of the WSTK.
When running this code on the radio board, I'm seeing 12 uA.
I have a similar issue with Thunderboard Sense where with all application level timers disabled, I get 100uA of current draw every about 33ms. Was there ever a resolution to this issue?