Hello Kevin: Well, I just woke up and havent had my coffee yet, so if this response makes no sense you know why :-)
I certainly agree that what you have run across here is an issue that we will have to deal with. Certainly the clock source and/or its availability needs to be dictated by the BSP. We have discussed how clocks get handled by the bsp and realize that we need to do a bit of work on this. We also need to consider how the application developer gets to choose which clock source to use as (demonstrably) there will be multiple choices for a given BSP and (imo) it should be possible for the app to choose this (or at least define it in the bsp). Anyway, I will add a jira ticket for this and we will address it in the upcoming release (or sooner). If you have any ideas/suggestions on how this should work in the system please let us know. We will discuss here on the dev list so please chime in. Thanks! Will > On May 11, 2016, at 5:32 AM, Kevin Townsend <[email protected]> wrote: > > Just as a follow up, I was able to get the code to run with the following > modifications on a nRF51 based board with no 32kHz XTAL present (i.e.: > https://www.adafruit.com/product/2267): > > /* Turn on the LFCLK */ > NRF_CLOCK->XTALFREQ = CLOCK_XTALFREQ_XTALFREQ_16MHz; > NRF_CLOCK->TASKS_LFCLKSTOP = 1; > NRF_CLOCK->EVENTS_LFCLKSTARTED = 0; > // KTOWN: Changed to simulated LF clock > // NRF_CLOCK->LFCLKSRC = CLOCK_LFCLKSRC_SRC_Xtal; > NRF_CLOCK->LFCLKSRC = CLOCK_LFCLKSRC_SRC_Synth; > NRF_CLOCK->TASKS_LFCLKSTART = 1; > > /* Wait here till started! */ > // KTOWN: Changed to simulated LF clock > // mask = CLOCK_LFCLKSTAT_STATE_Msk | CLOCK_LFCLKSTAT_SRC_Xtal; > mask = CLOCK_LFCLKSTAT_STATE_Msk | CLOCK_LFCLKSRC_SRC_Synth; > > > On 11/05/16 14:04, Kevin Townsend wrote: >> >> While working on a BSP based on the nRF51 SoC, I noticed what may be an >> issue with the current division of config data between the 'bsp' and the >> 'mcu' code. >> >> For the nRF51 (and likely the nRF52, I haven't looked yet) the LF clock >> source is defined in 'mcu/nordic/nrf51xxx/src/hal_os_tick.c': >> >> /* Turn on the LFCLK */ >> NRF_CLOCK->XTALFREQ = CLOCK_XTALFREQ_XTALFREQ_16MHz; >> NRF_CLOCK->TASKS_LFCLKSTOP = 1; >> NRF_CLOCK->EVENTS_LFCLKSTARTED = 0; >> NRF_CLOCK->LFCLKSRC = CLOCK_LFCLKSRC_SRC_Xtal; >> NRF_CLOCK->TASKS_LFCLKSTART = 1; >> >> The XTAL is hard coded as a source, meaning that a 32kHz crystal must be >> present on the board for the LF clock to work. This is really a board level >> choice, though, and we have a number of boards in production that left the >> 32kHz crystal off to control costs at the tradeoff of slightly higher power >> consumption, simulating the LF clock with the mandatory 16MHz XTAL (which is >> a valid choice with the nRF51 SoC). >> >> The real question, of course, is if clock source or PLL setup decisions >> (frequency, multipliers, etc.) should be defined in the 'mcu' or migrated to >> the 'bsp' level? Hard coding this without an easy override seems like an >> unnecessary restriction and will just push people to modify the global MCU >> code. >> >> There is a small design challenge defining a generic interface for this, of >> course, since the clock or PLL config and setup is specific to individual >> silicon vendors and their own design decisions, but if there isn't already a >> mechanism to define clock source and setup at the BSP level (perhaps I >> simply missed it!), it's probably worth considering. >> >> Before going to far into it though, perhaps there is already a mechanism I >> missed to the end. >> >
