This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

IWRL6432: Issues flashing software

Part Number: IWRL6432


Hallo!

I am working on a project for the IWRL6432 and have discovered that the execution gets stuck in the boot when the program image size exceeds a certain limit.

To test my theory, I have allocated space for a constant dummy array in the LED blink example and I see that when the size of the array passes 315000 bytes, the program does not start, which I interpret as the boot rejecting the meta image.

I use the CCS project and makefile_ccs_bootimage_gen to build and create the metafile that I download using arprog_cmdline.py.

MulticoreImageGen has an argument for shared memory usage, which may need to be changed, but I can't find any MulticoreImageGen documentation that applies to IWRL6432, so I've kept the setting in the example's makefile_ccs_bootimage_gen, i.e. 0.

I am now wondering what causes the simple program not to start when the image becomes too large.

I have attached my gpio_led_blink.c file and I have used MMWAVE_L_SDK_05_01_00_04 for my tests.

BR Honke

/*
 *  Copyright (C) 2021 Texas Instruments Incorporated
 *
 *  Redistribution and use in source and binary forms, with or without
 *  modification, are permitted provided that the following conditions
 *  are met:
 *
 *    Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 *
 *    Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the
 *    distribution.
 *
 *    Neither the name of Texas Instruments Incorporated nor the names of
 *    its contributors may be used to endorse or promote products derived
 *    from this software without specific prior written permission.
 *
 *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
 *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
 *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
 *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
 *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
 *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */

#include <drivers/gpio.h>
#include <kernel/dpl/AddrTranslateP.h>
#include <kernel/dpl/DebugP.h>
#include <kernel/dpl/ClockP.h>
#include "ti_drivers_config.h"
#include "ti_drivers_open_close.h"
#include "ti_board_open_close.h"

/*
 * This example configures a GPIO pin connected to an LED on the EVM in
 * output mode.
 * The application toggles the LED on/off for 10 seconds and exits.
 */
#define DUMMY_SIZE 320000
volatile const uint8_t aDummy[DUMMY_SIZE] = {0};

