E2 Studio debugger cannot access SDRAM memory. (Debugger "Step Over" issue related)

Dear Colleagues!

are there any news about the "Step over" debugging issue first observed with E2 Studio 7.6.0?

https://community.renesas.com/tools/e2studio/f/e2studio-forum/15231/after-upgrading-to-7-6-0-debugging-with-step-over-is-not-fully-functional 

I have just checked our projects with 2024-01 and found no encouraging changes. Debugging of main() routine works, but if the execution stopped at the breakpoint in the middle of application - "Step Over" behaves the same as "Step In" - it is not possible to avoid entering every function on the way.

This time I decided to be a bit less lazy and investigate the situation more. In the "Debugger Console"  I see some "Cannot access memory at address" messages after stopping at the breakpoint.

We are using FreeRTOS. Resources for its tasks (Stack memory etc) are allocated on memory area, provided by SDRAM (0x8000000 - 0x8400000).

Execution started with creating root task that we call "generic". Stack for this task is allocated 0x801e8a8 - 0x80228a8.

If I stop at breakpoint in the generic task loop - following message comes in "Debugger Console" view:

Breakpoint 1, TaskGeneric (pParam=<error reading variable: Cannot access memory at address 0x8022898>) at ../src/generic_task.cpp:343

343 DigOuts_ProcessPulses();

so it looks like debugger (?) has no access to task's stack memory from SDRAM area. If I try investigate it in "Memory" view I see bunch of "??????"-s.

Are there any suggestions or extra initialization for gdb that may help accessing the memory?

Thank you and have a nice Weekend!

  • Hi Siarzhuk,

    Thanks for your inquiry and apologies for the delay. I've assigned this to someone from the Team to take a look.

    BR,

    PM_Renesas

  • Hi Siarzhuk,

    For the first question, I found that the "step over" works well unless you set the breakpoint in task creation.

    For the second question, could you tell me what MCU and the SDRAM work mode you are using now?

    BR,

    NP_Renesas

  • Thank you for the answer!


    We are using RX63N / R5F563NBDxFB MCU. Both E1 and E2 Lite debugger .

    SDRAM initialization procedure is as following:

    static void
    ConfigureSDRAM(void)
    {
      unsigned int delay = 0;
      
      // Unlock protection bits
      //Protect Register Control: Enables writing to clock gen, op modes, low power and LVD Registers
      SYSTEM.PRCR.WORD = PRCR_PRKEY_KEY | PRCR_PRC3 | PRCR_PRC1 | PRCR_PRC0;
    
      // Enable On Chip ROM & External BUS
      SYSTEM.SYSCR0.WORD = SYSCR0_KEY_KEY | SYSCR0_ROME | SYSCR0_EXBE;
    
      // Unlock protection register: To set the PFSWE bit to 1, write 1 to the PFSWE bit after writing 0 to the B0WI bit.
      MPC.PWPR.BYTE = 0x00;     		
      MPC.PWPR.BYTE = PWPR_PFSWE;
    
      // Configures PA1 to PA7 as the external address bus A0 to A7. A0 not used
    
      MPC.PFBCR0.BYTE |= PFBCR0_ADRLE;
    
      // Configures PB0 to PB6 as the external address bus A8 to A14
      MPC.PFAOE0.BYTE = PFAOE0_A8E | PFAOE0_A9E | PFAOE0_A10E | PFAOE0_A11E | PFAOE0_A12E | PFAOE0_A13E | PFAOE0_A14E;
    
      // Port E is D8-D15
      MPC.PFBCR0.BYTE |= PFBCR0_DHE;
    
      // Port D is D0-D7 -> Here no need since if the SDRAM is enabled d0 to d7 are obligatory
    
      // Configure P61 for SDRAM SDCS#
      // and P62 for RAS#
      // and P63 for CAS#
      // and P64 for WE#
      // and P65 for CKE
      // and P66 for DQM0
    
      MPC.PFBCR1.BYTE |= PFBCR1_MDSDE;
     
     // and P66 for DQM1
      MPC.PFBCR1.BYTE |= PFBCR1_DQM1E;
    
      // and enable SDCLK port pin
      MPC.PFBCR1.BYTE |= PFBCR1_SDCLKE;
    
      // Wait at least 100 uS (100 counts of about 100 MHz)
      for (delay=0; delay<100*100; delay++)
      {
        nop();
      }
    
      // Instead take this:
      // SDRAM initialization...AutoRefresh interval=3 cycles, Precharge cycles count=3cycles, 15 times
      BSC.SDIR.WORD = 0x00F0; 
      // Start the SDRAM initialization
      BSC.SDICR.BYTE = SDICR_INIRQ;
      // Wait for it to complete
      while (ANY_BIT_SET(BSC.SDICR.BYTE, SDICR_INIRQ))
      {
        nop();
      }
      // Configure more the SDRAM
     
      BSC.SDCMOD.BYTE = SDCMOD_ENDIAN_CPU; // Set same as the compiler operating mode: little endian
      BSC.SDCCR.BYTE = SDCCR_BSIZE_16; // Set 16-bit databus
      BSC.SDMOD.WORD = 0x220; //Set write single location, CL=2
    //----  BSC.SDMOD.WORD = 0x230; /* CL=3  */
      // Set the refresh cycle count to 5
      // Set refresh period to 720 clock cycles (15uS at 48Mhz)
      BSC.SDRFCR.WORD = SDRFCR_REFW(5-1) | SDRFCR_RFC(720-1);
    
      BSC.SDTR.LONG = 0x000002;    // set RAS=1, RCD=1, RP=1, WR=1, CL=2 == CAS, cycles
      BSC.SDADR.BYTE = 1;// set shift to 9 bits (for 8Mx16 SDRAM)
      BSC.SDRFEN.BYTE = SDRFEN_RFEN; 	// Auto-refresh operation is enabled
      BSC.SDCCR.BYTE |= SDCCR_EXENB;	// enable SDRAM operation...this should be last operation
    
      // Sets drive strenght of data bus to high  
      PORTD.DSCR.BYTE = 0xFF;
      PORTE.DSCR.BYTE = 0xFF;
      PORTA.DSCR.BYTE = 0xFF;
      PORTB.DSCR.BYTE = 0xFF;	
    
      BSC.BEREN.BYTE = PWPR_PFSWE | PWPR_B0WI;
    }


    I hope it helps.

  • Thank you for the hint!

    I have checked my Debug configurations and found that SDCS bus width was set to default 8 bit one. After changing it to 16 bit the SDRAM access problem looks like gone - both the task stack and the "Memory" View are looking healthy now. Quick check for the "Step Over" problem was also successful - I can debug inside of the task context too.

    Thanks a lot!