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!
Related
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.
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 am using a MAX5825 as an external DAC for RPi.
According to the datasheet, the resolution of this component is 12 bits.
As I read, I'm supposed to write the value I want to set in the CODEn (0x8n) register, n being the DAC channel I want to set, and then write anything in the LOADn (0x9n) register, or use the CODEn_LOADn (0xBn) register to do it in one step. See here the datasheet extract.
I'm using pigpio daemon library to interface I²C communication
void AnalogOutput::updateValue(int value) {
i2c_write_word_data(my_pi_device, my_handler, 0xB0, value << 4);
}
This is supposed to set my CODE0 register to the value parameter.
However, I had a strange behavior so I tried to read the data from CODEn (0x80) register to watch if my set attempt was correct.
i2c_read_word_data(my_pi_device, my_handler, 0x80);
I'm not sure I can read a value from a command register tho, but when my value exceed 0xFF, the return I get from I²C reading looks like value & 0xFF. (i.e. when I set the register to 0xFF I read 0xFF in the register, when I set the register to 0x100 I read 0x00)
Also, the output voltage of my DAC0 channel is at its maximum scale when CODEn register is set to 0xFF. I used 4.0V internal reference and when I set value to 0xFF, the output voltage is 4.0V-ish.
I don't understand why is 0xFF the maximum scale on a 12-bits resolution DAC ? Am I missing a way to configure the resolution or anything like that ?
What I've tried so far :
Remove the << 4 shifting on the set value : no change on the behavior
Invert the LSByte and MSByte written to the CODEn register (I've seen
on pigpiod API SMBus standard was supposed to send LSByte then MSByte
in a word writing procedure) : the reading of CODEn register was
jumping over 0x0FFF value. MAX5825 is supposed to be compatible with
SMBus standard tho.
Use i2c_write_block_data instead of
i2c_write_word_data function of pigpiod lib : no change on the
behavior.
Thanks for your time !
References :
MAX5825 datasheet : https://datasheets.maximintegrated.com/en/ds/MAX5823-MAX5825.pdf
pigpio API : https://abyz.me.uk/rpi/pigpio/pdif2.html
Ok I got it fixed using i2cget & i2cset, my supposition about LSByte & MSByte was right.
CODEn registers are filled with 12 MSB. That means a set value of 0x0ABC needs to be stored in CODEn register by : 0xABC0. pigpio following SMBus standard send I²C word message with LSByte first and then MSByte, so if I send 0x0ABC message through I²C it will actually send 0xBC0A. When I tried to invert LSByte and MSByte, I was sending through I²C the message 0xBC0A so what was stored inside MAX5825 was 0x0AB.
One functionnal workaround would be :
void AnalogOutput::updateValue(int value) {
int codeRegisterData = (value >> 4) + ((value & 0xF)<<12);
i2c_write_word_data(my_pi_device, my_handler, 0xB0, codeRegisterData);
}
If value = 0x0ABC, codeRegisterData would be = 0xC0AB so pigpio will write over the I²C bus into the CODEn register the message 0xABC0.
Am trying to initialize the NRF24L01+ registers using SPI but they always return 0x00.
According to the datasheet, Table 20 on page 51, all write commands will have a pattern of b001x xxxx, which i understood as having a 0x2x pattern.
In my snapshot below, i send the register value, for example register 0x00 will be sent as 0x20 indicating a write command to that register and then i send the value to be written on that register.
As you see on the MISO line, the value is 0x00 even when am trying to write a 0x08 which should be the default value according to page 57 of the datasheet.
I still dont know why its returning 0x00 even when i independently try to read the contents of that register later on without writing to it. I still get 0x00. The same applies to all other registers that am trying to re-init.
Anyone who has experienced this behaviour elsewhere or is it me that is having something wrong?
The NRF24 am trying to program here is this type from sparkfun
You are close. The datasheet shows write register as 001A AAAA and read as 000A AAAA, where the 5 A's represent the register you want to write to. The spec states that while the command is being sent (read, write, read payload, write payload, flush, activate, and so on), the device will return the status register. In your data, the device is responding with 0x0E, which is correct; decoded is is saying no errors and no data received or pending to transmit. If you want to see if the command you send was accepted, you need to first write the data and then read the data. For example, let's say we want to write the config register to enable the device as a receiver, 2 byte CRC with Rx interrupts enabled.
First, you would send 0b00100000 (0x20), 0b00111111 (0x3F). The device will respond with 0b00001110 (0x0e), 0b00000000 (0x00). This is what you are seeing. If you want to verify the configuration register, you need to then send 0b00000000 (0x00),which is the command to read the config register, then 0b00000000 (0x00), which is a dummy byte to clock out the data. The device will respond with 0x0e, which is the status, and then 0x3F assuming you configured as I did above.
Note that there are more commands than just reading and writing the registers, there are specific commands to fill and read the pipeline data.
Hope this helps.
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.