Can't set Option Byte with the attached function for the Micro STM32L151CBT6A Only when the controller is new from factory. If we erase and reset the option bytes the STM32 afterwards new flashing it works.

[ralf239955_stm1]

void init_OptionByte (void)

{

    FLASH->SR |= FLASH_SR_WRPERR ;     // l�sche bestehende Fehler

    FLASH->SR |= FLASH_SR_PGAERR ;     // l�sche bestehende Fehler

    FLASH->SR |= FLASH_SR_SIZERR ;     // l�sche bestehende Fehler

    FLASH->SR |= FLASH_SR_OPTVERR;     // l�sche bestehende Fehler

#if TT_DEBUG == TT_ON          /* Debug Betrieb */

    NOP;

#else                          /* Release */

                                                // Es soll:

    if(( FLASH_OB_GetRDP()  == RESET         )  //   Lese-Schutz bestehen

    || ( FLASH_OB_GetWRP()  != 0x00000000    )  //   kein Schreibschutz bestehen

    || ( FLASH_OB_GetUser() != 0x07          )  //   nRST_STDBY,nRST_STOP,IWDG_SW

    || ( FLASH_OB_GetBOR()  != OB_BOR_OFF    )) //   Brown-Out-Level 2

    {

                                                      // falls nicht, folgende Aktionen

       FLASH_Unlock();                                // unlock flash memory for erase/write actions

       FLASH_OB_Unlock();                             // unlocks the option bytes block access

       FLASH_OB_RDPConfig (OB_RDP_Level_1);           // memory read protection on. Achtung Level 2 ist irreversibel und klemmt den EMU ab!!

       FLASH_OB_WRPConfig (OB_WRP_AllPages, DISABLE); // memory write protection off (like default)

       FLASH_OB_UserConfig(OB_IWDG_SW, OB_STOP_NoRST, OB_STDBY_NoRST); // Sw watch dog, no reset when entering stop mode, no reset when entering standby (like default)

       FLASH_OB_BORConfig (OB_BOR_OFF);               // brown out detection off

       FLASH_OB_Launch();                             // lauch the option byte loading. L�st RESET aus

       FLASH_OB_Lock();                               // unlocks the option bytes block access

       FLASH_Lock();                                  // lock flash memory after erase/write actions

    }

    else

    {

       NOP;

    }

#endif

}

[Carsten1]

Hello, I am a colleague of ralf239955_stm1.

The problem really only occurs when we want to flash a brand new microcontroller.

We make do with a workaround by flashing twice. It is noticeable that after the first flash the Read Protection is set to Level 1, but the software does not start.

Even a power on reset does not help.

Only after a mass erase and the second flashing does our firmware start correctly. The process can then be repeated as required, the software starts up and Read Protection Level 1 is also set as required.

Does anyone have any idea why the brand-new microcontroller behaves this way and how you can achieve success with a single flash?

Many Thanks

[Mike_ST]

Just wondering,

In STM32L1 HAL V1.4.3 / 22-October-2020

FLASH_OB_GetRDP() doesn't seem to return RESET.

and FLASH_OB_GetUser() doesn't seem to return 0x7.

Maybe you wrote your own functions ?

[Carsten1]

These are older ST functions, but they have always worked correctly so far. The only difference seems to be that we now want to use an A-type microcontroller. The software is partially migrated from an STM32L151C8T6.

[Mike_ST]

"It is noticeable that after the first flash the Read Protection is set to Level 1, but the software does not start."

So that means the software has started and has set the RDP_Level to 1, and then, it is looping somewhere ?

You can also set RDP level 1 using -ob option using the STM32_Programmer_CLI at the same time you are flashing your binary.

[Carsten1]

Hi Mike,

Thank you for your prompt reply. We have been working with all types of ST microcontrollers for 10 years now. We would like to locate and understand the problem.

"The problem really only occurs when we want to flash a brand new microcontroller."

We can recognize that read protection has been set to level 1 if we want to establish a connection to the microcontroller with the ST-Link utility after the first flash. However, as I said, the software does not start. (I don't think the software loops in nirvana either.)

If we then e.g. perform a mass erase with the ST-Link utility and flash it a second time, the software starts up. From this moment on we can start as many flash processes as we want -> Everything is going well.

We know very well that the read protection can be set with the STM32_Programmer_CLI during flashing. But:

1. We flash with OpenOCD via one of our testers with whom we have also flashed the old STM32L151C8T6 (but we also have the problem when we flash with the STM32_Programmer_CLI) and ...

2. The firmware should also be able to set the read protection during the startup phase, as we have done so far.

We have now developed a workaround for this problem:

1. The tester sets RDP to level 1.

2. The tester sets RDP to level 0.

3. The tester performs a power on reset.

4. Finally, the software is flashed -> Everything is running fine.

regards

Carsten

[Mike_ST]

Hard to tell, from here.

It looks like the flash need to be erased, it is what the transition from RDP level 1 to RDP level 0 is doing after all.

Have you tried mass erase before flashing on the new parts to see whether it is changing anything ?

It might be a software path that leads to corrupted/empty flash or even hardfault depending of initial flash content.

There are errata sheets on STM32L1, if not done check wheteher you system is falling into one of these cases.

[Carsten1]

Hi Mike,

We also tried mass erase as a workaround. You can do that, but our solution is faster.

Your idea about corrupt flash content is good. The very first OB_Launch action may lead to incorrect address access and a hard fault error. That would be hard to debug. We are now studying the errata sheets. If we find a lead, we will report here at this point ...

regards

Carsten