Menu ▾ ▴

#231 STM32L07x dual bank fails flashing

0.9.0
new
nobody
None
2019-08-05
2019-03-31
Martin Jäger
No

I'm not able to flash my STM32L073 with the settings stated in https://sourceforge.net/p/openocd/code/ci/master/tree/tcl/board/st_nucleo_l073rz.cfg

If I change the WORKAREASIZE to 0x1000, everything works fine.

Do you agree to change the setting?

Discussion

  • Tomas Vanek

    Tomas Vanek - 2019-04-04

    The board config file is intended for ST Nucleo L073RZ board. The on-board MCU has 20kB RAM, more than enough for the requested 8kB work area. If you use similar, not the same MCU (and different board), do not use st_nucleo_l073rz.cfg directly. Make your own config (you can get inspiration from st_nucleo_l073rz.cfg)

     

  • Martin Jäger

    Martin Jäger - 2019-04-04

    I am using STM32L073CZ and STM32L072CZ. They do both have the same amount of RAM, just a smaller package.

    I can double-check with the STM32L073RZ nucleo board again when I'm back in the lab, but I had same issues with it before.

     

  • Tomas Vanek

    Tomas Vanek - 2019-04-04

    It might be an issue of the flash driver then. Please attach -d3 log of failed programming. Thanks

     

  • Andreas Bolsch

    Andreas Bolsch - 2019-04-04

    The size of working area must not have any influence except speed (as long as the memory is present and operating properly), otherwise there is probably a bug lurking around: The L073 hasn't got ECC for RAM nor watchdogs, which could cause obvious trouble. Hence it might be useful to dig into this further ...

    BTW: Does this problem occur on an 'empty' device, or when there's already something programmed in the flash?

     

  • Martin Jäger

    Martin Jäger - 2019-04-05

    Please find the the -d3 of a failed programming attached. This was with workareasize set to 0x2000. It doesn't fail always, but with workareasize set to 0x1000 it never failed so far. This might be by accident without a particular reason.

    This time I was not able to reproduce the failure with the Nucleo board itself. It only occured when programming the external microcontroller through the ST-link integrated in the Nucleo board. But I had similar issues also with the Nucleo board before.

    @Andreas: The L072/3 do have a watchdog.

    Currently don't have a board with an brand-new, empty microcontroller. If I remember correctly, empty devices never failed programming in the past.

     

    Last edit: Martin Jäger 2019-04-05
    openocd_debug_failed.txt

    • Andreas Bolsch

      Andreas Bolsch - 2019-04-05

      Oh, yes, overlooked the watchdogs at the very end of the features list ...

      I didn't mean brand-new. Just do a mass-erase and verify that option bytes are at factory settings (in particular hardware/software watchdog), power-cycle board and stlink, and restart OpenOCD. This should be sufficient to see whether the problem might be related to firmware or option settings.

       

  • Tomas Vanek

    Tomas Vanek - 2019-04-05

    The debug log shows that CPU waits for the end of half page write with stalled AHB and the adapter polling suffers from long waits. It seems just question of probability if and when the adapter exceeds MAX_WAIT_RETRIES (8).
    The write algo in contrib/loaders/flash/stm32/stm32lx.S should check FLASH_SR BSY bit at the end of half page to wait without blocking AHB.

     

  • Tomas Vanek

    Tomas Vanek - 2019-08-05

    Checking the FLASH_SR BSY bit in the flash loader does not help. AHB gets stalled in flash write operation before the algo can check BSY.

    Please test
    http://openocd.zylin.com/5270
    where the target algo is removed and memory block writes are used intead.
    The speed is slightly slower. Unpredictable long WAITs are reduced to one half page write time.

     

Log in to post a comment.