cancel
Showing results for 
Search instead for 
Did you mean: 

RM error: I2C Transfer figure wrong (RELOAD bit)

flyer31
Senior

Hi,

in RM STM32G4 (I use Rev. 7, page 1882, Figure 648 "Transfer sequence flow for I2C master transmitter for N>255bytes":

The "RELOAD=0" info in last box at "N<256" is wrong.

It must instead say RELOAD=1, AUTOEND=1 (otherwise Stop bit will fire immediately, and the last N bytes will NOT be sent...).

(My application case is DMA tx transfer (I used 1031 bytes in total), NO I2C-restart... .)

With this change then (RELOAD=1, AUTOEND=1, NBYTES= Nlast) it works perfect... .

1 ACCEPTED SOLUTION

Accepted Solutions

Sorry, I just recognized a flaw in my I2C init function... .

I enforce there "CR1_NOSTRETCH" - also if I initialize as Master.

But RM in register description of I2C_CR1 (41.7.1) clearly says for NOSTRETCH: "It must be kept cleared in master mode"... .

And ta ta ... after this (with NOSTRETCH=0 in CR1), it also works if RELOAD=0 (it also works if RELOAD=1 for the last block ... but this then is no error any more... please excuse this wrong error message of me.. ...).

View solution in original post

4 REPLIES 4
Piranha
Chief II

> RELOAD=1 ... otherwise Stop bit will fire immediately, and the last N bytes will NOT be sent

From where did you got such a conclusion? It does not make a sense logically. And the actual code implemented according to the documentation works as expected. Not only the HAL code, but I looked at my driver for L4 and F7 series - the same thing.

flyer31
Senior

Hi Piranha,

I have written a small test application with 2 own boards,

... but based on STM standard example STM32Cube_FW_G4_V1.4.0\Projects\NUCLEO-G474RE\Examples_LL\I2C\I2C_TwoBoards_MasterTx_SlaveRx_DMA_Init

... just I stripped HAL - I use my own "Abstration Layer" (which is not as "abstract" as HAL 🙂 - I acknowledge the HAL is for sure nice and useful for STM to produce its very important multitude of demo software for any controller, but I must admit that I do not like it very much (I love the STM32 register initialization scheme and description, it is very clear somehow...)...).

... but if you use this example with 2 Nucleo 474 boards (if you have them, somehow difficult to get them in the last year...), you should see it if you would enlarge the transfer buffer aLedOn to a larger value, e. g. use my length of 1031, fill it with zeroes, and put the bytes 1, 3, 7, 0xF at the positions 250, 500, 750, 1000, then you should see it easily and fast with a basic oscilloscope... . Just of course you have to adapt the code a bit to poll the TCR bit fast to do the reload correctly (or use an interrupt programming .. I used while-loop-polling of TCR for simplicity in my first basic example .. in a final larger system of course you would use TCR interrupt, this I am just programing... ).

(as I do not like HAL very much, I would not like to try such adaption in HAL... but if you do it and it schould realy work in your program with RELOAD=0 for the last buffer, I would be stunned... then I will try it also, I have two Nucleo474 boards here, but I bet 100% against it...).

Sorry, I just recognized a flaw in my I2C init function... .

I enforce there "CR1_NOSTRETCH" - also if I initialize as Master.

But RM in register description of I2C_CR1 (41.7.1) clearly says for NOSTRETCH: "It must be kept cleared in master mode"... .

And ta ta ... after this (with NOSTRETCH=0 in CR1), it also works if RELOAD=0 (it also works if RELOAD=1 for the last block ... but this then is no error any more... please excuse this wrong error message of me.. ...).

HAL is a broken bloatware and for a high level library it doesn't provide many features it should. For example, it cannot even do USART sanely...