BSP_CFG_HANDLE_UNRECOVERABLE_ERROR(0) tied to time delay routine?

Well, 

I had code working before the Xmas break, but of course after the break it is broken - no pun intended.   I get BSP_CFG_HANDLE_UNRECOVERABLE_ERROR(0); and I have isolated it to this line (which used to work):  R_BSP_SoftwareDelay(100,BSP_DELAY_UNITS_MILLISECONDS);

Can you think of any reason why invoking a delay routine would cause this kind of problem?

 

Thanks

 

Jim

 

 

  • In reply to jimctr:

    Hi Jim,

    I need a little more context before I can answer the question - it looks like you may have an issue with alignment on an address of a data structure that the ARM instruction is trying to access. Please provide more information about your application.

    -Gary
  • In reply to garyj:

    Hi Gary:

    Can you explain more of what you need. The routine in question is the one provided by Renesas, in the bsp_delay.c file. If this is commented out, the program operates normally, but fails for other reason because the VBUS voltage has not had time enough to stabilize. This program used to run fine, so I am not certain what has changed. I run a series of tests to exercise hardware on my board, and I use preprocessor commands to dictate which tests run and which do not.

    Regards
    Jim


    //IDlvl = 0(false), means that either Host or Serial Converter attached
    //IDlvl = 1(true), no attachment of USB
    //Host = 0, Board acts a device - only check if IDlvl = 0
    //Host = 1, Board acts as a host and supplies 5V
    //*status = 0, Status OK; *status = 1, Problem exists
    bool Poll_USBID(bool *status, bool *Host){

    ioport_level_t PinVal;
    ioport_level_t Status1, Status2;

    bool IDlvl = true;

    *status = false; //No problem
    *Host = false;

    //Typically seeing ID bit set to ground indicates that you are operating as a device, receiving 5V from
    //the Host. If ID is pulled LOW but you do NOT sense 5V on the VBUS line, it is assumed that the Serial
    //translator is attached, and so the MCU itself must supply the 5V.
    GetUSBID(PinVal);

    if (!PinVal){ //If USB ID is pulled LOW, check to see state of VBUS
    IDlvl = false;
    GetUSBFBUS(PinVal);

    if (!PinVal) //if 5V Bus is LOW, Act as a Host and Set 5V
    *Host = true;
    ENABLE_VBUS;
    //Max time for VBUS to rise is 100ms
    //I need a delay here because the 5V requires time to ramp up. Otherwise, Status1 will fail.
    //Unfortunately, the Delay routine is causing problems and I am getting an unhandled error.!!!!
    //R_BSP_SoftwareDelay(100,BSP_DELAY_UNITS_MILLISECONDS);

    //Check that current status of the two current inputs

    GetUSB_Status1(Status1);
    GetUSB_Status2(Status2);

    //If both Status2 and Status2 are HIGH, VBUS circuit good
    //Else Not
    if (!(Status1 & Status2)){
    *status = true; //a problem exists
    DISABLE_VBUS;
    }

    }//end if (!PinVal)


    return(IDlvl);
    }
  • In reply to jimctr:

    Jim,

    Can you please post the disassembly view in the debugger (Window>show view>disassembly) and step into the R_BSP_SoftwareDelay() function. I would also be helpful to know the SSP version that you are using and the board BSP.

    I have not seen any issue with the R_BSP_SoftwareDelay() function and I think that there is something else going on here.

    -Gary
  • In reply to garyj:

    Hi Gary:

    I did reply to you via email but it doesn't appear to get to you.  I have run into additional problems so cannot resume research of this particular problem yet.  It appears that I stall where I enter into a loop

    162               __asm volatile ("sw_delay_loop:         \n"

             software_delay_loop:

    00004004:   sub.w   r0, r0, #1

    00004008:   cmp     r0, #0

    0000400a:   bne.n   0x4004 <software_delay_loop>

    0000400c:   bx      lr

    0000400e:   nop    

    181       }

             R_BSP_SoftwareDelay:

    00004010:   stmdb   sp!, {r4, r6, r7, r8, r9, lr}

    101           uint32_t total_us = (delay * units);  /** Convert the requested time to microseconds. */

    00004014:   mul.w   r4, r1, r0

    104           iclk_hz = bsp_cpu_clock_get();        /** Get the system clock frequency in Hz. */

    00004018:   bl      0x3bf0 <bsp_cpu_clock_get>

    116            ns_64bits = (uint64_t)total_us * (uint64_t)1000;      // Convert to ns.

    0000401c:   mov.w   r1, #1000       ; 0x3e8

    00004020:   umull   r8, r9, r4, r1

    119            if (ns_64bits <= 0xFFFFFFFFUL)

    00004024:   movs    r7, #0

    00004026:   mov.w   r6, #4294967295

    0000402a:   cmp     r7, r9

     

    What is the best way to check the status of stacks?  I notice there is a stack analysis tab, but it doesn’t appear under the debug.  And it is asking for a stack information file ?? 

    I did increase the stack size of my main thread (really currently the only thread I do most of my work in from 1024 to 4096, but still the same error results.  I know this shotgun method is not very effective a debugging however.

     

  • In reply to jimctr:

    Jim,

    You can use the Renesas Views>Partner OS>RTOS Resources view in the debugger and select the stacks tab.
    The view will update when you hit a breakpoint.

    -Gary
  • In reply to garyj:

    Hi Gary,

    While programming, I encountered a similar problem and I hope you can help me. I wrote a program that enabled window switching on the LCD by clicking a button. My program was compiled without any warnings or errors, but when the program was written, my program stopped at the line BSP_CFG_HANDLE_UNRECOVERABLE_ERROR (0) and nothing was displayed on the LCD screen. If I delete this line, the screen can be displayed on the LCD screen, but the window switching function cannot be realized. Can you help me answer this question?

    Here is my code:

    UINT window1_handler(GX_WINDOW *widget, GX_EVENT *event_ptr)

    {

    UINT result = gx_window_event_process(widget, event_ptr);

    switch (event_ptr->gx_event_type)

    {

    case GX_SIGNAL(ID_CHECKBOX, GX_EVENT_TOGGLE_ON):

    button_enabled = true;

    update_text_id(widget->gx_widget_parent, ID_PROMPT_MAIN, GX_STRING_ID_BUTTON_STATUS);

    update_text_id(widget->gx_widget_parent, ID_TEXT_BUTTON_STARTED, GX_STRING_ID_BUTTON_CONTINUE);

    break;

    case GX_SIGNAL(ID_CHECKBOX, GX_EVENT_TOGGLE_OFF):

    button_enabled = false;

    update_text_id(widget->gx_widget_parent, ID_PROMPT_MAIN, GX_STRING_ID_PROMPT_HOME);

    update_text_id(widget->gx_widget_parent, ID_TEXT_BUTTON_STARTED, GX_STRING_ID_BUTTON_STATUS);

    break;

    case GX_SIGNAL(ID_TEXT_BUTTON_STARTED, GX_EVENT_CLICKED):

    if(button_enabled){

    show_window((GX_WINDOW*)&window2, (GX_WIDGET*)widget, true);

    }

    break;

    default:

    gx_window_event_process(widget, event_ptr);

    break;

    }

    return result;

    }

    UINT window2_handler(GX_WINDOW *widget, GX_EVENT *event_ptr)

    {

    UINT result = gx_window_event_process(widget, event_ptr);

    switch (event_ptr->gx_event_type)

    {

    case GX_SIGNAL(ID_BUTTON_HOME, GX_EVENT_CLICKED):

    button_enabled = true;

    if(button_enabled){

    show_window((GX_WINDOW*)&window1, (GX_WIDGET*)widget, true);

    }

    break;

    default:

    gx_window_event_process(widget, event_ptr);

    break;

    }

    return result;

    }

     

    This is where the program stops when the program is written:

    Best regards,

    ghg

  • In reply to ghg:

    hii ghg

    can you able to give me answer for BSP_CFG_HANDLE_UNRECOVERABLE_ERROR (0) problem because i have same problem in my program.
  • In reply to sonu:

    Hi sonu,

    Could you attach a screenshot of the call stack when this issue occurs?

    Regards,
    adboc