Skip to main content
Graduate II
April 7, 2024
Solved

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

  • April 7, 2024
  • 1 reply
  • 1998 views

Hi,

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

Captura de pantalla de 2024-04-07 16-03-42.png

 

 

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:

Captura de pantalla de 2024-04-07 15-26-36.png

(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:

Captura de pantalla de 2024-04-07 15-44-19.png

And then I can enter into the debug mode again:

Captura de pantalla de 2024-04-07 15-33-39.png

 

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!

 

 

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

    >>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.

    1 reply

    Graduate II
    April 7, 2024

    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.1Author
    Graduate II
    April 8, 2024

    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!

    Graduate II
    April 8, 2024

    >>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.