Program up and running when flashed with Renesas Flash Programmer, not working when debugging

Hi everyone,

I'm trying to debug an application that is located at 0x80000, since the space before is used for a bootloader. I have set the startup options to the corresponding addresses and can track the boot of the application up until

while ((0U != p_system_reg->SOPCCR_b.SOPCMTSF) || (0U != p_system_reg->OPCCR_b.OPCMTSF)) in hw_cgc.c

There, the program hangs in the endless while-loop. When I flash it with the Renesas Flash Programmer it works. When I reset the board and the flash was written by the debugger, it still doesn't work, so it shouldn't be a problem with the debugging per se, but more the way the debugger writes the flash.

Any ideas how to fix that?

Regards,

Christoph

  • Hi Christoph,

    Are you using your own board or one from Renesas?

    Regards
  • In reply to Renesas Karol:

    I am using a SYG-S7G2 MDK from Teamfdi. The Thing is, the Program runs just fine, when I Program the Flash with renesas Flash Programmer, when the Debugger does it, even after resetting the Board and disconnecting the Debugger, it still won't start.

    The bootloader is supposed to jump to the Image location, which works when Programmed through renesas Flash Programmer.

    Regards,

    Christoph
  • In reply to cbismark:

    Any news from you? This is pretty important to us. We could debug the application when saving it to Flash at position 0x00000000 and for production writing the bootloader to position 0 and the application to 80000, but that way we would need to use two linker files for each project and might not find errors that only exist when the application starts at 0x80000.

    Regards,

    Christoph
  • In reply to cbismark:

    Hello Christoph,

    When working with the debugger, is your application configured to start at 0x0 or 0x80000? Cortex M MCUs always get their initial stack pointer from 0x0 and reset vector from 0x4. You will need additional instructions in order to set up initial SP, PC and VTOR for application that doesn't start at 0x0:

    These are set in the debug configuration on the startup tab.

    Regards

  • In reply to Renesas Karol:

    Hi Karol,

    I set up These run commands with my addresses 0x80000. Weird Thing is, the Debugger still starts in the bootloader (located at 0x0), I can See this through breakpoints when adding the bootloader elf file to the debug configuration.

    Any more ideas?

    Regards,

    Christoph
  • In reply to cbismark:

    Hi Karol,

    any news on this problem?

    Regards,

    Christoph

     

    EDIT: I re-checked and found that I missed the * before the addresses for $pc and $sp. the program now apparently starts correctly in the second program, not the bootloader, however it still hangs at HW_CGC_OperatingModeSet(p_system_reg, CGC_HIGH_SPEED_MODE); and internally at while ((0U != p_system_reg->SOPCCR_b.SOPCMTSF) || (0U != p_system_reg->OPCCR_b.OPCMTSF)).

     

    Also, it seems as if the chip is running through these functions thrice, with hanging at the third time, is this normal behaviour?

    Regards,

    Christoph

  • In reply to cbismark:

    Hi Christoph,

    Are you using same clock configuration between bootloader and application projects (i.e. settings on the Clocks tab in the configurator)? I can also recommend checking properties of the g_cgc instance on the HAL/Common tab. If the application gets stuck at while ((0U != p_system_reg->SOPCCR_b.SOPCMTSF) || (0U != p_system_reg->OPCCR_b.OPCMTSF)) then this indicates that transition is in progress for either operating or sub-operating power control mode. Typically this would last couple of cycles unless there's an error in the configuration.

    Regards
  • In reply to Renesas Karol:

    Hi Karol,

    thank you for your answer. The Main Oscillator Wait Time was different, in the Bootloader 2087us (547 cycles) and in the Program 31139us (8163 cycles). After changing it however it still doesn't work, hangs at the same point in the program.

    Clocks Tab is configured the same.

    Anything else I can try?

    Regards,

    Christoph
  • In reply to cbismark:

    Hello Christoph,

    Can you share your settings from the clock tab?

    Regards
  • In reply to Renesas Karol:

    Hi Karol,

    please find attached the clock tab screenshot for the bootloader and the main application. As mentioned before, the settings are the same, thus only one screenshot.

    I tried to start the main program without having the bootloader installed (erased all, flash main program from 0x80000 and started with

    set $sp = *0x80000
    set $pc = *0x80004
    set {int}0xe000ed08 = 0x80000

    When debugging, the following error happened :

    Any ideas?

    Regards,

     

    Christoph

  • In reply to cbismark:

    I have removed all breakpoints and suddenly it works to debug at 0x80000. I didn't change anything else, so somehow the breakpoints must have been the reason for it to not work.

    I have another problem now, I inserted a breakpoint in my USB_thread_entry of the main program and tried to do something as simple as write 4 bytes into an unsigned int value. I tried it through bitshifting and adding and through a union consisting of four bytes and one int. Both of these methods usually work in C in our old controller, however this thread, the variable just isn't written.

    To test this behaviour, I simply wrote variable=53 (random number) and after stepping through this instruction, the variable remained 0.

    The program is built with oprimization level 0 and debug level maximum (I think 3).

    Any idea what could cause the debugger to not be able to read out the variable? Or even the variable to not be set? the variable is defined as static UINT in the usb_thread_entry function, in which I handle all the USB CDC TXD and RXD routines.

    Regards,

    Christoph

     

    EDIT: I just tried it while debugging at 0x00 and reading out the variable worked correctly. Apparently the debugger doesn't work as it should when starting the program from 80000. How can I fix this? It's really important for us!