Can't enter into debug mode after writing to the STM32L073 EEPROM memory; mass erase solves it.

[XR.1]

Hi,

I'm using the internal EEPROM bank 0 for the STM32L073 chip located at 0x08080000 (as per the user manual).

After writing my data (less than 1K; and bank 0 has 3K capacity) and trying to enter into debug mode, system refuses to do so:

(BTW: such log file isn't created: tmp/STM...log)

In order to bring the chip back from this brick mode I need to apply a mass erase operation using the STM32CubeProgrammer:

And then I can enter into the debug mode again:

The code for writing into the EEPROM is:

#define EEPROM_BASE_ADDR 0x08080000

      bool write_( uint16_t data_address, const uint8_t* buffer, uint16_t len )
      {
         HAL_StatusTypeDef ret_val = HAL_OK;

         HAL_FLASHEx_DATAEEPROM_Unlock();

         for( uint16_t i = 0; i < len and ret_val == HAL_OK; ++buffer, ++i )
         {
            ret_val = HAL_FLASHEx_DATAEEPROM_Program( 
                  FLASH_TYPEPROGRAMDATA_BYTE, 
                  (uint32_t)(EEPROM_BASE_ADDR + data_address + i),
                  static_cast<uint32_t>(*buffer) );
         }

         HAL_FLASHEx_DATAEEPROM_Lock();

         return ret_val == HAL_OK;
      }

Data seems to be written correctly at the specified address offset (`data_address`, which is zero ). I can see it (through the RAM memory debug pane) and the expected values are written into RAM variables with the expected values.

My first guess is  that the new data is invading some critical flash memory portion, but with such small values (< 1K) I don't see how).

Any ideas? Thank you in advanced!

[Tesla DeLorean]

Is this a custom board, or one of ST's ?

Is NRST connected too the ST-LINK ? BOOT0 pulled Low?

Any code disabling the SWD pins? Entering Low Power modes?

Any code reading / using the EEPROM data you've written?

The MCU otherwise continues to work, and you can interact with it. Entering Error_Handler() or HardFault_Handler()? Those outputting actionable information?

Does the debugger connect successfully if BOOT0 is pulled High?

[XR.1]

Is this a custom board, or one of ST's ?
Is NRST connected too the ST-LINK ? BOOT0 pulled Low?
Any code disabling the SWD pins? Entering Low Power modes?

It's a custom board. I've been using it (debugging/programming it) for 45 days without any problem. This problem started right after integrating the EEPROM code.

I'm not using (by now) any low power mode.

Any code reading / using the EEPROM data you've written?

      bool read_( uint16_t data_address, uint8_t* buffer, uint16_t len )
      {
         uint8_t *p = (uint8_t*)( EEPROM_BASE_ADDR + data_address );
         while( len-- )
         {
            *buffer++ = *p++;
         }
         return true;
      }

The MCU otherwise continues to work, and you can interact with it.

System starts and does its duty, however I cannot debug it.

Entering Error_Handler() or HardFault_Handler()? Those outputting actionable information?

No, fortunately I'm not facing these problems (by now).

Does the debugger connect successfully if BOOT0 is pulled High?

I haven't tried it, but I'll ASAP. 

If you have any other questions, please don't hesitate. Thank you!

[Tesla DeLorean · Accepted solution]

>>I've been using it (debugging/programming it) for 45 days without any problem. This problem started right after integrating the EEPROM code.

Ok, but I'm not aware of any history of the EEPROM interfering with debugging, either from forum interactions, or use of L0 for many years. Yes, I've used EEPROM on L011 and L072 devices.

Do you have NRST connected? The ST-LINK can't "connect under reset" if the pin isn't controlled by the debugger.

[XR.1]

Hi!

Do you have NRST connected? The ST-LINK can't "connect under reset" if the pin isn't controlled by the debugger.

No, I hadn't connected this signal. When I did so to my board, the problem dissapeared.

I had been developing my project on this hardware without NRST connected without any problem for a period of time. It even worked from the very first time, so I didn't think about this signal thoroughly.

Anyway, thank you for spotting it out!