Hi Joakim! Thanks for the update! I’ll test it asap on PR #7181 which will need an update since #7209 was merged.
I’ll keep you updated on the results. Cheers, -- Francisco Javier Acosta Padilla Research Engineer at INRIA Saclay INFINE Team On 18 July 2017 at 09:47:13, Joakim Nohlgård (joakim.nohlg...@eistec.se) wrote: Hi again Francisco, See https://github.com/RIOT-OS/RIOT/pull/7379 for an updated clocking configuration for Kinetis boards. I think it will be more robust against non-default starting values because it tries to go to a safe mode (using the internal reference clock) before reconfiguring the clock setting registers. Best regards, Joakim On Tue, Jun 13, 2017 at 3:12 PM, Francisco Javier Acosta Padilla <francisco.aco...@inria.fr> wrote: > Hi Joakim! Thanks for the hints. > > Your proposed approach at a first sight it seemed to work, then I rebased on > your PRs and it didn’t work anymore. But more strange, I reverted your > commits and it doesn’t work either… However, with the clock configuration > that I proposed before it still works, either with your commits or without. > > I continue my quest… > > Cheers, > > -- > Francisco Javier Acosta Padilla > Research Engineer at INRIA Saclay > INFINE Team > > On 12 June 2017 at 19:36:46, Joakim Nohlgård (joakim.nohlg...@eistec.se) > wrote: > > Hi, > I think the wisest choice is probably to switch to FEI mode first to use the > internal oscillator before booting a new image. That is the same mode that > the mcu comes up in after a hardware reset. > > There are some relevant PRs open on GitHub for the Kinetis clocking: > https://github.com/RIOT-OS/RIOT/pull/6986 move k64f clock configuration to > board config > https://github.com/RIOT-OS/RIOT/pull/6978 MCG improvements > > Best regards, > Joakim > > > On Jun 12, 2017 16:36, "Francisco Javier Acosta Padilla" > <francisco.aco...@inria.fr> wrote: > > Hi again! > > I just made it work, though is super strange why it works… I did: > > static void cpu_clock_init(void) > { > /* setup system prescalers */ > SIM->CLKDIV1 = ( > SIM_CLKDIV1_OUTDIV1(0) | /* Core/System clock > divider */ > SIM_CLKDIV1_OUTDIV2(1) | /* Bus clock divider */ > SIM_CLKDIV1_OUTDIV3(1) | /* FlexBus divider, not > used in Mulle */ > SIM_CLKDIV1_OUTDIV4(3)); /* Flash clock divider > */ > > //SIM->CLKDIV1 = (uint32_t)SIM_CLKDIV1_60MHZ; > > /* RMII RXCLK */ > SIM->SCGC5 |= SIM_SCGC5_PORTA_MASK; > PORTA->PCR[18] &= ~(PORT_PCR_ISF_MASK | PORT_PCR_MUX(0x07)); > > kinetis_mcg_set_mode(KINETIS_MCG_PEE); > } > > And it works… any explanation? I took the values from the k60f code (mulle) > which seems to be completely different to the values contained in the macro > SIM_CLKDIV1_60MHZ (0, 0, 1, 2 values). Therefore, I have no idea on which > speed the clock is running. > > BTW, with this code also works for a “normal” build, compiling and flashing > as usual. > > I’ll look at the manual to see why we do that on RIOT (it’s not documented) > and maybe submit some PRs to both add doc and fix the setup if needed. > > Cheers, > > -- > Francisco Javier Acosta Padilla > Research Engineer at INRIA Saclay > INFINE Team > > On 12 June 2017 at 15:16:28, Francisco Javier Acosta Padilla > (francisco.aco...@inria.fr) wrote: > > Hi RIOT devs! > > I’m currently working on the RIOT port for MCUBoot[1], which takes the > frdm-k64f board as a reference board, and that’s also supported by RIOT and > other OSs using MCUBoot. > > My first goal is to provide a “bootable” image compiled in RIOT and booted > by MCUBoot built for mynewt. > > The work is going well so far, but I’m facing a problem which was also > present while coding the RIOT bootloader. Namely, the problem is that the > bootloader initialises the clock to a specific speed to run the booting > algorithm, which goal is to boot an OS in another flash position, an thus > the clock is initialised again leading to a clock crash. > > Does anyone knows a “safe” way to reset the clock config to afterwards > configure it to the desired speed? Currently, as the code shows for the > k64f, the assumption is that the clock is in it’s default condition, which > is true when a reset is triggered, but now in this new context it’s not true > anymore. > > I have seen some examples here [2] and here [3] which I tried without > success. > > Thanks in advance! > > Cheers, > > -- > Francisco Javier Acosta Padilla > Research Engineer at INRIA Saclay > INFINE Team > > [1] https://github.com/runtimeco/mcuboot/ > [2] > https://github.com/apache/incubator-mynewt-core/blob/master/hw/mcu/nxp/src/ext/sdk-2.0-frdm-k64f_b160321/devices/MK64F12/drivers/fsl_clock.h#L897 > > [3] https://github.com/RIOT-OS/RIOT/blob/master/boards/mulle/board.c#L170 > > > _______________________________________________ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel > > > _______________________________________________ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel
_______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
