Closed elsalahy closed 3 years ago
@azerimaker as per our discussion, I opened this issue so we can share info on behavior
Also here is another test case scenario where I switch pins assignment as seen in the code below to try to pinpoint the issue.
Test scenario: I changed the Pins assignment in STNODE_bsp.h as seen below
#define SENSOR_I2C1 I2C2
#define SENSOR_I2C1_TIMING 0x00707CBBU //Evaluates to 10 KHz bus frequency
#define SENSOR_I2C1_TIMOUT 100U //Read and write operattions timeout in ms
#define SENSOR_I2C1_PERIPH_CLK RCC_PERIPHCLK_I2C2
#define SENSOR_I2C1_SOURCE_CLK RCC_I2C2CLKSOURCE_SYSCLK
#define SENSOR_I2C1_CLK_ENABLE() __HAL_RCC_I2C2_CLK_ENABLE()
#define SENSOR_I2C1_CLK_DISABLE() __HAL_RCC_I2C2_CLK_DISABLE()
#define SENSOR_I2C1_SDA_GPIO_CLK_ENABLE() __HAL_RCC_GPIOA_CLK_ENABLE()
#define SENSOR_I2C1_SCL_GPIO_CLK_ENABLE() __HAL_RCC_GPIOA_CLK_ENABLE()
#define SENSOR_I2C1_FORCE_RESET() __HAL_RCC_I2C2_FORCE_RESET()
#define SENSOR_I2C1_RELEASE_RESET() __HAL_RCC_I2C2_RELEASE_RESET()
#define SENSOR_I2C1_SCL_PIN GPIO_PIN_12
#define SENSOR_I2C1_SCL_GPIO_PORT GPIOA
#define SENSOR_I2C1_SDA_PIN GPIO_PIN_11
#define SENSOR_I2C1_SDA_GPIO_PORT GPIOA
#define SENSOR_I2C1_SCL_SDA_AF GPIO_AF4_I2C2
#define SEC_ELM_I2C2 I2C1
#define SEC_ELM_I2C2_TIMING 0x00707CBBU //Evaluates to 10 KHz bus frequency
#define SEC_ELM_I2C2_TIMOUT 100U //Read and write operattions timeout in ms
#define SEC_ELM_I2C2_PERIPH_CLK RCC_PERIPHCLK_I2C1
#define SEC_ELM_I2C2_SOURCE_CLK RCC_I2C1CLKSOURCE_SYSCLK
#define SEC_ELM_I2C2_CLK_ENABLE() __HAL_RCC_I2C1_CLK_ENABLE()
#define SEC_ELM_I2C2_CLK_DISABLE() __HAL_RCC_I2C1_CLK_DISABLE()
#define SEC_ELM_I2C2_SDA_GPIO_CLK_ENABLE() __HAL_RCC_GPIOA_CLK_ENABLE()
#define SEC_ELM_I2C2_SCL_GPIO_CLK_ENABLE() __HAL_RCC_GPIOA_CLK_ENABLE()
#define SEC_ELM_I2C2_FORCE_RESET() __HAL_RCC_I2C1_FORCE_RESET()
#define SEC_ELM_I2C2_RELEASE_RESET() __HAL_RCC_I2C1_RELEASE_RESET()
#define SEC_ELM_I2C2_SCL_PIN GPIO_PIN_9
#define SEC_ELM_I2C2_SCL_GPIO_PORT GPIOA
#define SEC_ELM_I2C2_SDA_PIN GPIO_PIN_10
#define SEC_ELM_I2C2_SDA_GPIO_PORT GPIOA
#define SEC_ELM_I2C2_SCL_SDA_AF GPIO_AF4_I2C1
and I get this log
This is only for testing purposes and it shows that when I2C2 bus is being used with UART printing the device halts.
If this is a HW issue, it would be due to shortening of the I2C2 bus and the node UART Tx If it's a SW issue, it will be mainly because of ST HAL drivers
Also it is good to keep in mind that I tested the following scenarios 1) Removed all UART prints and the device functions as expected 2) Increased stack and heap sizes and the problem still occurs
Thanks @elsalahy for a detailed FW review. Since I2C1 works properly, I suspect crosstalk is the culprit here. Here's the screenshot of the lower layer, as we can see there's a section of about 13mm, where these lines run alongside each other and it might be the reason for such behavior. One way for fix this is to decrease the pull-up resistor values (currently 4.7K Ohm). I'll play with smaller values and get back to you.
Lowered the pull-up resistors to 1.8K Ohm (don't mind the through-hole resistors :sweat_smile: ), still the same behavior.
Sorry I had to:
Summary:
The device (V0.1) halts when we are transmitting data via UART and I2C2.
Steps to Reproduce:
What do you see now?
System halt due to a SW or HW issue.
What do you want to see instead?
System functions without any halt.
How do you propose to implement this?
Identify if it is a HW issue, or a SW issue. In case it is a HW issue, we will need to adjust the schematics of V0.2 design In case it is a SW issue, we will need to fix the driver causing the issue
Environment:
Baremetal
What can you do yourself and what do you need help with?
All