I2C Slave - clock stretching disables communication and other problems (STM32L0)

[TDJ]

I try to implement I2C slave so it behaves like a typical EPROM and master can read/write using HAL_I2C_Mem_Read/HAL_I2C_Mem_Write functions.

After 3 days of searching and trying I found only one, partially working example: STM32F072 I2C slave Receive callback

Problems:

1. Communication seems to work only when clock stretching is disabled (Clock No Stretch Mode = Enable/I2C_NOSTRETCH_ENABLE). Enabling clock stretching causes slave to pull SCL line down indefinitely once it receives its address.
2. Description of I2C_XFEROPTIONS (I2C_FIRST_FRAME, I2C_NEXT_FRAME, I2C_LAST_FRAME) found in UM1940 is completely cryptic and no description in HAL source code is found.
3. I am able to receive data but not to send. I receive odd address, call HAL_I2C_Slave_Seq_Transmit_IT(hi2c, &_dataBuffer[_offset], 1, I2C_NEXT_FRAME) and that results in HAL_I2C_ERROR_OVR error.

I read many posts discouraging use of HAL functions for slave implementation but I hoped the functionality has been improved recent years and maybe now it is usable.

I use the latest STM32Cube_FW_L0_V1.12.1, functions calls in interrupt mode (*_IT) and STM32L041.

I am familiar with the I2C_TwoBoards_RestartAdvComIT example. It does provide some insight but it does not address the above two problems. This example is provided for Nucleo-L073RZ only, which may or may not indicate that tests with other L0 Nucleos were not successful. Moreover, HAL_I2C_EnableListen_IT() is called in the loop which indicates author(s) of this example could not find a better yet reliable solution.

Please advise.

[TDJ]

@Piranha​ I do not see all those issues as a result of insufficient competency. I think it is rather insufficient/ineffective corporate sponsorship/support.

That results, for instance, in the lack of effective feedback channels. These days all open-source vendors try to engage community in software improvement process, e.g. encourage pull request. ST does not do anything like that. Even this forum uses rather old interface, no MarkDown, login requires password every time because "Remember me on this computer." option is broken since I remember. It speaks for itself. Basically, this program has shocking low corporate priority.

Two months ago I asked for help via support channel. Case has been opened. I asked to at least confirm Reference Manual is correct because probably it is not. No answer so far. Much different experience than with Texas Instruments. I like ST products but I find myself more and more often checking on alternatives.

[Amel NASRI]

Hi @TJast​ ,

I want just to comment on "These days all open-source vendors try to engage community in software improvement process, e.g. encourage pull request. ST does not do anything like that."

ST is publishing STM32Cube firmware packages in Github since a while.

All ST Customers and STM32 users can submit issues or add pull requests as explained in CONTRIBUTING.md.

-Amel

[TDJ]

@Amel NASRI​ The key concept here is to engage, make it work. It does not happen by just publishing stuff. "STM32Cube_MCU_Overall_Offer" repo has 4 (four) contributors, two pull requests, four registered issues total, zero releases, zero packages.

I do not think the goals of publishing HAL on Github have been achieved, do not you agree?

The name of the repo does not even make it possible to find it, if someone looks for STM32 HAL. Try it yourself.

[Amel NASRI]

For this feedback regarding Github, I add @ALABB​  to this discussion.

At package level, you can see that goal is achieved.

Select for example STM32CubeL4, you will find there 2 dedicated pull requests & 11 issues managed by the team engaged to provide required support there.

May be the name of the repository is not so significant (from your point of view), but this is the main page gathering all Cube firmware components for all families. So you need to select relevant component each time.

Thanks again for sharing your thoughts and giving me the opportunity to enlighten more about Github repository.

-Amel

[ALABSTM]

Hi,

Thank you @TJast​ for your feedback and thank you  @Amel NASRI​ for the details about our offer on GitHub. Indeed, the STM32Cube_MCU_Overall_Offer repository on the STMicroelectronics organization is the entry point for the STM32 MCU offer on GitHub. There, you can find a list of different repositories, from those containing whole firmware per series (e.g., STM32CubeL4, as mentioned above) to those containing particular components like CMSIS or HAL-LL (e.g., stm32l4xx_hal_driver). Each set of repositories addresses particular needs of our users and customers.

Hence, the STM32Cube_MCU_Overall_Offer repository is not intended to submit issues and pull-requests. In your case, you could have submitted your issue on the STM32CubeL0 repository, for instance. Now, since you submitted it to the ST Community, it is fine too, as both support channels are complementary.

Please note also that issues and pull-requests submitted via the GitHub channel are limited to the software published within each repository (criterium that your issue fulfills).

Other topics related to the hardware, the ecosystem, or the documentation (e.g., the reference manual), or any support request (help to port an existing application or to develop your own) shall be submitted to this community, whose scope is broader than the GitHub support channel's.

I hope this helps.

With regards,

[TDJ]

@ALABB​ In my view, the fundamental problem here is the "Community" does not have sufficient expertise to support such sophisticated technology as ST MCUs. This approach, apart from the mediocre implementation, is just ineffective. The believe that Community of your product users will ever be able to effectively support itself with just some ST moderation is based on false premises. Essentially, the believe is that top, non-ST embedded engineers will spend their non-billable time supporting your customers in exchange for virtual points and badges to feel good about themselves. Such believe is naive, at best. What I often observe is quite opposite - top engineers I know tend not to reveal the secrets of their craftsmanship, even we work for the same company. That's because they had to learn so hard.

Look, so far four ST employee commented on this very topic, no one provided meaningful help. That's the proof, right here.

Obvious and serious bugs in Cube MX I pointed out several months ago are not fixed. Support case I opened spring 2021 (00129564) has just been closed without any attempt to help.

Frankly, in my already long technical life I rarely experience tech support of equal inefficiency.

[S.Ma]

Would having an emulated I2C slave RAM stm32 example help? With the example telling the relation between max non clock stretch bit rate vs core speed and max interrupt latency?