Transferring and receiving more than 32-bits over Teensy 4.1 SPI at same time - spi

I want to read and transfer more than 32 bits over SPI using teensy 4.1 on Arduino IDE.
Hi! I want to read binary data comprising of 100 bits. The data is synced at 1.8Mhz clock and I am able to sync Teensy 4.1 with it. What I want to do is, I want to read that data through SPI with no CS pin by making the SPI clock 1.8Mhz. I achieved this but the microcontroller SPI is running in non-continuous mode i.e., by observing the signals on Oscilloscope,
> CS goes LOW
> 32 Clock pulses
> CS Goes High
> CS Goes low
> again 32 clock pulses.
> CS goes low
again, I am reading data over SPI just using the MOSI and MISO pins. Clock and CS pins are for observation only.

Related

Where is the SPI multiplexer of my dreams?

Consider you have an SPI bus with only a single chip select.
Is there a chip such that I can connect 8 or more devices to that SPI bus?
To simplify things, you may assume that all devices agree on the SPI mode (data needs to be valid on a rising edge). Also, all devices are of the time, where chip selects stays low for the whole transfer, and is not toggled after each word.
The SPI multiplexer could have 4 inputs:
MISO, MOSI, input clock, master chip select
and 9 outputs:
output clock, 8 slave chip selects
MISO and MOSI are connected directly to the slaves. The slaves have their SPI clock connected to the output clock and their chips selects are connected to one of the 8 slave chip selects.
The SPI multiplexer would take the two bytes of each SPI transfer as its own input. The first byte could indicate which slave is to be selected. For configuration of the multiplexer, a ninth address could be allowed.
If one of the 8 slaves is selected, the multiplexer would then activate the slave's chip select after the first byte (or even after the first few bits of the first byte). The output clock would activate with the start of the second byte and it would be synchronous to the input clock. Leaving the clock inactive during the first byte makes sure that the slaves never take notice of the first byte.
Such a chip does not seem to exist. I found solutions with two chip selects, but that's not an option to upgrade old hardware designs with just a single chip select.
Does such a thing exist?
It does not exist because there is no need for it. Often CS is only controlled from software as a regular gpio before initiating an SPI transfer, then you could just wire the different slaves to different GPIO and use them as CS. If the CS is generated and needed by the hardware block you gate this signal with the external chip select to choose the wanted slave.
Your proposed one byte to select bus would also break all software which relay on writing from and reading to the same buffer, and it would be decrease the available bandwidth with control signals.
As a side note with recent development with secure enclaves and Trustzone the trend is not to share spi buses but rather hard wire them so only code running in the trusted part of the SoC will be able to access the connected slave.

When using the SPI protocol, is the output data rate synonymous with the baud rate?

I'm trying to learn how the SPI protocol works, and I'm working on a basic project using the STM32F407G-Discovery board.
This board has a built-in accelerometer (LIS3DSH), and it uses the SPI protocol. In the user manual, it states the following:
The LIS3DSH has ±2g/±4g/±6g/±8g/±16g dynamically selectable full-scale
and it is capable of measuring acceleration with an output data rate
of 3.125 Hz to 1.6 kHz.
This accelerometer is using SPI1, which is connected to APB2. I'm using STM32CubeMX to generate the initialization code (including the clock configuration), and it looks like the APB2 peripheral clock has a default value of 84 Mhz.
Does this mean that I need to configure the APB2 peripheral clock to have such a value that it falls between the range of 3.125 Hz and 1.6 kHz? I can't imagine this is true because I can't get the value low enough
in STM32CubeMX since it throws an error if I go too low.
I'm also accounting for the baud rate control SPI register, which allows you to go as low as f-PCLK/256.
In other words, I'm a bit stuck on which clock frequency to use and which baud rate control to use.
I'm still learning embedded programming, and so my terminology might be incorrect.
the two are not related. the max SPI clock rate is 10Mhz (page 14). The out rate of 3.125Hz to 1.6Khz is how fast the chip does an acceleration conversion. At 3.125Hz, a new conversion result is ready every 320ms, and at 1.6Khz, they are available every 625us. There is a trade off between conversion rates, power consumption and accuracy. The data sheet leaves a lot of holes, I would suggest reading the MMA7660 data sheet to get a better understanding of how these types of chips work and then revert back to your datasheet for implementation details.
You could use the SPI clock frequency with up to 10MHz to get data from this chip.
(So a prescaler of 16 and the full rate (84MHz) APB2 clock would be ok)
The SPI clock determines how fast the data is transferred from the chip to the controller not how fast the chip generated new results.
To always get the newest data you could use the IRQ lines from the chip or use an timer to trigger the transmission corresponding to sampling rate.

