• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 102 subscribers
  • Views 369 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AM6548: SBL development/debugging problem on AM6548 Sitara

Novica Jovanovic
Intellectual 470 points
Part Number: AM6548
Other Parts Discussed in Thread: TMDX654IDKEVM, UNIFLASH

Hello All,

I have some questions regarding SBL development/debugging on AM6548 Sitara.

My configuration is:

CCS ver 8.3.0

Windows version - Windows 10 Pro version 1803

TI-RTOS SDK 6.01

PDK - pdk_am65xx_1_0_6

AM65x (IDK) - TMDX654IDKEVM

Custom board based on AM6548

In our custom board with AM6548 we use as primary boot device qspi nor flash memory. So in order to boot application from NOR flash on our custom board, qspi support must be added in SBL application.

 

As a starting point I decided to test existing OSPI SBL from pdk on AM65xx IDK board. My idea was to load and run original OSPI SBL for AM65xx IDK board via emulator(XDS200) from CCS. I wanted to see how SBL works, and to test debugging options (breakpoints , step by step execution etc.) in order to use debugging for further developing of SBL application with qspi support for our custom board.

 

What I did:

- I created target configuration file for IDK board, where i added .js script (ti\drv\sciclient\tools\ccsLoadDmsc\am65xx\launch.js) for basic initialization of SoC with GEL files (original GEL files from CCS were used).

- When SoC was initialized, the OSPI SBL application was loaded to the MCU_Cortex_R5_0 core

- Then I started to execute SBL code step by step

 

But following problems appeared:

1) MCU UART interface is printing messages on serial terminal on baud rate 230400 instead of configured 115200

2) in file `sbl_ospi.c` under function <int32_t SBL_ReadSysfwImage(void **pBuffer, uint32_t num_bytes)>, when function that opens flash instance is called `h = Board_flashOpen(BOARD_FLASH_ID_MT35XU512ABA1G12, BOARD_OSPI_NOR_INSTANCE, NULL);` the communication is not open (Board_flashHandle h == NULL).

 

I don't have any hardware problems with IDK board, I confirmed that by running ospi nor flash test. The second test i made was that I placed the OSPI SBL, SYSFW and some APP to OSPI nor flash on IDK board (by using Uniflash application), then i set OSPI as primary boot device and after power-up SBL, SYSFW and APP were loaded and executed without any problem.

 

I am wondering if TI used CCS for developing and debugging the SBL code?

Are there some special GEL files that are needed to initialize SoC (on the same way like ROM bootloader do), so that SBL can be run properly via CCS?

 

Best regards,

Novica

  • 0
    TI__Genius 14680 points

    Novica,

    Are you loading the SYSFW to the DMSC? If you are bypassing the internal ROM bootloader, you need to be sure the SYSFW loaded in addition to the SBL program.

    The steps to load the DMSC firmware to the M3 are outlined in the UG. You will need to use the .js file from the RTOS SDK

    http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_how_to_guides.html#am65x-debug-software-setup 

     

    See section "10.3.1.3.3.1. Creating Debug Configuration to Integrate CCS GEL and DMSC Firmware Initialization"

    Please confirm and we can then look to next steps.

    Best regards,

    Dave

  • 0 in reply to Dave Bell
    Intellectual 470 points

    Hello Dave,

    Thank you for your reply.

    Yes i am loading SYSFW to the DMSC. I am using the JS script from pdk to load SYSFW to M3 core and for basic initialization on SoC.

    But still i have problem that i mentioned in previous post.

    Best regards,

    Novica

  • 0 in reply to Novica Jovanovic
    Mastermind 6185 points

    Hello Novica,

    debugging the SBL with a (half-way) initialized processor never worked for us. The SBL itself tries to initialize the hardware, and for example loads the SYSFW to the DMSC. This works only once, and I'm pretty sure we've seen errors from the Sciclient if we tried to initialize the DMSC again.

    The SBL also seems to rely on some previous initialization of the peripherals for the boot medium, e.g. we've not been able to access the SD-card from the SBL if the processor was configured to boot from OSPI. The boot ROM only initializes the peripherals it needs for the configured boot medium.

    We use two approaches to debug the SBL:

    a) add a while loop waiting for a (volatile) variable to change, flash the SBL via some external means (e.g. Uniflash) and use a debugger configuration that simply "attaches" to the processor, without any initializing GEL files. The turnaround times are pretty high, since every change to the software requires the SBL to be written to flash.

    b) put a small pre-bootloader that is wrapped like a SBL in the flash, attach to that, and load the SBL using the debugger. That way you should be able to read the SYSFW from OSPI, since the ROM initialized everything as usual.

    If you take too long from system reset to the Sciclient initialization (I think), a watchdog is going to reset the processor. The romclean.gel that comes with CCS shows you how to disable that watchdog. We wrapped these few lines in a hotmenu that we can call from the CCS menu bar.

    If TI has a solution that works out of the box I would of course be very interested myself, but I haven't seen something like that yet.

    Regards,

    Dominic

  • 0 in reply to Dominic Rath
    Intellectual 470 points

    Hello Dominic,

    Thanks for the information you provided to me.

    I tried to used both options from your answer, and both of them are working fine for me.

    Once again, thank you for your help and for sharing your knowledge regarding to this topic!

    Best regards,

    Novica