void gpio_led_blink_main(void *args)
{
    uint32_t    loopcnt = 5, delaySec = 1;
    uint32_t    gpioBaseAddr, pinNum;

    /* Open drivers to open the UART driver for console */
    Drivers_open();
    Board_driversOpen();

    while (1)
    {
        DebugP_log("GPIO LED Blink Test Started ...\r\n");
        DebugP_log("LED will Blink for %d seconds ...\r\n", (loopcnt * delaySec * 2));

        /* Get address after translation translate */
        gpioBaseAddr = (uint32_t) AddrTranslateP_getLocalAddr(CSL_APP_GIO_U_BASE);
        pinNum       = GPIO_LED_PIN;

        GPIO_setDirMode(gpioBaseAddr, pinNum, GPIO_LED_DIR);
        loopcnt = 5;
        while(loopcnt > 0)
        {
            GPIO_pinWriteHigh(gpioBaseAddr, pinNum);
            ClockP_sleep(delaySec);
            GPIO_pinWriteLow(gpioBaseAddr, pinNum);
            ClockP_sleep(delaySec);

            loopcnt--;
        }


        if (aDummy[0] == 0)
        {
            ClockP_sleep(10);
        }
        else if (aDummy[DUMMY_SIZE-1] == 0xFF)
        {
            ClockP_sleep(20);
        }


        DebugP_log("GPIO LED Blink Test Passed!!\r\n");
        DebugP_log("All tests have passed!!\r\n");
    }

    Board_driversClose();
    Drivers_close();
}

  • Hello,

    In CCS, you can get an idea of how much space your program is taking during the debug phase where a tab shows up that says "Memory Allocation View". Indeed if you try to allocate too much memory, the R4F Cortex will not be able to start/reach main.c. You can also go to tools and look at Runtime Object Viewer to see where it hangs. With memory allocation issues, you will likely see something such as heapInit. Just to confirm, you have verified your enviornment to work via importing IWRL6432's Motion and Presence demo within the SDK, compiled that, and flashed it to see if it starts and runs properly?

    Best Regards,

    Pedrhom

  • Pedrhom, thanks for your quick response!

    Using CCS is of course a good advise for debugging errors in your program, but in this case, the program works perfectly fine in CCS, but when I flash the program using arprog_cmdline, it seems like the program doesn't even reach the first line of code. Therefore, I suspect that there is something in the boot that prevents continued execution, when the image becomes too big.

    The IWRL6432 is a brand new circuit and it is not unlikely that early tests detect this kind of errors. Above I have attached my change to the simple led blink example so you can replicate what I see in my tests.

    (The Memory Allocation View in CCS show the following:)

    BR,

    Honke

  • Hello Honke,

    I have personally come across this issue on other devices and I imagine this issue can be similar. When a program compiles fine and the Memory Allocation shows good margins, it is good to use Runtime Object Viewer while in debug mode to see where it hangs. In my experience when it comes to memory, the issue results from heap initialization failure and the viewer mentioned can generally confirm this. This is something CCS does not calculate at compilation of a program. Have you tried increasing the size of the heap?

    Best Regards,

    Pedrhom

  • Thanks Pedrhom,

    Doesn't this require that the software hang while you are running the software in debug mode in CCS? As I wrote the very simple (slightly modified) led blink software works perfectly well in debug mode, but doesn't start after flashing the software with arprog_cmdline.py, so I cannot see how the Runtime Object Viewer can help me. 

    BR,

    Honke

  • Hello Honke,

    I misunderstood, I thought you were saying that the program compiled fine but always hung when flashed to the device, whether it be in debug mode or flashed with a compiled binary. If what you are saying is that it compiles, can flash both .xer4f and .xe674 files, and run it without issue and then only after flashing the .bin and running it in functional mode does it not work, then I will need some more time to investigate this as there should not ever really be a delta between debug mode and functional mode.

    Best Regards,

    Pedrhom 

  • Hello,

    I am still very curious if there is any solution on this issue, since I can only run my software in the CCS debugging environment, i.e. if I flash the software with arprog_cmdline.py the software doesn't start at all.

    BR

    Honke

  • Hello Honke,

    Have you tried building the project in "Release" mode rather than "Debug" mode and flashing a release binary?

    Best Regards,

    Pedrhom

  • Pedrhom,

    I changed the configuration to "Release" and found that the modified led blink example is working with DUMMY_SIZE set to 320000, but the reason for this is that optimization is set to "s" for "Release", so the size of the code becomes a little smaller. Increasing the DUMMY_SIZE to 330000 will give an image of approximately the same size as for configuration "Debug" and with this setting the example doesn't start, i.e. the LED doesn't blink. 

    BR,

    Honke

  • Hello Honke,

    What might be happening is that you are overwriting the ATE calibration information when running it on device independently from CCS. One thing I would like you to do is to load symbols and check where exactly it is breaking and send me a screenshot. I want to determine if the device is getting stuck in the bootloader or application. You could also check the NERROR pin and see what the result is.

    Best Regards,

    Pedrhom

  • Hello Again Honke,

    Please try this fix which is an update to the linker file

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/1023/linker.cmd

    Best Regards,

    Pedrhom Nafisi

  • Thanks Pedrhom!

    It seems like you have found something, because now the led blink example is working with DUMMY_SIZE set to 330000, but when increasing the constant to 340000 I get the following linking error:

    Building target: "gpio_led_blink_xwrL64xx-evm_m4fss0-0_freertos_ti-arm-clang.out"
    Invoking: Arm Linker
    ...
    "../linker.cmd", line 28: error #10099-D: program will not fit into available memory, or the section contains a call site that requires a trampoline that can't be generated for this section. placement with alignment fails for section ".rodata" size 0x538e0. Available memory ranges:
    M4F_RAM12 size: 0x57e00 unused: 0x51550 max hole: 0x51548
    M4F_RAM3 size: 0x20000 unused: 0x1c000 max hole: 0x1c000
    error #10010: errors encountered during linking; "gpio_led_blink_xwrL64xx-evm_m4fss0-0_freertos_ti-arm-clang.out" not built
    tiarmclang: error: tiarmlnk command failed with exit code 1 (use -v to see invocation)
    gmake[1]: *** [gpio_led_blink_xwrL64xx-evm_m4fss0-0_freertos_ti-arm-clang.out] Error 1
    makefile:148: recipe for target 'all' failed
    gmake: *** [all] Error 2

    I see, in linker.cmd, that you want to avoid the memory range 0x458000 - 0x460000, because that RAM range is used by RBL.

    What is RBL? I searched the Reference Manual, but cannot find any information.

    It seems like we must find another way of avoiding this memory range because the suggested solution in the attached linker.cmd doesn't work if the sections don't fully fit in either RAM12 or RAM3. I.e. you cannot split a section between the two defined RAM ranges. I tried the suggested solution on my original program and I get the same issue during linkage of that program, i.e. one or several sections doesn't fully fit in either RAM12 or RAM3, so they need to be split, which is now allowed.

    Would it be possible to allocate memory for an uninitialized variable in the code, at the location for the reserved memory area?

    BR,

    Honke

  • Hi Honke, 

    Pedrhom is currently out of office, so give us some time to look into this on his behalf internally. We should get back to you within 48 hours.

    Regards,

    Luke

  • Hi Honke,

    Sorry about the delayed response here. 

    What is RBL?

    RBL is referring to the bootloader. 

    I understand your predicament and the limitations that this fix has in terms of max hole size. We are still looking into alternate solutions. 

    Best Regards,

    Josh