SD Card Shared SPI High Current Consumption

Hi I am using shared SPI Lines between External Flash and SD Card. For SD Card i use MSP430's SPI Engine, however for External Flash I am using same SPI Lines but as GPIO BitBanging.
The SD Card is a very rarely used and hence even the init functions are not called.
The issue:
I observed that if SD Card is inserted but never used, and External Flash is accessed, there is a sudden current increase (13mA) and does not reduce until SD card is removed. If SD card is not inserted there is no such issue.
The CHIP SELECT of the SD card is never touched and is always HIGH, yet the communication over FLASH is effecting the SD Card's sleep modes. According to Sandisk's datasheet the SD automatilly enters sleep mode.
Observations:
Ø Both SD and flash use common SPI lines, all 4 lines state is observed in both HIGH and LOW current states and observed no difference
**LINE HIGH Current Low Current**
Clock H H
D_Out H H
D_In H H
SD_CS H H
Ø **SD Card Removed**
Clock H H
D_Out H H
D_In H H
SD_CS H H
> Observed that changing the BitBanging to SPI ENGINE for both FLASH and SD card has no such current issues.
Checked the Line states if used in SPI Engine but found all signals as same.
Tried making all signals LOW when not in use but no difference.
Queries?
1. IF SD Card's Chip SELECT is HIGH (CS is active LOW) why is SD card not maintaining its SLEEP mode ?
Why both BitBanging and SPI Engine communications work without issue but effect current consumption in SD card though SD card is not communicated with ?
Limitations
I cannot use FLASH in SPI ENGINE mode and it is important for me to use only BitBanging.
The device is required to consume least power at all times and should work for 1 year on battery.
First, you need to mention the SD card,SPI FLASH and MSP part numbers (a pdf link is preferable) as the answer may lay in the documentation. Have you studied all the conditions that can take the SD card in and out of SLEEP?
There might be some register initialization required for the card to persist in sleep mode when there is activity on the SCLK line.
Second, find out the exact moment (instruction) on which the current spikes. Is it when SCLK goes high for the first time, or maybe when MOSI goes high?
Third, if possible, measure the current consumption of all 3 involed chips separatedly (MSP, SD, FLASH) to pinpoint who is generating this extra consumption.
Is the SD card powered while not in use? If it isn't, then it can feed through the I/O lines when they are high.
Mind sharing the reason for not using the SPI engine to communicate with the FLASH chip? And why share the pins? If you want the lowerest power consumption, bitbanging is NOT the way to go.

max voltage level for Rx and Tx:mbed lpc1768

I have an mbed board with LPC 1768. I want to receive serial data from a zigbee adapter which works on 5V. The voltage beween the Rx Tx pin and ground of the adapter is around 4.99 V. Is it safe to connect it directly to the mbed board Rx, Tx.
Most of the LPC1768 pins are 5V tolerant, so you can connect them to a 5V system without damaging the CPU.
To make sure that the pins in question are indeed 5V tolerant check the data-sheet: http://www.nxp.com/documents/data_sheet/LPC1769_68_67_66_65_64_63.pdf
All pins are listed in section 7.2. You may have to take a look at the mbed schematic to find out which CPU pins are used for your UART.
You also have to make sure that the 5V system will interpret the 3.3V output level of the LPC1768 as logic high levels. Most chips will work fine and interpret anything higher than 2.5V as logic high but there are some exceptions out there that need a higher level. Those won't be damaged but you won't be able to communicate with them without the help of a level-shifter.

When putting an SD/MMC card into SPI mode, can CS go high in between bytes?

I have a microprocessor with the card's chip select (CS) line tied to a 'frame' signal automatically driven by the SPI (SSP) circuit. This causes CS to go high between each byte.
The MMC/SD specs require that CS be held low in order to enter SPI mode. Does it need to be held low the entire time, or only when transmitting each byte of CMD0?
At the sdcard.org site, I found various PDF specifications for SDIO. None of these seem to have an explicit timing statement which clarifies this. However, this statement does occur:
(1) SD Bus mode is selected by CMD0 (Keep Pin 1 to high during CMD0 execution).
from page 88 of SD Host Controller Simplified Specification Version 2.00. ("Pin 1" is Chip Select (CS))
Given that sentence, an SD card manufacturer would be justified in requiring that you assert CS through the entire D0..D15 bits being sent. In other words, I think you cannot use the SPI frame signal and will need a GPIO pin or similar.