sparkfun / SparkFun_Apollo3_AmbiqSuite_BSPs

One-stop-shop for all your AmbiqSuite SDK board support package needs.
27 stars 21 forks source link

FreeRTOS example code clock-rate error? #32

Closed pfliegster closed 4 years ago

pfliegster commented 4 years ago

Hello, Thanks for creating and maintaining this great resource for us hobbyists (and pros) to learn and create!

I have a SparkFun Edge (with Ambiq Apollo3 Blue) and I'm attempting to modify one of your example programs for my own use (starting from the ble_freertos_tag example). In reviewing some of the existing code and trying to understand what it does and what I should change, I came across what I think is an error ... the following code snippet is from the FreeRTOSConfig.h file:

#ifdef AM_PART_APOLLO2
    #define configCPU_CLOCK_HZ                  48000000UL
#else
    #define configCPU_CLOCK_HZ                  24000000UL
#endif

For AM_PART_APOLLO3 (which is set in the Makefile for the Edge board, as expected), I think this will tell the FreeRTOS system that the CPU clock is 24 MHz, instead of the 48 MHz that Apollo3 is running at (like Apollo2).

Tracking this C Macro a little, it looks like it is used by another macro (configSYSTICK_CLOCK_HZ), which will then have error in timing of the RTOS and I believe results in the timer interrupts happening twice as often as they should, possibly increasing power consumption and processor overhead.

I noticed the same thing in Ambiq's own example code (e.g. ble_freertos_fit), possibly from where your ble_freertos_tag code is derived, and think this was just an oversight (my hunch is that this part of the code started as an older example and was not updated to reflect APOLLO3 part settings). I'm hoping other changes between Apollo2 and Apollo3 are correctly reflected in the code repository (or don't affect operation). I'm otherwise not entirely sure how it affects real-world operation of the example, except possibly bluetooth communication timeouts being 1/2 as long?? I'm still trying to track this ...

As I'm kind of new to this, I may be missing something else that would explain this discrepancy ... in which case, please excuse my error :-)

Otherwise, this is my own quick-and-dirty fix (since it actually looks like everything released after the original Apollo is now at 48 MHz):

#ifdef AM_PART_APOLLO
    #define configCPU_CLOCK_HZ                  24000000UL
#else
    #define configCPU_CLOCK_HZ                  48000000UL
#endif

Thanks in advance for an answer, alternate/recommended fix, or update to the GIT repo!

oclyke commented 4 years ago

@pfliegster wow, fantastic catch! Thank you a lot for reporting this. At a first glance I like your solution a lot - it seems simple and effective. One thing that I would like to consider more is what happens when the Apollo3 is put into burst mode (doubles clock to 96 MHz). But at least as a start this is a great idea.

I will also consider elevating this issue to the AmbiqSuiteSDK mirror repo.