help debug corrupted memory location

[Anton_2]

Hi Folks,

I'm stuck with an intermittent error on an array value ( array[0]) , which is sometimes overwritten to value "0" instead of the necessary value.

I'm not able to find the source of this problem, is there any way to debug and intercept which instruction is actually overwriting this specific array location?

The array should be written at turn on, and then never modified.

Using standard debug, it seems the writing routine is never called after initialization, but after some time, array[0] is overwritten with "0"

MCU is STM32U595 and code is written on STM32Cube in C

No hardfault appears nor other unexpected behaviour, except for this array[0] value

Best Regards,

Anton

[Tesla DeLorean]

Well the debugger via DWT/FPB should be able to trap on specific accesses.

Is it other parts of the code? Can you add some guard zones at either end to monitor?

Can you monitor from the 1 ms / 1 KHz SysTick, and at least pin it down to some specific set of circumstances, or code execution. Can you add other instrumentation to check when it occurs or narrow it down to specific subroutines? Can you check the routine(s) that normally write to it?

Some errant pointer, or unrelated code?

If the arrays only written once, perhaps put it in an area that's protected by the CPU/MPU, so a subsequent write will Bus Fault?

[Anton_2]

Hi @Tesla DeLorean ,

thank you for your reply.

What I've already tried is to place some variables before and after the array, but the error still remained as before.

uint16_t blankSpaceBefore [24]; 
uint16_t FaultyArray [numberofpoints]; 
uint16_t blankSpaceAfter [24]; 

I have a standard STLink V2, code is written in STM32Cube with standard compiler.

Is this enough to use the "DWT/FPB" thing you mentioned? ( sorry I'm not a firmware engineer ) Where can I find some infos on how to do that?

In theory, no other parts of the code should have write instructions on that specific array.

I can check again of there is some potential writing to nearby variables with erratic pointer, but up to now I was not able find any.

Best regards,

Anton

[Anton_2]

Hi All, 

after some struggling, I think I've better pinpointed where the problem is located.

It was not in the Array I originally thought, but in a variable that it is used as alternative source of data, which again  after initial computation should be completely fixed throughout the life of the firmware.

So I have this DAC_EXT_idle uint16_t, and I managed to add watchpoint to that

Surprisingly enough, the breakpoint triggers at this instruction

      /* Clear injected group conversion flag */
      __HAL_ADC_CLEAR_FLAG(hadc, ADC_FLAG_JEOC | ADC_FLAG_JEOS);

which is located in the stm32u5xx_hal_adc.c file in the void HAL_ADC_IRQHandler(ADC_HandleTypeDef *hadc) function, and as far as I can understand, should be completely unrelated to variable DAC_EXT_idle , which is placed in a different file.

I'm wondering if this could be a debug issue?

Any hint would really be appreciated.

Best regards,

Anton

edit:

this is how watchpoint is set up, with or without range enabled I get the same breakpoint

more edit:

culprit probably found, debug correctly pointed the instruction AFTER the problematic one. It was an array writing under interrupt, but array index managed outside the interrupt.