I’m working on a customized firmware that is meant to run on RAK3172 modules. However, there is conflicting information on what is actually connected to the HSE32 peripheral on the module:

  • RAK3172 Internal Schematic - #2 by beegee and the block diagram in the module’s datasheet suggest it’s a TCXO with power gating via PB0
  • The documentation linked in Low Level Development of RAK3172 - #4 by carlrowan suggests it’s a regular crystal, as it specifies disabling TCXO control (i.e. power gating via PB0) and gives specific values for configuring the trimming capacitor banks in the device, which only makes sense for a crystal driven by the internal crystal driver (note that the document linked in that post talks about “LSE” trimming, but that does not make sense as the LSE caps cannot be trimmed and in fact the included files modify XTAL_DEFAULT_CAP_VALUE from 0x20 to 0x10)

So what is really going on here? What is the correct configuration for the HSE32 block?

All of this would be much easier if you just released the schematics for the RAK3172, please reconsider doing that.

1 Like

Hi @fynn ,

What @beegee sent to you is correct. There is a TCXO in the module with the pin assignments as shown in the snippet of the schematic shared.

Regarding the file I shared, that modification is not using the TCXO yet. It uses MSI set at 48Mhz.


Thank you for your quick reply!

Regarding the file I shared, that modification is not using the TCXO yet. It uses MSI set at 48Mhz.

Hmm, that still doesn’t fully make sense to me. Sure, the MCU part can be clocked from MSI and that’s fine. But the radio peripheral will always be clocked from HSE32:

Thus, the HSE32 configuration must be correct even when the rest of the system is clocked from MSI, as long as the radio is used at all.

Your code snippet at Low Level Development of RAK3172 - #4 by carlrowan sets IS_TCXO_SUPPORTED to 0. This will cause the SUBGRF_Init function to not configure power for / calibrate the TCXO (and conversely, tuning capacitor values will be configured, although those probably don’t cause problems for a TCXO). So if this works it’s more by accident (e.g. because the default Vddtcxo supply voltage matches the one the RAK3172 needs).

Hi @fynn ,

I understand you. Sorry for the confusion. I just confirmed that there was no TCXO placed but a normal crystal is present.

Here is the datasheet of the XTAL oscillator.

1 Like

Hi @carlrowan,

thanks for the clarification! This makes much more sense now.

Given that the datasheet mentions a TCXO, I guess this change was a result of the current shortages? Are there any plans to switch back to a TCXO in the future?

I’m asking because then you’d need a way to distinguish the crystal vs. TCXO module versions, either through different SKUs or some mechanism that would allow one to distinguish the different population options in software so that it can configure the HSE32 block accordingly.

1 Like

You got it exactly @fynn ! :clap:

It was because of the shortage. There was no plan yet for the TCXO but a hardware version will be different on modules with TCXO and without.

Alright, thanks again for your help!

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.