- Wed Aug 12, 2020 12:41 pm
#218006
Hello - I am attempting to build the ble_freertos_tag example application for the SparkFun Edge board. I've gotten everything to compile and link and can load to the board. It appears functional at first (although BLE connection seems a little flaky to an iPhone-based BLE connection app) ...
However, I've found at least one code error in this example project in both the Ambiq SDK 2.2.0/2.4.2 maintained version under apollo3_evb, as well as in the SparkFun maintained git repo (https://github.com/sparkfun/SparkFun_Ap ... Suite_BSPs) for the same example project (under .../common/examples), which SparkFun has fixed in their version (documented in closed issue #32: https://github.com/sparkfun/SparkFun_Ap ... /issues/32).
Basically, for the Apollo3 clock rate was erroneously assumed to be 24 MHz (like the older Apollo MCU), instead of 48 MHz (like Apollo2). The error stems from a conditional preprocessor directive testing whether AM_PART_APOLLO2 was set. SparkFun made an adequate change to fix this in the repo & I have the fix here too.
However, in going through the code for this same ble_freertos_tag example project ... I began to notice several other places where there is conditional code compilation using the same AM_PART_APOLLO2 definition check, with no other "#else' or '#elif' directives checking against the AM_PART_APOLLO3 definition which I am using & I'm wondering if the example projects have not been fully updated to reflect processor differences to the Apollo3 MCU. My concern is that the example won't be fully functional (or perhaps have spotty performance due to things like timeouts being incorrectly based on the wrong clock frequency).
Ultimately, I'd like to just fully understand the code as I attempt to make changes for my own purpose, or before trying to use it as an example to build a custom BLE profile ... so I want to make sure the code for my starting point is accurate
I'm new to both BLE and the Ambiq MCUs so this is a learning moment. I'm mostly interested in the Apollo3 (since this is what I have) and was hoping to minimize learning much about the Apollo2 and differences to the Apollo3 in order to do this.
Specifically, another place where there is a check for AM_PART_APOLLO2 but not AM_PART_APOLLO3 which looks conspicuous: in main(), inside the ble_freertos_tag.c example source code file:
There are at least a few other places with similar discrepancies in the ble_freertos_tag example, and I'm sure in other example projects as well.
So ... I guess my questions are (hopefully from SF, Ambiq or other experienced SW folks monitoring this forum): Are there other updates to the example projects that accurately reflect code mods to better support Apollo3 parts? Will these differences create other unforeseen problems functionally (aside for perhaps higher than expected power consumption)? Has anyone else noticed similar issues and already gone through the code and figured out what changes, if any, are needed to work correctly in Apollo3 parts (like the Edge board)? Instead of posting/asking about each one directly in the repo, I figured I throw up the question to the whole forum community here.
Thank you for any help or other guidance about these issues. I really like this board & am hoping to use it for a couple of cool personal projects!
- Keith
However, I've found at least one code error in this example project in both the Ambiq SDK 2.2.0/2.4.2 maintained version under apollo3_evb, as well as in the SparkFun maintained git repo (https://github.com/sparkfun/SparkFun_Ap ... Suite_BSPs) for the same example project (under .../common/examples), which SparkFun has fixed in their version (documented in closed issue #32: https://github.com/sparkfun/SparkFun_Ap ... /issues/32).
Basically, for the Apollo3 clock rate was erroneously assumed to be 24 MHz (like the older Apollo MCU), instead of 48 MHz (like Apollo2). The error stems from a conditional preprocessor directive testing whether AM_PART_APOLLO2 was set. SparkFun made an adequate change to fix this in the repo & I have the fix here too.
However, in going through the code for this same ble_freertos_tag example project ... I began to notice several other places where there is conditional code compilation using the same AM_PART_APOLLO2 definition check, with no other "#else' or '#elif' directives checking against the AM_PART_APOLLO3 definition which I am using & I'm wondering if the example projects have not been fully updated to reflect processor differences to the Apollo3 MCU. My concern is that the example won't be fully functional (or perhaps have spotty performance due to things like timeouts being incorrectly based on the wrong clock frequency).
Ultimately, I'd like to just fully understand the code as I attempt to make changes for my own purpose, or before trying to use it as an example to build a custom BLE profile ... so I want to make sure the code for my starting point is accurate
I'm new to both BLE and the Ambiq MCUs so this is a learning moment. I'm mostly interested in the Apollo3 (since this is what I have) and was hoping to minimize learning much about the Apollo2 and differences to the Apollo3 in order to do this.Specifically, another place where there is a check for AM_PART_APOLLO2 but not AM_PART_APOLLO3 which looks conspicuous: in main(), inside the ble_freertos_tag.c example source code file:
Code: Select all
Notice that there are tests for both the APOLLO and the APOLLO2, but not the APOLLO3. I would think that something comparable should be here & perhaps the worst case is that my power consumption is a little higher until I figure this out (although, the low power seems to be a huge selling point of these Ambiq parts, so I'd love to finalize tweaks like this at some point). It looks like both Apollo2 & 3 have a similar FLASH setup, but the SRAM is different ... so I'm not immediately sure. // Turn off unused Flash & SRAM
#ifdef AM_PART_APOLLO
//
// SRAM bank power setting.
// Need to match up with actual SRAM usage for the program
// Current usage is between 32K and 40K - so disabling upper 3 banks
//
am_hal_mcuctrl_sram_power_set(AM_HAL_MCUCTRL_SRAM_POWER_DOWN_5 |
AM_HAL_MCUCTRL_SRAM_POWER_DOWN_6 |
AM_HAL_MCUCTRL_SRAM_POWER_DOWN_7,
AM_HAL_MCUCTRL_SRAM_POWER_DOWN_5 |
AM_HAL_MCUCTRL_SRAM_POWER_DOWN_6 |
AM_HAL_MCUCTRL_SRAM_POWER_DOWN_7);
#if 0 // Not turning off the Flash as it may be needed to download the image
//
// Flash bank power set.
//
am_hal_mcuctrl_flash_power_set(AM_HAL_MCUCTRL_FLASH_POWER_DOWN_1);
#endif
#endif // AM_PART_APOLLO
#ifdef AM_PART_APOLLO2
#if 0 // Not turning off the Flash as it may be needed to download the image
am_hal_pwrctrl_memory_enable(AM_HAL_PWRCTRL_MEMEN_FLASH512K);
#endif
am_hal_pwrctrl_memory_enable(AM_HAL_PWRCTRL_MEMEN_SRAM64K);
#endif // AM_PART_APOLLO2
There are at least a few other places with similar discrepancies in the ble_freertos_tag example, and I'm sure in other example projects as well.
So ... I guess my questions are (hopefully from SF, Ambiq or other experienced SW folks monitoring this forum): Are there other updates to the example projects that accurately reflect code mods to better support Apollo3 parts? Will these differences create other unforeseen problems functionally (aside for perhaps higher than expected power consumption)? Has anyone else noticed similar issues and already gone through the code and figured out what changes, if any, are needed to work correctly in Apollo3 parts (like the Edge board)? Instead of posting/asking about each one directly in the repo, I figured I throw up the question to the whole forum community here.
Thank you for any help or other guidance about these issues. I really like this board & am hoping to use it for a couple of cool personal projects!
- Keith
