• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 99 subscribers
  • Views 929 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.

Debugging the IBL - malloc failing, EVM failing to step through code

Dan Christensen
Prodigy 240 points

Hello,

I'm trying to bring up a custom board with 2 C6678s.  In an effort to change to a different booting strategy, I've been attempting to run the IBL interactively through CCS.  This post (http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/140644.aspx#513379) was very helpful.  I'm building the IBL with DEBUG=yes, and in order to step through it in CCS, I load the i2cConfig.gel, then the .out file, then the setConfig_c6678_main function to setup the boot parameters table, then resume the code in CCS.  The boot configuration is set for "nor" and my plan is to modify that code path in the IBL to produce my desired results.

So far I get from main > iblNorBoot > iblBoot > iblBootElf > DLOAD_load > new_DLIMP_Dynamic_Module > DLIF_malloc.  Once I get to the DLIF_malloc though, it ends up returning 0.  This behavior did not always happen, and did not coincide with a rebuild of the IBL.  But once I see the malloc fail, I can't seem to recover.

My first attempt at resolving the malloc failure  was to double the HEAP size in ibl/src/make/ibl_c66x/ibl_common.inc.  This didn't seem to help.  I'm currently using the IBL from MCSDK 2.00.00.11 and would like to avoid updating unless absolutely necessary.

Then I moved to the EVM to verify basic functionality and debugging in the IBL.  So I started with a fresh copy of the IBL with no changes.  First, I doubled the TEXT_INIT size in ibl_common.inc to accommodate DEBUG=yes.  Then, I configured the EVM for NOBOOT mode in order to test this.  Once CCS is ready (following the process above) I step once with F6, CCS highlights the line "iblMemset (&iblStatus, 0, sizeof(iblStatus_t));" (ibl/src/main/iblmain.c:242).  I step again with F6 and CCS doesn't break again.  I suspend execution with CCS and get an address with no source available (e.g. 0x0FF0F39C) which the "assembly step into" will walk along these addresses but the disassembly window says "Memory map prevent reading of the target memory at 0x0FF0F39C [code=131072]" (and so on for the subsequent addresses).  So I'm not sure what's going on in the EVM.

I've also tried the above steps with the NOR (image 0) boot mode configured, and attached the debugger after the UART indicated the application from the NOR flash was up and running.  There was no difference in the behavior.

I'm not quite sure how to proceed.  Either with the EVM or with my custom board.  I'm not sure of another way to combat malloc failing (aside from increasing the HEAP).  I would appreciate any input.

Thanks,
Dan

  • 0
    TI__Genius 9915 points

    Hi Dan,

    Are you using the latest MCSDK?

    thanks,

    Arun.

  • 0 in reply to ArunMani
    Prodigy 240 points

    Hi Arun,

    I'm using the IBL from MCSDK 2.00.00.11 and would like to avoid updating unless absolutely necessary.

    Thanks,
    Dan

  • 0 in reply to Dan Christensen
    TI__Genius 9915 points

    Dan,

    please move to the MCSDK2.0.5. They have moved from separate config files and it is simpiler than before.

    Thanks,

    Arun.

  • 0 in reply to ArunMani
    Prodigy 240 points

    Hi Arun,

    I have now tested running the MCSDK 2.0.5.17 IBL (version 1.0.0.12) on the EVM, and it fails the same way.  Something in my procedure must be wrong.  Here is what I did with the newest MCSDK:

    1. Install MCSDK 2.00.05.17
    2. Grabbed the EVMC6678L.GEL file from ti_emupack_keystone1_setup_1.0.1.0_ccs_5.0.3.zip
    3. Copy %PROGRAMFILES%/Texas Instruments/mcsdk_2_00_05_17/tools/boot_loader to a directory to build it without modifying the installed files.
    4. Modified the setupenvMsys.sh to have the correct path to the CGT 7.2.4 binaries.
    5. sourced the setup script, and then ran make evm_c6678_i2c ENDIAN=little I2C_BUS_ADDR=0x51 DEBUG=yes
    6. (5) fails the first time, with a message about TEXT_INIT being too small, so I added 0x100 to TEXT_INIT and reduced TEXT by 0x100 in ibl/src/make/ibl_c66x/ibl_common.inc
    7. (6) built successfully, so off to CCS 5.0.3 which I loaded the GEL from (2), ran the Global Default Setup script and then loaded ibl/src/make/bin/i2cConfig.gel
    8. I loaded ibl/src/make/bin/ibl_c66x.out
    9. I then pressed F6 to step over the iblMemset call from iblmain.c:244
    10. I sat for a number of minutes and the Debug tab indicates that core 0 is still "running" and has not given back control to the debugger.
    11. I issued a suspend from the debugger, and saw "CPU pipeline is stalled and the CPU is 'not ready'" (I've omitted most of the message) but the last line read "(Error -1202) @ 0 (0x0)"

    I appear to be in the same state as before, and switching to the latest and greatest MCSDK / IBL was not the silver bullet solution that I needed.

    Any advice on how to do basic code-level debugging of the IBL in CCS would be greatly appreciated.

    Thanks,
    Dan

  • 0 in reply to Dan Christensen
    Prodigy 240 points

    It's also worth adding that I just tested a build where I did not pass DEBUG=yes, followed the rest of the procedure to load the code and execute (resume instead of step) and saw the IBL display some messages on the UART:

    IBL: PLL and DDR Initialization Complete
    IBL Result code 00
    IBL: Booting from NAND

    So I think DEBUG=yes breaks things.  Which is disappointing as that would be very useful to use.  At least this newer version of the IBL has some mechanism to display data on the UART.

    I was also able to get a test application to boot from the SPI NOR on the EVM using the 1.0.0.12 IBL.

    Thanks,
    Dan

  • 0 in reply to Dan Christensen
    Prodigy 240 points

    First, as I stated before, DEBUG=yes does not work, even in the 1.0.0.12 IBL (from the 2.00.05.17 MCSDK).  Is this expected to work?  If not, are there other mechanism(s) for source-level debugging?

    Using the 1.0.0.12 IBL, I was able to get our custom board to boot.  Now I am to the point where I want to cleanly integrate my changes and functionality.  To that end, I was wondering what is the preferred way to add support for additional boards or boot modes to the IBL?  It seems that one option is to replace an existing boot mode with the functionality that I need.  This does not seem like a very clean implementation though.

    Any thoughts on these points would be appreciated.

    Thanks,
    Dan