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:
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.
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).
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.
