- Silicon Labs Community
- Welcome and Announcements
- Silicon Labs Knowledge Base
- 8-bit MCU
- 32-bit MCU
- Bluetooth / Wi-Fi
- Other Products Category
- Optical/RH/Temp Sensor
- Other Products
- Hardware and Software Tools
- Simplicity Studio and Software
- General Discussions and Suggestions
- Chinese Forum
- Software Libraries
- Development Kits
- Reference Designs
- Third Party Tools
- White Papers
- Official Blog of Silicon Labs
- Chinese Blog
10-02-2017 10:39 PM
I am using EFM32 Zero Gecko Starter kit (EFM32ZG-STK3200A). I am trying to set up SPI Master mode on USART1 (loc 3) : CLK-PC15, CS-PC14, RX-PD6, TX-PD7, and have set up baudrate as 1Mhz. I am sending single byte using function USART_SpiTransfer(USART1, dataByte). I can see the CLK and TX signals on oscilloscope, they look fine, but the CS stays low - no activitiy at all. I have the following code to send a byte:
Before I did not have the two lies - MaxCSLow() and MaxCSHigh(), hoping that the USART1 will automatically handle CS since the CS is tied with USART1, but it did not do anything, so I added these two lines, but still it does not toggle. My questions:
1. What is going wrong?
2. There is another port pin that I am using - which toggles fine with similar command - MaxRSTLow() and MaxRSTHigh() and also the LED blinks fine. Why can't the CS line toggle?
3. Is there a way to disassociate CS pin from USART1? i.e. in standard SPI mode, USAR1 has 4 pins - CLK, CS, TX, RX - how can I have USART1 in SPI mode only 3 pins - CLK, TX, RX ? So that I can take any port pin to function as CS independently?
4. I am using Harware Configurator with Simplicity Studio4, I also tried setting DataOutput = 1 in the properties window for CS pin - it does not change the default output on that pin. But it works for other port pin.. not sure why?
Thanks in advance!
Solved! Go to Solution.
10-03-2017 04:11 AM
I assume the USART CS line is not a master output but a slave input. If you want another master to select this MCU as slave then its CS must be selected. I suggest not to enable CS in the USART and use GPIO to select your slave device through this pin.
10-03-2017 10:12 AM
If you want the USART to handle the chip select, make sure AUTOCS is enabled in the USARTn_CTRL register, CSPEN is enabled in USARTn_ROUTE, and the appropriate GPIO is set to push pull mode. If you disable autocs, you can control the chip select as a GPIO.
10-03-2017 01:27 PM
Also note that AUTOCS toggles on a per byte basis. If you need to transfer a string of data (and you are not using DMA), AUTOCS will not keep CS asserted for you unless you happen to be in a very tight loop that keeps the USART TX FIFO fed.
10-03-2017 11:11 PM
Thanks for your reply. In the Configurator, it automatically selects CS as part of SPI and I tried deselecting CS for USART1 but the Configurator gave an error - "USART1_CS pin is in use and must be enabled" - but diregarding that message I actually deleted that error. And compiled, and it worked as expected - with CS line controlled as GPIO as per the following code:
Now I see another issue - seems the CS stays low much longer - before and after transmitting the data/clock time.
So I would try to use the AUTOCS option
10-04-2017 11:57 AM
I tried AUTOCS and it works perfectly fine! Not need to use the manual control of CS line;
Just remember, AUTOCS will assert and de-assert CS for each byte you send. If this is not desirable behavior, you will need to control CS as a GPIO.
Regarding the slow GPIO toggling you are seeing, I suspect you are compiling your code using the Debug configuration. This imposes certain overhead that cuts GPIO toggling time by close to an order of magnitude.
See this Knowledge Base article for details.
10-04-2017 07:13 PM
That is really awesome! Thank you so much for the explanation and the link for the article
I tested with the Release config using GNU ARM 4.9.3 and the code with manual handling of CS works just as expected. The manual CS option is more preferred when there is longer data string exchange between MCU and SPI.
Thank you all once again!