• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 32 subscribers
  • Views 454 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AWRL1432BOOST-BSD: BSD demo v4.1, SBL jump to APP fails

James Austrial
Expert 4140 points
Part Number: AWRL1432BOOST-BSD
Other Parts Discussed in Thread: MMWAVE-L-SDK, UNIFLASH, TCAN4550

Tool/software:

HW: AWRL1432BOOST-BSD
SW: BSD demo v4.1

Description:

The issue is reproduced based on TI original HW and SW, no additional modification.

In previous BSD demo v3.1 The SBL is able to jump to APP. No problem at all.

When testing BSD demo v4.1. We found SBL is not able to jump to APP any more.

It looks memory copy fails in parser_image.c  p_memAddRet = memcpy((void*)t_ImagePrms.t_SectPrms.p_SectionPtr, (const void*)p_readPtr, w_bytesToWrite);

Please take a look.

I attached the SBL and APP images below for reference.

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/1023/sbl.Debug.appimage

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/1023/mmwave_5F00_demo.Debug.appimage

  • 0
    TI__Guru*** 149204 points

    Hi,

    In our release process we have not tested with SBL

    I assume the behavior is the same with the "Release" images.

    We will be able to review this issue next week

    thank you

    Cesar

  • 0 in reply to Cesar
    TI__Expert 4140 points

    Hi Cesar,

    May I have your feedback?

  • 0 in reply to James Austrial
    TI__Expert 3460 points

    Hi James,

    I just tested the SBL image present at this path

    "C:\ti\MMWAVE_L_SDK_05_05_03_00\examples\drivers\boot\sbl\xwrL14xx-evm\m4fss0-0_nortos\ti-arm-clang\sbl.release.appimage"

    The following link also has more background on the steps I took to test this

    xWRL1432 MMWAVE-L-SDK: Secondary Boot Loader

    I provided two screenshots to help explain my process (left is memory placement and right is uniflash screenshot). I loaded the sbl image in the meta image 1 location. I loaded my application (BSD demo) in meta image 2 location and my backup image in meta image 4. Everything worked for both versions of the BSD demo. I noticed you used the debug sbl image, try using the release version instead. If that doesn't work, please give me exact context on what you are trying to do and how you are doing it.

  • 0 in reply to Gabriel Gigliotti
    Prodigy 50 points

    Hi Gabriel Gigliotti：

    I’m using Release builds for both the SBL and the APP, placing the SBL in meta image 1 and the APP in meta image 2. In tests, when the appimage size is under 200 KB everything works fine, but once it exceeds 200 KB the bootloader fails to jump to the APP. To reproduce the issue, you can enable both #define TCAN4550 1 and #define ENABLE_MONITORS 1, which causes the appimage to grow beyond 200 KB.

  • 0 in reply to Jasper Tsai
    TI__Expert 3460 points

    Hello,

    I conducted what you said and received the same result. Please give us a few days to try to root cause this issue. I don't believe 200kb is the issue since I tried both defines individually and the enable monitors build was 203 kb.

    Best,

    Gabriel

  • 0 in reply to Gabriel Gigliotti
    TI__Expert 3460 points

    Hello,

    I believe I have found what the issue could be. If you access the following page, you can see the Developer Notes section at the bottom of the page. It specifies where critical sections of data are stored for the SBL (from address 0x00470000 to 0x0047FFFF).

    xWRL1432 MMWAVE-L-SDK: Secondary Boot Loader

    We can see on the memory map that when both tcan and monitoring is enabled we pass that 0x00470000 memory location. Left memory map is when tcan and mon are both enabled versus right is when only tcan is enabled.

    The Developer Notes section provides more context and workarounds as well, such as using shared memory as read only memory or disable ECC for APPSS/HWASS memory when shared with APPSS(M4). Try these workarounds and see if they work.

    Best,

    Gabriel

  • 0 in reply to Gabriel Gigliotti
    TI__Expert 4140 points

    Hi Gabriel,

    Customer have tried your suggestion: "Using shared memory as read only memory or disable ECC for APPSS/HWASS memory when shared with APPSS(M4)."

    However, none of them can solve this issue.

    You're able to reproduce this issue on TI software and EVM, could you provide a workable solution directly?

  • +1 in reply to James Austrial
    TI__Expert 3460 points

    Hello,

    I have a solution available. The problem stems from conflicting memory access between the SBL and BSD applications. To fix the issue please follow the following steps.

    1) Edit the linker.cmd file for the SBL application as shown to decrease M4F_RAM by half. Rebuild in CCS in release mode once changes are done.

    2) Edit the linker.cmd file for the BSD application as shown to decrease M4F_RAM3 by 32 KB freeing space for the SBL designated RAM. Rebuild in CCS in release mode once changes are done.

    Then both images can be flashed on the board. As a sanity check can you please format the SFLASH before loading your images. Here is where it can be done on the Uniflash app.

    Once SFlash has been erased then load your images in the correct locations and it should work as expected. Let me know if any further questions.

    Best,

    Gabriel