I'm using an STM32F0Discovery to try and intialize SD Cards via bare metal programming. I have 3 cards that I'm working with. A Kingston 32GB Sd card, SanDisk Ultra 32GB sd card, and a Transcend 1GB sd card. Right now, only the Transcend SD card can get past CMD0. The other two SDHC cards return 0xff.
Do SD and SDHC differ someway?
Anyone know why my code would work for an SD card and not an SDHC card?
The spi clock speed is set to 375kHz which is in the 100-400kHz range.
Intialization steps
I start by setting the CS line high and sending 0xff 20 times (overkill ik).
Set CS low, and send CMD0, wait 100ms, then check for response 1.
My send CMD function involves first sending a 0xff then the cmd|0x40, and then the cmd argument then teh crc.
For CMD 0 this is (cmd|0x40), the argument 1 byte at a time, then the (crc|0x01) which is 0x95|0x01.
Response1 invoves sending 0xff 8 times or untill 0x01 is returned, whichever comes first.
the whole cmd0 r1 code is in a do while loop, waiting until R1 returns 0x01. cslow, cmd0, r1, cshigh
After sending CMD0 and checking for Response 1. For my 1gb SD card i get an 0x01 response, but form my two SDHC cards I get an 0xff.
I tried looking it up, but it seems like most people are able to get past CMD0.
I saw This response to a similar issue, where someone mentioned when writing a command, send 0xff untill you get 0xff, but it didn't work. I also saw one mentioning that when an SD card has been initialized that cmd0 won't return 0x01. I've been in debug mode so I would start the program, remove the sd card and put it back in and then go through the process.
I have a break point after response1
I'm quite lost on what to try and do.
Related
i want to write in AT24C512 with stm32f103c8 i send my code.
HAL_I2C_Mem_Write(&hi2c1, 0XA0, 0X11FA,I2C_MEMADD_SIZE_16BIT , &write_data, 1, 100);
For example, I want to put the value of write_data on 0x11FA, and I specify the memory address as 16 bits, but it is always sent as 8 bits, and AT24C512 seems to receive only the first byte of 0x11FA It means AT24C512 receive just 0x11 and its not difference if i set mt address register to 0x1167 0x11FF 0x11A0 all these address is same for AT24C512.
what should I do?
Because I used the module, I am sure the hardware have no problem
i want to write and read correctly in AT24C512 with stm32f103c8.
I'm using AT24C512 EEPROM which is 512KB along with my STM32
I'm able to write 128bytes of data at once using
HAL_I2C_Mem_Write(&_EEPROM24XX_I2C,0xa0,Address,I2C_MEMADD_SIZE_16BIT,(uint8_t*)data,size_of_data,100)
but the issue is that i want to write more data after the data that was just wrote, but the EEPROM will replace the data as the Address is the same
so how can i skip the written address ?
This answer is not about using HAL with I2C, but hope it will point you
Just check datasheet (I looking into STM32F0) and you can see that the limit is 255 bytes (register CR2:NBYTES), I'm not sure if there is another limitation in HAL, but using direct access to registers you can sent 255 bytes at once or fragment it and sent how much you want.
For fragmenting there is bit CR2:RELOAD, if you set this, then at the end will be not transfer stopped, and you can update next NBYTES, .. when you will set last block of bytes (which will fit into NBYTES) then clear bit CR2:RELOAD.
This has one disadvantage, that every 255 bytes, you will be interrupted.
i think you should check the AT24C512 datasheet page 7.
If more
than 128 data words are transmitted to the EEPROM, the
data word address will
“
roll over
”
and previous data will be
overwritten. The address
“
roll over
”
during write is from the
last byte of the current page to the first byte of the same
page.
I have multiple 512MB SDSC cards that seem to block after getting a read single block command. I get back the expected data which I wrote before, but the card seems to stop returning anything but 0xFF afterwards. Even simple commands like CMD13 (request status) do not send back anything but 0xFF. While these commands did return normal before the read command was used.
The entire code does work with another SDHC card. Attempting reinitialization does not work until the card has had its power removed. I am using SPI mode.
I am running out of ideas what the issue might be.
The addressing scheme for SDHC and SDSC is slightly different: SDHC requires SECTOR id while SDSC needs BYTE address. Maybe that's the case with CMD17.
I have two xbee's series 1. I have them as endpoint devices working in API mode and talking to each other. The first xbee is attached at a raspberry pi, while the other is on my pc where I see the terminal tab of XCTU program. The baud rate I use is 125000.
From raspberry pi I try to send a jpg image which is 30Kbytes. I send data frames 100 byte long (the biggest as it is said in the xbee documentation). Inside a loop I create and send the packets, I have also a cout statement that prints the loop number. Everything is fine and all bytes are sent. When I comment out the cout statement not all bytes are sent.
From what I have understood the cout statement works as a delay between packets, but I still cannot understand why is this happening as it is supposed that I use the half speed ...
I hope I was clear and look forward for a reply.
UPDATE
Just to summarize, i changed baud rate to 250000 where there is the same behavior as in 125000. I also implemented hardware flow control by checking cts signal. When xbees are in transparent mode I need a delay between sending characters at around 150us. The same goes for api mode too. The difference with 125000 baud rate in api mode was that the delay needed, was enough to be betwween each data packet, but in 250000 the delay is needed between each byte that i send. If i do the above everything goes well.
The next thing i did was to plug both xbees in my pc in transparent mode. I went to terminal tab of xctu software where i chose assemble packet and sent at around 3000 bytes to the other xbee. The result was the same. The second xbee received at about 1500 bytes and then each time that i was sending one byte from the first to the second, the "lost bytes" were being received at packets of 1000. :/
So could anyone know what am I doing wrong?
You should connect the /CTS pin from the XBee module into the Raspberry Pi, and have your routine stop sending data when the XBee de-asserts it.
At higher baud rates, it's possible to stream data into the XBee module faster than it can send to the remote module. The local XBee module uses the /CTS pin to notify the host when its buffers are almost full and the host should stop sending. People refer to this as hardware flow control.
It may be necessary to modify the serial driver on the Raspberry Pi to make use of that signal -- it should pause the transmit buffer when de-asserted, and automatically resume sending when re-asserted.
I'm working on an embedded system that currently only supports SDSC v1 cards. As it's getting harder and harder to find cards less than 2 GB, I'm trying to add support for SDHC cards. The communication with the card is done via the SPI bus.
So here is what I'm doing to initialise the card:
Send CMD0. Card returns 0x1
Send CMD8 + 0x1AA. Card returns 0x1 and 0x1AA
Send ACMD41. Card returns 0x0.
Afterwards, I read the MBR and figured out that there is a FAT16 partition at 0x30 LBA. However, reading a sector from that address (0x30*512) returns a repetition of 0x01 0x09...
When sending ACMD41, I'm sending command id 0x69. Is it correct? Or should I send CMD55 and then CMD1?
A diagram 1 shows that I need to send CMD58 and possibly CMD16 after sending ACMD41. Is it necessary? I was able to read a valid MBR without doing them.
1. http://elm-chan.org/docs/mmc/mmc_e.html
"ACMD" commands all require a CMD55 followed by the relevant command.
For example, for command ACMD41:
SD_command(55, 0, 0, 0, 0, 0xFF);
n= SD_command(41, SD2<<6 , 0, 0, 0, 0xFF);
Don't forget to OR in 0b01000000 to the first argument. The actual command isn't 55, it's 55|0b01000000 (0b01110111, decimal 119). I do it in the SD_command function itself.
Interfacing to SD cards is a HUUUUUGE pain, so don't give up. Good luck!