I have a QN9080 chip revision D (QN9080DHNE) and I believe the internal OSC32M is running at 48 MHz, not 32 MHz. Is this even possible?
Here are the experiments I ran, the board has a 32 MHz external XTAL, I checked it with the oscilloscope and it runs at 32 MHz. When selecting the external XTAL as the system clock (CLOCK_AttachClk(kXTAL_to_SYS_CLK);) and setting a 115200 baudrate USART in FLEXCOMM0 everything works as expected and I see 115200 data on the serial port (~8.66us pulses in the TX line).
However, if all I change is the SYS clock to the internal OSC32M (CLOCK_AttachClk(kOSC32M_to_SYS_CLK);) then the USART output is wrong (the pulses are shorter). I did the math and it basically meant that the flexcomm clock was running at 48 MHz rather than the expected 32 MHz. So if I also change the "USART_Init(..., 32000000)" to use 48000000 everything works as expected in the USART output, which is a surprise.
Both the internal OSC32M_DIV and external XTAL_DIV are set to not divide, and there isn't really any other modification I can find to the OSC32 after reading the errata and the UM11023 user manual several times. The USART might not be the best example in terms of configure clocks, so I made the following example that shows the clock of the system in the output. This code is a 8-cycle loop, setting a GPIO pin in GPIOA (the GPIONUM one, previously set as an output) high for 4 cycles and low for another 4 cycles. Running this on the chip with the external XTAL as system clock gives me a 4 MHz 50% duty cycle in the output pin; while running this same code with the system clock set to OSC32M it gives me a 6 MHz clock in the pin. This shows that chip is running at 48 MHz, or I'm missing something else.
#define GPIONUM nn __asm__ volatile ( "loop:;\n" " str %[off], [%[outdata]]\n" " nop\n" " nop\n" " nop\n" " str %[on], [%[outdata]]\n" " nop\n" " b loop\n" : /* no outputs */ : [outdata] "r"(&(GPIOA->DATAOUT)), [on] "r"(GPIOA->DATAOUT | (1 << GPIONUM)), [off] "r"(GPIOA->DATAOUT & ~(1 << GPIONUM)) : );
Some details from the chip:
Vdd is 1.8v from external power supply.
SYSCON->CHIP_ID = 0xfc00d010
SYSCON->FC_FRG = 0x00ff00ff (thus, MULT0 = 0 and therefore flexcomm0 clock == CLOCK_GetFreq(kCLOCK_BusClk))
SWD connected to an LPC-Link2.
Hi Iosabi, I hope you're doing well!
The Internal oscillator of the QN9080 should max out at a frequency of 32 MHz. This is by design, and a frequency of 48MHz should not be possible under normal circumstances.
Could you please try routing the CLKOUT signal to PA28? This way, the system clock can be directly measured on that pin. (Please note that the signal may be deformed, but should still be 32MHz).
Is the signal being outputted from that pin still 48MHz?
Best regards,
Sebastian
Thanks Sebastian for your reply.
I set PA28 to FUNC1 (CLK_AHB), and with all three divisors set to /1 (OSC32M_DIV, XTAL_DIV, AHB_DIV) I see a very clear clock running at 48.08 MHz as measured with the oscilloscope, although it is a bit deformed and I measure a peak value of about 1.14v instead of the 1.8v the core is running at.
If set the OSC32_M DIV to /2 to bring down these frequencies I see a 24.04 MHz, now with a peak voltage of about 1.8v and nicer shape.
When using the external XTAL and repeating the measurements I see 32 MHz and 16 MHz respectively (using XTAL_DIV instead of OSC32M_DIV). So, I'm pretty convinced now that the internal RCO is running at 48 MHz.
If you want I can provide you the markings on the chip or other identification you may need.
Hi Iosabi,
We are currently investigating the possible issue, thank you so much for your feedback!
I will update you on this topic as soon as possible.
Best regards,
Sebastian
FYI, I tested the internal RCO32K by enabling the 32K output on PA10 and it also gives me a bad frequency (55.2KHz in that case). If I set the external 32K xtal as the 32K source I do get the expected 32.768 KHz signal in PA10, but when using the RCO32K I see a very well formed, nice and squared, but quite off frequency. Functions like RTC don't work as expected with the wrong 32K clock frequency (INT_SEC triggers significantly faster than once a second).
As a note, I'm running at 1.8v and not using the internal buck converter. Is there any calibration that needs to be adjusted for those conditions?
Hi Iosabi,
We will also take a look at this other possible issue you're pointing out.
Thank you so much for your feedback, we will get back to you as soon as possible.
Best regards,
Sebastian