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.
Related
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.
I have working C & Python3 code, based upon simple examples from the internet, where I can correctly send data from my Raspberry Pi4 to an Atmel SAM-E70 dev kit board. I've got a logic analyzer connected to look at the data being sent, and for every i2c_write_data_block() from my Python3 code, the smbus2 code sends the 7-bit address, followed by 0x00, followed by the byte stream that I want to send. My C code, sending the same byte streams, doesn't have the 0x00 between the address and the data. Finally, sending the byte stream using i2ctransfer() from the shell also works as expected: no extra byte.
Hypothetically, it could be that the smbus2 package is trying to use a 10-bit address, but I cannot find any documentation supporting this supposition. In fact, what I've found indicates that the I2C bus configuration is performed via config file(s) which would lead me to the believe that the language used to communicate on the I2C bus shouldn't matter - it would have the same configuration.
Has anyone else encountered this?
I noticed the same thing using the smbus2 i2c_write_data_block() function.
To avoid sending the 0x00 start byte, use the i2c_rdwr() function.
Example:
bus = SMBus(1)
address = 4
data = 'Some message'.encode()
msg = i2c_msg.write(address, data)
bus.i2c_rdwr(msg)
I'm experimenting with the STM32 nucleo board STM32F446.
uint8_t data[x];
HAL_UART_Receive_DMA(&huart2, &data, x);
This piece of code works when I send bytes to the PA3 and through DMA it writes to data the x bytes I sent.
However, when &data is replaced with 0x40020014 (GPIOA->ODR) or the bit-band aliased address 0x42400294 for PA5 LED, the bit for toggling the LED isn't set when I sent a byte to PA3, and HAL_UART_RxCpltCallback may or may not be called depending on x. Why?
Link to code: https://github.com/pterodragon/stm32_try/tree/question
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.