• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 31 subscribers
  • Views 134 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.

Original question:

AM263P4-Q1: AM263P4-Q1: AM263P4- Flash or Booting through JTAG

AM263P4: AM263Px Custom Board: Controller Stuck at 0x00004AA6 After Programming sbl.tiimage and app.mcelf

Shilpa G
Prodigy 240 points

Part Number: AM263P4
Other Parts Discussed in Thread: UNIFLASH, SYSCONFIG

Hi TI Team, 

We are able to load the image files successfully using UniFlash. However, we are observing the same issue that was previously seen with our SBL image.

After programming sbl.tiimage and app.mcelf through UniFlash, we changed the boot mode accordingly, performed a power cycle, and then connected through CCS using the sbl.out file in the target configuration.

During debugging, we observed that the controller gets stuck at the call stack address 0x00004AA6 and does not proceed further.

The corresponding screenshots showing the Disassembly View, Call Stack, and Register View have been attached below for reference.

Could you please help us understand:

  1. What could cause the controller to get stuck at address 0x00004AA6 after booting through the programmed SBL and application image?
  2. Are there any additional checks required to verify whether the SBL is correctly loading and jumping to the application?
  3. Is there any recommended debug approach to identify whether the issue is related to boot mode configuration, image generation, memory mapping, or application execution?

Please find the below attached register values, and even after loading the .out file still observing the same behaviour.

Attaching another thread of the flashing issue: AM263P4-Q1: AM263P4-Q1: AM263P4- Flash or Booting through JTAG


 


Best Regards,

Shilpa G

  • 0
    TI__Genius 9495 points

    Hi Shilpa,

    Since this a SIP device, no special changes are required in the SBL. Whatever SBL is shipped in the SDK should work (provided migration is done). Since the board lacks peripherals like UART, we had to remove them in the debug call. In the last meeting, we were able to boot a different SBL right? Can you share me the progress on that? 

    I remember we were able to boot it with the SBL in the last meeting. In that SBL, post changing the UART dependencies, what is the observation? Are you able to jump to the application. I would like you to double confirm that the all the flash and ospi settings in your SBL is indeed matching with the one in working ospi_flash_io example.

    Fundamentally there is no difference between OSPI-FLASH Driver of SBL and ospi_flash_io example. It is the same. So if the sysconfig configurations are same, then booting should be working.

    Let us use the SBL with which boot worked in last meeting for the tests.

    Additionally, can you share me your schematics. Specially the OSPI pins exposed out of the package?

    Thanks & Regards,
    Aswin

  • +1 in reply to Aswin Sankar
    TI__Genius 9495 points

    This issue was due to the issue with flashing. Performed flashing using SBL JTAG Uniflash tool and boot worked successfully.