Skip to main content
Visitor II
August 5, 2024
Solved

STM32G4 using HAL Lib to read eeprom, when wirte to eeprom many times, the SYSTICK's tick variable will be changed randomly

  • August 5, 2024
  • 3 replies
  • 1969 views

hi,

for our project,we used firmware package was STM32CubeG4 Firmware Package V1.6.0 / 05-June-2024.

IDE: MDK 5.39

MCU: STM32G473MET6 EEPROM: 24LC256

we already check the page write opreation, ensure the boundaries and size of each write (less than or equal to the page size)

we have also tried DMA and IT, but they will affect SYSTICK

this our test code

 

uint32_t EEPROM_WriteBytes(uint16_t address, uint8_t *pData, uint16_t length)
{

while( (HAL_GetTick() -LastWriteTick) <=6);
LastWriteTick = HAL_GetTick();
if (HAL_I2C_Mem_Write(&hi2c4, _24LCXX_I2C_ADDRESS, address, I2C_MEMADD_SIZE_16BIT,
pData, length, HAL_MAX_DELAY) != HAL_OK)
{
return 0;
}

 

 

 

uint32_t EEPROM_ReadBytes(uint16_t address, uint8_t *pData, uint16_t length)
{
while( (HAL_GetTick() -LastWriteTick) <=6);
if (HAL_I2C_Mem_Read(&hi2c4, _24LCXX_I2C_ADDRESS, address, I2C_MEMADD_SIZE_16BIT,
pData, length, HAL_MAX_DELAY) != 0)
{
return 0;
}
return 1;
}

 

 

    This topic has been closed for replies.
    Best answer by Tesla DeLorean

    Really shouldn't jump around unless you're trashing the environment.

    With Keil make sure you've allocated an adequate STACK (see startup_stm32xyz.s) otherwise in will plough into the HEAP and STATICS/LOCALEs

    Watch your local/auto variable allocations and call-depth

    3 replies

    Super User
    August 5, 2024

    The systick code is dirt simple. You can inspect it. Unlikely to be bugs there.

    Why do you think it's getting changed randomly? What values do you see vs what values do you expect?

    mas666Author
    Visitor II
    August 5, 2024
    /**
     * @brief This function handles System tick timer.
     */
    void SysTick_Handler(void)
    {
     /* USER CODE BEGIN SysTick_IRQn 0 */
    
     /* USER CODE END SysTick_IRQn 0 */
     HAL_IncTick();
     /* USER CODE BEGIN SysTick_IRQn 1 */
    
     /* USER CODE END SysTick_IRQn 1 */
    }
    /**
     * @brief This function is called to increment a global variable "uwTick"
     * used as application time base.
     * @note In the default implementation, this variable is incremented each 1ms
     * in SysTick ISR.
     * @note This function is declared as __weak to be overwritten in case of other
     * implementations in user file.
     * @retval None
     */
    __weak void HAL_IncTick(void)
    {
     uwTick += uwTickFreq;
    }

    I know it's easy, that's why I'm confused. The variable 'uwTick' operated by the default code generated by CubeMX mentioned above, when I perform multiple eeprom writes, the value will randomly jump, but after writing, it will count normally.

    mas666_0-1722866341560.png

     

    The "uwTick" variable in the watch window will randomly change, such as suddenly resetting to zero, or suddenly becoming 0x20xxxxxx, or 0x80xxxxxx. However, after the write operation is completed, the variable will count normally based on the changed value

    Super User
    August 5, 2024

    Yeah that's a weird one.

    If uwTick is getting modified, you can set up a conditional breakpoint and see what instruction is causing the bad behavior. Possibly an out of bounds write.

    It could also be an IDE issue, maybe reading from the wrong address. Seems less likely. Consider sending uwTick out via UART or similar to eliminate that possibility.

    mas666Author
    Visitor II
    August 5, 2024

    Thank you for providing new troubleshooting directions. If there are any results, I will reply as soon as possible.

    Graduate II
    August 5, 2024

    Really shouldn't jump around unless you're trashing the environment.

    With Keil make sure you've allocated an adequate STACK (see startup_stm32xyz.s) otherwise in will plough into the HEAP and STATICS/LOCALEs

    Watch your local/auto variable allocations and call-depth

    mas666Author
    Visitor II
    August 6, 2024

    Thank you very much. The problem has been solved because the stack is too small