cancel
Showing results for 
Search instead for 
Did you mean: 

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

mas666
Associate II

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;
}

 

 

1 ACCEPTED SOLUTION

Accepted Solutions

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

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

View solution in original post

7 REPLIES 7
TDK
Guru

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?

If you feel a post has answered your question, please click "Accept as Solution".
mas666
Associate II
/**
  * @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

TDK
Guru

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.

If you feel a post has answered your question, please click "Accept as Solution".
mas666
Associate II

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

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

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

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

mas666
Associate II

Thanks. The problem has been solved