Lost in the device-configurator

I’m trying to figure out what requirements, if any, the onethinx module have regarding configuration set in the device-configurator.

I need to enable the “System Clocks” section to get some peripherals going. But after doing so I cant do any lorawan stuff any more.
I have tried to compare with, and configure accordingly, to the old modustoolbox-1.1 example packs. But so far not much luck.

I would prefer an explanatory instruction over a premade design.modus file. The later will just require me to reverse engineer it down to the former.

Hi mogul,

The Modus configurator unfortunately generates a conflicting clock config compared to what is done internally on the M0+.

The solution is use the template which comes with the VS Code Helloworld example and to keep the top-level System Clocks disabled. You are able to use the peripheral clocks based on the (disabled) system clock configuration as in the example (the clocks are configured correctly).

We’re currently working with Cypress to see if there’s a better solution.

I’m sorry for the misunderstanding, we should have made a note of it to avoid any confusion…

After an evening experimenting, trying to figure out what was going on I think I got it now:

  • If “System Clocks” have to be disabled, it does not matter what else is set in the System tab.
  • Even when “System Clocks” are disabled, values set in the System tab affect the frequency calculations done elsewhere in the Device Configurator
  • If “System Clocks” are disabled Input to Peripheral-Clocks is always 8 MHz
  • To get the calculations in Peripheral-Clocks and Peripherals tabs right, it is safe to adjust values in the System tab to get the 8MHz output from CLK_PERI

@Rolf do agree? Is there more to the story?

Does this mean I can’t create a clock higher than 8 MHz?

You can. You can use the FLL or PLL to create the clock configuration of your choice. You can also use the 32MHz on-board ECO clock as your source.

I will provide a list of things to keep in mind.

I tried going the PLL path with “System Clocks” disabled, as seen here:


As you can see, there is an advisory stating that top-level system clocks must be enabled to generate clock initialization code. Building resulted in errors concerning the PLL (see below).

After re-enabling System Clocks, the PLL error went away, but it was replaced by another error (see below).

Attempting to use the ECO


yielded the following:

Attempting to use the FLL


yielded the following:

Did you do a clean reconfigure each time you changed the configuration?

Each time files are added or removed from the project, a clean reconfigure needs to be done…

Configured for ECO:


Did a clean reconfigure and a clean rebuild. Result is:

Hi Paul,

Will look into this tomorrow. We need some small fixes in our BSP library. Are the configurations you posted the preferred ones?

Rolf

Not necessarily. I was just trying to find a combination that would work.

I’m confused about the clocking situation. If I read the configurator correctly, it would appear that, in the VSCode HelloWorld example, both cores are being clocked at 8 MHz. But that doesn’t seem likely to me. What am I missing?

Paul

Actually, it would be nice to have use of the ECO, since the module already has a crystal (I think).

Rolf,

Over the weekend I made it work. So far, I’ve only done it with ModusToolbox. When I have time, I’ll try to do it with VSCode. Here are some comments and observations, in no particular order.

  • In a couple of projects, someone at Onethinx added the following statement to the PDL header file cy_ble_clk.h: #define CY_CFG_SYSCLK_ALTHF_ERROR 2. This presumably was to allow use of the ALTHF oscillator without compiler error.
  • It appears that this fix would only work for projects that have the PDL drivers included in the project. Two such projects are ModusToolbox2.0_HelloWorld and VSCode_HelloWorld_fullpack.
  • My copy of cy_ble_clk.h has the following defines:
    • #define CY_CFG_SYSCLK_ECO_ERROR 1
    • #define CY_CFG_SYSCLK_ALTHF_ERROR 2
    • #define CY_CFG_SYSCLK_PLL_ERROR 3
    • #define CY_CFG_SYSCLK_FLL_ERROR 4
    • #define CY_CFG_SYSCLK_WCO_ERROR 5
  • I got these values by checking System Clocks in the configurator, then looking at the Code Preview tab.
  • I think I was mistaken when I said I wanted to use the ECO. What I really want is to use whatever clock is crystal generated on the module, which I believe is the ALTHF. Am I correct?

Paul

Hi Paul,

Good to hear you made progress.

I don’t know why the cy_ble_clk.h is having the define. You could be right that it was added to prevent compile errors. The problem with the updates on ModusToolbox is that each time a lot of changes are done at the low level clock drivers. We have seen multiple problems with several PDL versions.

Usually step-debugging would lead to the problem but it can be a tough job, I know.

There are three external crystal clock circuits available, the WCO, the ECO and the BLE ECO (ALT HF). The module uses the low power WCO (in sleep and hibernate for the RTC as well) and the BLE ECO. The BLE ECO is using a 32MHz XTAL (shared with the LoRa radio) and a 32.768KHz XTAL for the WCO.

Both clocks are enabled by the M0+. The LoRaWAN stack uses the WCO for timing and the BLE ECO to clock the LoRa radio. The rest of the clock configuration can be modified by the developer using the M4, if all okay we wouldn’t expect any problems over there…

Rolf

Hi Rolf,

Thanks for the info. I just opened an unaltered ModusToolbox2.0_HelloWorld project.


The configurator shows the following:

  • IMO is 8 MHz
  • ALTHF (BLE ECO) is 32 MHz
  • CLK_HF0 is 32 MHz, sourced by ALTHF via CLK_PATH2
  • CLK_PERI is 16 MHz
  • WCO is not enabled

The configurator shows ALTHF frequency is 32 MHz. Also, the following excerpt from the module specification shows a 32 MHz crystal. Are these not correct?

Paul

I’m not at my computer right now, I think the ALTHF divider is set to 4.

Rolf