Post Go back to editing

Booting Firmware from Flash not working

Category: Hardware
Product Number: ADSP-21593

Hello together,

I have an issue with saving my firmware on the flash and then booting from the flash.

More exactly, after saving the firmware on the flash, the issue is that Sharc Core1 starts correctly but Core2 does not. However when running the Release-dxes of both cores using the ICE1000 in a Debug Session, the firmware runs fine without any problems for both cores.

What could be the issue, as it literally is executing the same program?

I do not have any more ideas what the problem could be, maybe somebody has an idea?

Best Regards,

Vitus

Parents
  • Hi Vitus,

    Could you please share your thoughts on the following points to help us address this issue more effectively?
    1. We recommend starting with a simple program (like toggling an LED) to verify that booting works correctly. Once this is confirmed, you can move forward with your application. This step will help determine if the booting problem is related to your application.
    2. We understand that your application runs smoothly during debugging. Could you let us know how you are generating the loader file?
    Please install Board support package from the below link.
    download.analog.com/.../ADI_EV-SC59x_EZ-KIT-Rel3.2.0.exe


    After installation, please refer readme file available in the below link and go through “Creating/Using Loader File” for complete procedure to create loader file.
    <Installation path>:\Analog Devices\EV-SC59x_EZ-KIT-Rel3.2.0\EV-SC59x_EZ-KIT\Examples\Power_On_Self_Test\Readme

    Since you are using multicore, please remember to include the -NoFinalTag switch. For more information, please refer the below FAQ.
    https://ez.analog.com/dsp/sharc-processors/w/documents/32203/elfloader-commands-for-generating-an-adsp-sc594-single-and-multicore-loader-stream

    3. Are you utilizing DDR memory in your application? If so, please ensure that you have included the initialization code when creating the loader file.

    4. Additionally, please connect the processor to DND (Do Not Disturb) mode or remove the reset option from the debug configuration, and then check the RCU_MSG register.

    Regards,
    Nandini C

Reply
  • Hi Vitus,

    Could you please share your thoughts on the following points to help us address this issue more effectively?
    1. We recommend starting with a simple program (like toggling an LED) to verify that booting works correctly. Once this is confirmed, you can move forward with your application. This step will help determine if the booting problem is related to your application.
    2. We understand that your application runs smoothly during debugging. Could you let us know how you are generating the loader file?
    Please install Board support package from the below link.
    download.analog.com/.../ADI_EV-SC59x_EZ-KIT-Rel3.2.0.exe


    After installation, please refer readme file available in the below link and go through “Creating/Using Loader File” for complete procedure to create loader file.
    <Installation path>:\Analog Devices\EV-SC59x_EZ-KIT-Rel3.2.0\EV-SC59x_EZ-KIT\Examples\Power_On_Self_Test\Readme

    Since you are using multicore, please remember to include the -NoFinalTag switch. For more information, please refer the below FAQ.
    https://ez.analog.com/dsp/sharc-processors/w/documents/32203/elfloader-commands-for-generating-an-adsp-sc594-single-and-multicore-loader-stream

    3. Are you utilizing DDR memory in your application? If so, please ensure that you have included the initialization code when creating the loader file.

    4. Additionally, please connect the processor to DND (Do Not Disturb) mode or remove the reset option from the debug configuration, and then check the RCU_MSG register.

    Regards,
    Nandini C

Children
  • So the command I use for the loader looks like this: 

    -proc ADSP-21593 -si-revision 0.0 -bspimaster -fbinary -width 8 -bcode 1 -init "C:\analog\cces\3.0.0\SHARC\ldr\ezkit21593_initcode_core1.dxe" -core1="C:/Users/Gimbio/git/NGA/nga_core1/Release/NGA_Core1.dxe" -NoFinalTag="NGA_Core1.dxe" -core2="C:/Users/Gimbio/git/NGA/nga_core2/Release/NGA_Core2.dxe"

    So, the NoFinalTag as well as the initcode is included.

    Also after removing the reset-option for Core2 in the Debug configuration, the program still runs fine when running over the ICE: 

  • Hi Vitus,

    Thanks for sharing the commands for generating the loader. They seem appropriate.

    1. As mentioned earlier, could you please starts with a simple program (like toggling an LED) to verify that booting works correctly. Once this is confirmed, you can move forward with your application. This step will help determine if the booting problem is related to your application.

    2. Have you connect the processor to DND (Do Not Disturb) mode and examined the RCU_MSG register? For guidance on connecting the processor to DND mode, please refer to the following link:
    https://ez.analog.com/dsp/software-and-development-tools/hardware-tools/w/documents/6749/how-to-debug-a-target-board-which-boots-from-flash-using-crosscore-embedded-studio

    3. Are using an Ezkit or a custom board?

    Regards,
    Nandini C

  • Hi Nandini,

    sorry for the late response. In the mean time I got the program running when booting from flash.

    However, I got a more urgent problem. When the program runs, when loaded from the flash, the program of one Core crashes or something at the execution of a certain instruction. The exact point where the program crashes is when adding more than one element to a std::vector. More exactly, I use a vector as a member of a certain class, and reserve in advance the required space in the vector, so that no dynamic memory allocations are necessary later. When then adding more than one element to the vector it seems that the program crashes. However, when running the program over the ICE, I cannot observe this problem, neither when debugging the Release version of the program nor the Debug version of the program.

    Do you have any idea what could be the problem here?

    Is my question still on topic, or should I post it in a separate post?

    I am happy about any advice!

    Best,

    Vitus

  • Hi,

    It seems you were loaded Release version of the program in the flash “i.e” executable generated with optimization enabled. Please confirm?

    If so, could you please try to disable the optimization by selecting Project > Properties > C/C++ Build > Settings > Tool Settings > Compiler > General > Disable optimization.

    Please note that the default setting (or "debug" mode within the IDE) is for non-optimized compilation in order to assist programmers in diagnosing problems with their initial coding.

    Regards,
    Nandini.C

  • Hello, 

    yes I am loading the Release version of the program and the flash.

    However I have already disabled optimization.

    In the mean time, I solved the issue by eliminating the following code from my program:

    adi_cache_set_range(void*, void*, adi_cache_rr4, adi_cache_noncacheable_range);

    I tried to modify the shared cached L2 memory range with this.

    Unfortunately, I do not understand why this solves the problem. Do you have an idea?

    Best, 

    Vitus

  • Hi Vitus,

    To maintain coherency between the contents stored in cache and the actual values in source memory, you have to flush the cache before turning a region to non-cacheable. This can be done via flush_data_buffer() function.

    While calling adi_cache_set_range(), it is user’s responsibility to flush would-be non-cacheable memory using flush_data_buffer() first. Can you please confirm whether you have used this flush_data_buffer() function?

    If this isn't helpful, can you please share more details about the sequence of data handling by cache and external activity, such as DMA.

    Regards,
    Nandini C

  • Yes, we use the flush_data_buffer() function. 

    The problem that we had was the following: at some point when trying to push elements on a std::vector, the program gets stuck at some allocation procedure within the push_back function.

    When we removed the adi_cache_set_range() this problem no longer occurred.

    The flush_data_buffer() works as expected.

    Best, 

    Vitus