I know that SandDisk Micro SD cards have bad block detection and re-mapping capability. The default mode for an SD card is the 4 bit SD interface. When using the SPI interface does anyone know if the SD card will still do this automatic bad block detection and re-mapping? Based on my reading the SanDisk OEM Product Manual
"The SPI Mode is a secondary communication protocol for cards in the SanDisk
microSD Card Product Family. This mode is a subset of the SD Protocol, designed to
communicate with an SPI channel, commonly found in Motorola and other vendors'
microcontrollers. Detailed information about SPI Mode can be found in Section 7 or
the SDA Physical Layer Specification, Version 3.01."
This does not seem to clarify my doubt. Does anyone know the answer?
Using a different interface with the card should not prevent the card from doing its internal wear leveling and bad block management as the commands do not change, only the physical link.
From section 7.1 of the Physical Layer Simplified Specification Version 4.10
The SPI standard defines the physical link only, and not the complete data transfer protocol.
https://www.sdcard.org/downloads/pls/part1_410.pdf
Related
I have already posted this question on the raspberry forum but I only got a few answers that didn't solve my problem... I have been waiting for a month so I turn to this forum hoping to be able to find a solution there...
PS : do not hesitate to check my post on RPI forum to see my progress and my research/tests carried out (https://forums.raspberrypi.com/viewtopic.php?t=335338)
So here is my problem :
I have been looking for a while how to write to an external microSD card in SPI mode...
My goal is to write data collected by a sensor an store them on various microSD cards (6) by using CS. But at this point, I'm tring to write data on one card.
I'm using a RPI Zero 2W, a simple microSD card module and an 512GB microSD card (with exFAT filesystem).
I saw that there was a "mmc_spi" driver included in a linux kernel which allows to detect an SD card connected by SPI as if it were a USB key to which we could simply access/read/write (https://ralimtek.com/posts/2016/2016-12-10-raspberry_pi_secondary_sd_card/)
the problem is that this tutorial is not working anymore... In fact, the linux Kernel used in the tuto is an old one compare to the current version and and I had confirmation that the "mmc_spi" driver used to detect the SD card had evolved but the use of this new version is not documented and obviously does not work like the old one...
So my question is : does the mmc_spi driver still allows to detect SD cards and access them and if yes, does it works with the PI zero 2W ?
I want to send data through USB between STM32 and Raspberry Pi. I don't want to use USB to Serial convertor, but instead have a actual USB Connection (maybe CDC class). I have to send data at high rate (Full speed). Please guide on how to achieve this?
A USB-serial connector is simply a microcontroller implementing a USB CDC/ACM virtual COM port and bridging to a UART which you would connect to a microcontroller's UART interface.
In your case you can simply implement the CDC/ACM directly on the STM32 using either of its USB device controller peripherals (USB support varies depending on the specific device https://www.st.com/resource/en/application_note/dm00296349-usb-hardware-and-pcb-guidelines-using-stm32-mcus-stmicroelectronics.pdf).
How you actually implement that will depend on what specific part, and what library or framework ecosystem you are using (e.g. SPL, CubeMX, Mbed). There are reference implementations, examples, drivers and libraries for all of these.
Your milage may vary, but I have measured ST's own USB library and example CDC/ACM virtual COM for STM32F1xx on a 72MHz MCU achieving 700kbits/s. Note that the performance is independent of the baud rate you might set on the host when you open the he VCP. Setting the baud rate simply sends a control packet to the device that can be used to set the baud rate of a UART in bridging applications. In your case such control packets can be ignored. There are similar packets for modem control signals such as DTR, RTS, CTS and RI, which you might choose to us for flow control or other signalling.
I have STM32F407 Boards like STM32F407 Disco board (without TFT) and some basic Chinese Boards. I have interfaced my TFT LCD with the board using FSMC interface and done basics like text, graphic shapes and images. So the driver is in place I think.
Now I want to introduce Touchgfx to make my GUI lively. But as far as I understand STM32F407 needs external RAM and ROM to store images and full frame buffer to be used by touchgfx to be more effective. Also FreeRTOS and my application code also needs to be added.
So which are the possible ROM and RAM chip options I can use for this purpose. BGA type RAM or high pin count ICS are not practical my case.
Please suggest.
Thank you
I am building a board based on the STM32F303RET6.
The Processor Datasheet, page 17/section 3.5, mentions programming can be done "using USART1 (PA9/PA10), USART2 (PA2/PA3) or USB (PA11/PA12) through DFU (device firmware upgrade)"
I am using a NUCLEO board with this processor.
I have connected the Vdd, Gnd, D+ and D- pins of USB to a NUCLEO board and disabled the power from the add-on programmer board.
However whenever I reboot it with BOOT0 HIGH the USB never enumerates any device.
I am connecting the pins directly to the USB plug without any external resistor. The datasheet seems to suggest these are not needed.
To make things a bit trickier, this processor has the additional particularity of not having a BOOT1 pin; it is a software bit.
My question is, does the processor actually support DFU by using the built in bootloader?
If so, how should one go about starting it and programming via USB?
Thank you very much,
Pedro.
PS: ST has actually got conflicting information about support for USB programming on this processor. While the Datasheet says it's supported, Application Note AN2606, page 81 (section 19) only mentions support for programming via USART1, USART 2 and I2C. It references the USARTs but it's unclear how they can be used.
I have connected the Vdd, Gnd, D+ and D- pins of USB to a NUCLEO board
and disabled the power from the add-on programmer board.
Check the actual voltage and current on Vdd. The host might limit the current, or shut the port down when the consumption exceeds 100mA before enumeration. Try it with an external power supply.
I am connecting the pins directly to the USB plug without any external
resistor.
You need an 1.5k pullup on D+ (full speed) or D- (low speed). This is from the STM32F3 Discovery schematics (that's an OTG socket, ignore the ID line for regular 4-wire ports)
When there is no pullup, the host can't detect when the device is plugged in, and therefore won't enumerate it.
ST has actually got conflicting information about support for USB programming on this processor. While the Datasheet says it's supported, Application Note AN2606, page 81 (section 19) only mentions support for programming via USART1, USART 2 and I2C.
There is no conflicting information there. Section 19 on page 81 refers to some other controllers.
The capabilities of your STM32F303RET6 are listed in table 36, section 18.1 on page 77. (As I've already pointed it out.) See also table 3 on page 23, line STM32F302xD(E)/303xD(E).
I have a NIC card and a HDD both connected on PCIe slots in a Linux machine. Ideally, I'd like to funnel incoming packets to the HDD without involving the CPU, or involving it minimally. Is it possible to set up direct communication along the PCI bus like that? Does anyone have pointers as to what to read up on to get started on a project like this?
Thanks all.
Not sure if you are asking about PCI or PCIe. You used both terms, and the answer is different for each.
If you are talking about a legacy PCI bus: The answer is "yes". Board to board DMA is doable. Video capture boards may DMA video frames directly into your graphics card memory for example.
In your example, the video card could DMA directly to a storage device. However, the data would be quite "raw". Your NIC would have no concept of a filesystem for example. You also need to make sure you can program the NIC's DMA engine to sit within the confines of your SATA controller's registers. You don't want to walk off the end of the BAR!
If you are talking about a modern PCIe bus: The answer is "typically no, but it depends". Peer-to-peer bus transactions are a funny thing in the PCI Express Spec. Root complex devices are not required to support it.
In my testing, peer-to-peer DMA will work, if your devices are behind a PCIe switch (not directly plugged into the motherboard). However, if your devices are connected directly to the chipset (Root Complex), peer-to-peer DMA will not work, except in some special cases. The most notable special case would be the video capture example I mentioned earlier. The special cases are mentioned in the chipset datasheets.
We have tested the peer-to-peer PCIe DMA with a few different Intel and AMD chipsets and found consistent behavior. Have not tested the most recent generations of chipsets though. (We have discussed the lack of peer-to-peer PCIe DMA support with Intel, not sure if our feedback has had any impact on their Engineering dept.)
Assuming that both the NIC card and the HDD are End Points (or Legacy Endpoints) you cannot funnel traffic without involving the Root Complex (CPU).
PCIe, unlike PCI or PCI-X, is not a bus but a link, thus any transaction from an Endpoint device (say the NIC) would have to travel through the Root Complex (CPU) in order to get to another branch (HDD).