Yes, the USART still can receive one more frame data after deasserting RTS pin.
The USART on series 1 devices EFM32PG1 / EFM32JG1 / EFM32PG12 / EFM32GG11 has separated receive / transmit multiple entry buffers, and an additional separate shift registers.
If the receive buffer is full, the RXFULL in USARTn_STATUS and the RXFULL interrupt flag in USARTn_IF will be set to notifying that there is no more space in the receive buffer is available. However, space is still available in the receive shift register for one more frame.
The RTS is an out going signal be controlled by USART peripheral which indicates that RX buffer space is available to receive a frame or not. If the receive buffer is full, USART will deassert the RTS pin, the one more frame data on the line still can be received by the USART since the receive shift register is empty.
In the LFXO Configuration section of the CMU chapter on EFM32 Series 1 and EFR32 devices, the following equation is presented for calculating the value of the CMU_LFXOCTRL register's TUNING bit field:
TUNING = ((desiredTotalLoadCap × 2 - Min(CLFXO_T)) / CLFXO_TS)
What is or where do I find the CLFXO_TS parameter? I need this in order to adjust the LFXO's tunable load capacitors to match the specification for the crystal in my design.
For the equation above to get you a register bit field value, the result needs to be dimensionless, i.e. it cannot have any units. Needless to say CLFXO_TS must be a datasheet or other parameter, ideally quantified in pF.
Looking at the table under Electrical Specifications → Electrical Characteristics → Oscillators → LFXO in any EFM32 Series 1 or EFR32 datasheet, CLFXO_TS is not listed. However, right under the CLFXO_T parameter, which is in the equation above, there is a specification for the on-chip tuning capacitor step size, in pF, with the symbol SSLFXO.
This parameter makes sense in the equation above because if you divide the numerator by the step size, you get a value without units. Likewise, min(CLFXO_T) is specified in the datasheet as 8 pF, so you know that if 16 pF is desired for the total loading capacitance of a given crystal, then TUNING = 0 gets the minimum CLFXO_T value of 8 pF.
Finally, it follows that if CLFXO_T is intended to be read as "LFXO tuning capacitance" then reading CLFXO_TS as "LFXO tuning capacitance step size" isn't much of a stretch. Another way to clear up this confusion is simply to rewrite the equation above as:
TUNING = ((desiredTotalLoadCap × 2 - Min(CLFXO_T)) / SSLFXO)
Is it possible to clock the RTC at a frequency higher than 32.768 kHz?
Yes. One would notice that all our specifications in the datasheet refer to the 32.768 kHz crystal. This is because all of our characterization tests have been conducted with a 32.768 kHz crystal and that is why the specs in the datasheet refer to it. But the RTC in itself has been designed to be clocked at a higher frequency. Hence, it is possible to run the RTC through an external clock running at a higher frequency - the maximum being 1 MHz.
Does the RAMPOWERDOWN bit field in EMU_RAM0CTRL only take effect when entering EM2 or EM3, or does it take effect immediately in any energy mode? In other words, can some of the RAM be shut off in any energy mode to conserve power?
This is a question well worth investigating. If your application can be structured in such a way that RAM is only powered when needed, why not disable unused banks to further optimize your system's overall energy usage.
At first blush, it appears that there might be something to this. Here's a dump of RAM on a Pearl Gecko device around address 0x20001000 with RAMPOWERDOWN = 0. All blocks are enabled, and we can see the words at 0x20001000 and 0x20001004, which are the first and second words of the second 4 KB block of RAM, hold 0xFFFFFFFF and 0x11112222, respectively.
So, now let's write RAMPOWERDOWN to 0xF, which disables all RAM blocks except for the first 4 KB from 0x20000000 to 0x20000FFF. We'll force Simplicity Studio to refresh the Memory View by writing 0x33334444 to the word at 0x20001004:
Lo' and behold, it looks like the RAM blocks starting at 0x20001000 are now powered down! No data is showing and trying to write 0x33334444 to address 0x20001004 had no effect.
Alas, this is not the case. The now inaccessible RAM blocks, in fact, remain powered, as we can see by writing RAMPOWERDOWN back to 0 and writing 0x33334444 to 0x20001004 to refresh the display:
If the RAM blocks were getting powered off, the locations shown above shouldn't retain the values previously written to them. What's actually happening in EM0 and EM1 because it certainly looks like something's getting disabled when 0xF is written to RAMPOWERDOWN?
As is common in digital logic design, enable signals for memories, analog blocks, and digital logic are generally qualified by more than one input. For example, an on-chip analog-to-digital converter might not perform conversions if its reference is not powered up because the conversion start signal is qualified with a signal that indicates that the reference is powered and ready.
Because RAMPOWERDOWN is intended to take effect in EM2 and EM3, it should come as no surprise that the enable signals for the blocks that can be powered down are qualified by an indication that the CPU is in sleep mode.
This can be tested by running the attached simple project on a Pearl Gecko 1 Starter Kit (SLSTK3401A). All the code does is show the contents of RAM locations 0x20001000 and 0x20001004 discussed above before and after entering EM2.
Note that the code must be run on the Starter Kit (STK) while it is powered from a battery, and the switch next to the battery is in the BAT (left) position. The code will not work as expected if the STK remains connected with the debugger running because when debug is active, the MCU never truly enters EM2 or EM3. Instead it remains in a kind of modified EM1, which, as noted above, means that none of the RAM blocks is ever powered down.
As the picture above shows, the RAM contents are not preserved after exit from EM2, demonstrating that the selected blocks are, in fact, powered down.
To run the test code, download the attachment and import it into Simplicity Studio using the following procedure:
Note that while this code is written for the Pearl Gecko STK, it will run unmodified, if inserted into a new project, on the majority of Blue, Flex, and Mighty Gecko radio boards connected to the Wireless STK motherboard. The same explanation above regarding RAMPOWERDOWN behavior applies to these devices.
Across the board, this information applies to all EFM32 Series 1 and EFR32 devices with the sole difference being the RAM blocks that are powered down in EM2 and EM3 (made inaccessible in EM0 and EM1) or that remain active. The reference manual description of the EMU_RAM0CTRL register details which blocks are affected by the RAMPOWERDOWN bit field for a given device.
Using the AN0042 bootloader on EFM32 STK's can be a bit tricky. Here are the complete steps required to do so:
Attached to this article is a python 3 script that will determine the clock divider, for a particular UART configuration (desired baudrate, HFPER clock, and oversample value) to reach the closest baudrate to the desired baudrate. It will then calculate and output the actual baudrate and the amount of error between it and the desired baudrate.
Here is the output of the script:
When using a Low Energy Peripheral (one clocked by the LFB or LFA clocks) with Delayed Synchronization, where the Low Frequency clock is selected to be HFCORECLK/2, is it necessary to monitor the SYNCBUSY register between subsequent asynchronous register writes or reads?
No. In this case, no synchronization with the Core clock domain is necessary, since both the peripheral and the core are being driven by the same clock, and thus they are always synchronized.
The value of this bit may be indeterminate when the core and LF clocks are the same, so polling this bit should be avoided.
Additionally, be mindful of the HFCORECLKLE/HFCLKLE frequency limitations, as noted in this article: http://community.silabs.com/t5/32-bit-MCU-Knowledge-Base/Maximum-HFCORECLKLE-HFCLKLE-frequency-and-HFLE-WSHFLE/ta-p/140458
For most devices, the maximum LE clock is 16 MHz, although it is 12 MHz on some devices. See the table in the article for more details.
For EFM32, EFR32 and EZR32 parts, what is the state of the GPIO pins of an unprogrammed part, and of a part during programming?
The reset state of the IO pins is disabled: high impedance, no pull resistor. This will be the case at power up, for an unprogrammed part, as well as while being programmed.
How to identify the revision of the Pearl Gecko chip on the Pearl Gecko STK (SLSTK3401A)?
There are two versions of the board that comes in SLSTK3401A:
- PCB2500A Rev. A00 using EFM32PG1B Rev. B
- PCB2500A Rev. A01 using EFM32PG1B Rev. C with UART Bootloader
The kit version can be detected by Simplicity Commander.
The Simplicity Commander tool can be found from link below:
Note: The pre-programmed UART Bootloader (AN0003) is not available on PG1 revision B devices.