[flasher ARM] release mode .srec not working on J-Flash and J-Flash Lite

Hello,

I'm trying to implement a programing method for production.

My program works well in debug mode on e2 studio even with the flasher ARM (from Segger) 

But when I build a srec or an hex file in release or debug mode and I try to use it with J-Flash or J-Flash lite,

The flash memory seems to be programmed and everything is okay but the code don't start...

 

Any idea of what's possibly wrong ?

 

Thanks,

 

Clément.

  • Hi Clément,

    Is your application making any calls to printf() or time()? These functions work only when the debugger is connected. Please check addresses in the SREC to see if there's any data in the load module that falls outside of flash addresses - if your binary initializes RAM then these segments will not be properly initialized on cold start.

    If you're only seeing these issues with Release mode then please compare build configuration settings with Debug configuration. By default the only difference is setting for debug information, which only affects the .elf file (Debug has this set to maximum/-g3 and Release build sets this to default/-g).

    Regards
  • In reply to Renesas Karol:

    Hi Karol,

    Thank you for your response !
    I don't use printf or time function in my program.
    How can I check the adresses in the srec file ? I dont' really understand this, do you have a tutorial or a link to have an explanation ?

    Thank you,

    Clément.
  • In reply to Clément:

    Hi Clément,

    SREC format is human-readable binary. Data is stored in blocks, each with its own id token, address, size and checksum: en.wikipedia.org/.../SREC_(file_format)

    Regards
  • In reply to Renesas Karol:

    Hi Karol,

    Thank you for your explanation :
    On the code part, it seems ok, it largely fits the µP flash memory.
    There is only one line for the ram and it seems to be composed of zeros :
    ...
    S315000161B400000000000000000000000000000000D4
    S315000161C400000000000000000000000000000000C4
    S309000161D400000000C0 // End of my program
    S3064010000000A9 // Only line of RAM
    S31560000000FEFF00000200FEFF0200FFFFFFFF02008E //First line of QSPI Data
    S31560000010FDFF0400FCFF0400FCFF0400FCFF04007D
    S31560000020FCFF0300FFFF00000100FEFF020000006E
    ...

    The last line seems strange :

    S70500007B7906
    I don't know the use of it.

    Is there something wrong ?

    Thanks,

    Clément.
  • In reply to Clément:

    I want to program a bootloader. There is no printf or initialise_function inside, only two files of code.

    Maybe I can't use the bsp warm state function ?
    void R_BSP_WarmStart (bsp_warm_start_event_t event)
    {
    if (BSP_WARM_START_PRE_C == event)
    {
    /* C runtime environment has not been setup so you cannot use globals. System clocks and pins are not setup. */
    }

    else if (BSP_WARM_START_POST_C == event)
    {

    bsp_init_hardware_locks();

    /* Delay */
    //R_BSP_SoftwareDelay(bsp_delay_units/freq_in_hz, bsp_delay_units);
    if(bootState)
    {
    write_flash_state(0);
    ssp_err_t status = g_sf_bootloader_mcu0.p_api->open(g_sf_bootloader_mcu0.p_ctrl, g_sf_bootloader_mcu0.p_cfg);
    if (!status)
    {
    status = g_sf_bootloader_mcu0.p_api->appStart(g_sf_bootloader_mcu0.p_ctrl);
    if (status)
    {

    g_sf_bootloader_mcu0.p_api->close(g_sf_bootloader_mcu0.p_ctrl);
    }
    }
    }

    }
    else
    {
    /* Do nothing */
    }
    }

    thanks in advance,

    Clément
  • In reply to Clément:

    Hi Clément,

    The R_BSP_WarmStart() context for the BSP_WARM_START_POST_C is before ThreadX has been started. If the bootloader framework uses any RTOS resources it will fail because ThreadX is not running.

    -Gary
  • In reply to garyj:

    Hi Garyj,

    My bootloader works great on debug mode and, when the flash memory is programed by the debugger (it happens sometimes), if I reboot my electronic board, everything works great without the debugger too. It's just that when I try to use an industrial way of programming my data, it doesn't work anymore...

    thank you,

    Clément.
  • In reply to Clément:

    Hi Clément,

    The one line you pointed out in your SREC file is at address 40100000h which is data-flash. Last line is a "termination record" as shown on the diagram I linked in my previous post. Gary's point is applicable to most frameworks, but SF_BOOTLOADER, SF_FIRMWARE_IMAGE and SF_MEMORY_MCU are exceptions to that rule as they don't have any dependency on ThreadX.

    You mentioned your application consists of bootloader - how do you intend to program the target application? For "production programming", I'd highly recommend composing a single SREC file consisting of the bootloader and application. This can be done easily by dumping flash contents from the MCU using JLink's savebin command, or through RFP.

    Regards
  • In reply to Renesas Karol:

    Hi Karol,

    For the moment, I would like to have at least an industrial process working with the bootloader. I'll try to dump the content of my application after that.

    Any idea of what's the problem ?

    Thanks,

    Clément.
  • In reply to Clément:

    Hi everybody,

    I found my problem ! My bootloader was waiting the USB key plug in event for a too short time and that made my board reboot indefinitely. It seems the USB key is found faster in debug mode !

    So no problem with the j-flash software !
  • In reply to Clément:

    Hi Clement-
    Thanx for finding this 'feature' of the debugger. I'm going to post a Knowledge Base article about it so it can be easily identified in the future.

    Warren