STM32F and STARTUP_FROM_RESET

Comments

10 comments

  • Avatar
    Harjit Singh

    I have seen this warning but I use STARTUP_FROM_RESET with an STM32F103 and have not had any issues with the debugger being able to break in.

    Can you describe what behavior you observe?

    0
    Comment actions Permalink
  • Avatar
    Gordon Scott

    With the board as originally built, with boot0 to 0V via 10k and boot1 open, I could debug fine via the JTAG port.

    I then selected build "Thumb Flash Release" to check something.

    I then reverted to "Thumb Flash Debug" but the load fails to verify Loader_rpc.elf

    I then short boot0 to +3V3 and it appears I can reprogram the chip, but my program will not run properly, it jumps to the bootloader somewhere within the CTL library.

    I cut the short to +3V3 and again I can flash the chip and debug, though I may have to repower the board between each flashing.

    That means I'm back working, but also suggests I must fit a switch or something to change boot modes.

    It seems that if boot0 is low and the CPU has been programmed with STARTUP_FROM_RESET, then the CPU declines to allow the JTAG to reprogram it.

    0
    Comment actions Permalink
  • Avatar
    Michael Johnson

    Hi Gordon,

     

    Are you using the latest STM32 CPU support package? I changed the reset script  to use SYSRESETREQ on the parts

    that support it (found by experimentation). This will give clean debug from reset assuming that the JTAG port is alive.

     

    Regards

    Michael

    0
    Comment actions Permalink
  • Avatar
    Juraj Vanco

    Once your JTAG is in charge to debug processor, you lose it only when JTAG peripheral in STM32 gets out of power, e.g. in low power modes.

    The STARTUP_FROM_RESET does not provide any window to communicate with debugger. Without this definition you get the window at the beginning in which you get debugger in the communication with JTAG peripheral. This happens also if you run System Memory ROM code of STM32.

    There is also another possiblity: to force JTAG peripheral to synchronize with CPU via "Attach debugger". As I told, this can be possible only when you are not in low power mode.

    0
    Comment actions Permalink
  • Avatar
    Gordon Scott

    Crossworks says I have the latest CPU package:
    STMicroelectronics STM32 CPU Support Package 2.10 Installed
    STMicroelectronics STM32F10x CPU Support Package 1.11 Installed
    STMicroelectronics STM32F10x Standard Peripherals Library Updates 1.1 Installed

    I'll have a look around the reset script

     

    I can connect to the CPU OK  when it's in the verify will not work: I see the CPU description in the status bar. But the download process fails at verify of Loader_rpc.elf.

     

    When I'd changed the boot0/boot1 settings,  I tried the attach-debugger and then Break, which confirms the CPU is running the bootloader.

    I just did the flash release again to try 'attach debugger' and it seems to do something, though I'm not sure what as the program appears it may be at HardFault, though it also appears like it may not be stopped. I'm a it puzzled by this and need to explore further.

    0
    Comment actions Permalink
  • Avatar
    Harjit Singh

    Michael, can you provide the previous rev. of STM32_target.js so that we can compare the behavior or provide instructions on how to modify STM32_target.js to the previous method?

    The debugger used to be able to break into the STM32 boot even when I used STARTUP_FROM_RESET but with STM32 CPU Support Package 2.10, it doesn't seem to be able to.

    0
    Comment actions Permalink
  • Avatar
    Michael Johnson

    See attached - this uses

     TargetInterface.stopAndReset(400);

    which waggles the NSRST pin and then stops the CPU.

    0
    Comment actions Permalink
  • Avatar
    Harjit Singh

    Michael, the STM32_Target-4662.js works on my target and I see it assert and deassert NSRST (just like it used to).

    In reading through the ARM debug docs, doing the SYSRESETREQ should be fine.

    I also verified that doing VECTRESET (instead of SYSRESETREQ) also works. Here is the reset function. My testing is limited to one board but I verified that this stopped the CPU from flash as well as RAM.

     

    function Reset()
    {
      TargetInterface.pokeWord(0xE000EDF0, 0xA05F0003); // halt the CPU by setting C_HALT and C_DEBUGEN in DHCSR
      TargetInterface.waitForDebugState(200);
      var DBGMCU_IDCODE = TargetInterface.peekWord(0xE0042000);
      TargetInterface.pokeWord(0xE000EDFC, 0x1); // set VC_CORERESET in DEMCR to halt the CPU on reset

      switch (DBGMCU_IDCODE & 0xffff0fff)
        {
          case 0x410: // STM32F10xx8/STM32F10xxB Revision A devices
            TargetInterface.pokeWord(0xE000ED0C, 0x05FA0001); // set VECTRESET in AIRCR 
            break;
          default:
            TargetInterface.pokeWord(0xE000ED0C, 0x05FA0001); // set VECTRESET in AIRCR to generate a reset
            break;
        }
     
      TargetInterface.waitForDebugState(1000); 
      switch (DBGMCU_IDCODE & 0xfff)
        {
          case 0x411: // STM32F2xx
          case 0x416: // STM32L       
            TargetInterface.pokeWord(0xE0042004, 1<<2|1<<1|1<<0); // enable low-power mode debugging
            TargetInterface.pokeWord(0xE0042008, 1<<12|1<<11); // turn off WWDG and IWDG in debug mode
            break;
          default:
            TargetInterface.pokeWord(0xE0042004, 1<<8|1<<9|1<<2|1<<1|1<<0); // turn off WWDG and IWDG in debug mode and enable low-power mode debugging
        }
    }

    0
    Comment actions Permalink
  • Avatar
    Nadav

    Hi ,

     

    I have same problem ,boot0 and boot1 pins connected to ground.

    i switch boot0 from low to high logic it does something but still the debugger can not make single step etc.

    The linker calc CRC and the application too,it seems that something wrong with the flash.

    in other one board at list it work well.

    in RAM DEBUG it work well without jtag i use SWD.

    i try to copy the reset function and it fail at compiling.

    PLS advise.

    IF you have SKYPE PLS send me your address to talk.

    Thank you.

    Ilan MAZUZ

     

    0
    Comment actions Permalink
  • Avatar
    Harjit Singh

    If you change the level of the boot0 or boot1 pin, you have to reset the processor. Have you tried this?

    0
    Comment actions Permalink

Please sign in to leave a comment.