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.

MAD tool question (booting 8 cores - C6678)

Hi,

I encountered a problem while trying to use the MAD tool for booting 8 cores (C6678).

 

For some of the .out files the 8 cores SPI booting is working perfect, but for other .out files – core 0 is stuck at address 0x0c008384  and all the other cores are working fine (core0 loaded all the other cores but did not start his own application).

In all the cases I’m using the same configurations, just replacing the .out files (these .out files are working well when working with CCS).

 

Also I took one of the CCS example projects, MessageQ,  and encountered the same behavior:

  • I didn’t do any changes in the application  (or in the memory map).
  • Same .out file supposes to run on all the cores.
  • I am working with “bypass-prelink” mode.
  • All the cores (except core 0) are running and working fine.
  • Core0 is stuck at address 0x0c008384 when I am working with the MSMC.
  • I am working with the last TI software - CCS5.2.1.00018 & CGT_c6000_7.4.1

 

Also I am using below procedure to debug the MAD utility (without using the MAD2Hex, and without burning to FLASH)… and I am getting the same behavior:

  • Connect to Core 0 using the CCS.
  • Load the gel file “evmc6678l.gel”, and run the script “Global_Default_Setup”.
  • Load the “images\ c6678-le.bin” into memory at 0x0c000000 (type-size: 32 bits).
  • Set the PC register to 0x0c001040.
  • Run all the cores.

 

Please advise

  • Yatsir,

    Our MAD examples and User's Guide use DDR as the load address. Just to verify, have you changed this in your .json files for your application?

    Also, does your application use any MSMC memory? Check the .map to make sure it does not overwrite the MAD memory. It could be that the MAD loader loaded all the cores but overwritten itself before it reached the branch.

    In the meantime, I will double check if there are any limits to using MAD in MSMC.

    -Ivan

  • Hi,

    Thanks for the response.

     

    Yes, I changed it in the JSON file.

    I also tried with the DDR configuration (without the changes) – in this case core0 loaded all the other cores and was stuck in 0x9E008384.

     

    The strange thing is that for some applications the 8 cores booting is working fine, but for other (ex. The CCS template project: IPC and I/O examples --> C6678: MessageQ (single image for all the cores)), using the same configuration, core0 is stuck at 0x__008384 and all the other cores are running.

     

    The MessageQ template project is using the MSMC but is not using the DDR. I am getting the same behavior for both booting methods.

  • Yatsir,

    I am not able to reproduce your errors with the IPC MessageQ template demo. I am loading the MAD image in DDR and not MSMC, and the cores all run to L2 program memory.

    I have attached the files I worked with here. Can you please try it out on your system and check if you can get the same success?

    If possible, would you be able to provide an application that is failing MAD boot?

    -Ivan

    7230.mad-debug.zip

  • Ivan,

    Thanks!

     

    I also tested your version in my system and it is working fine.

     Your configurations are the same as mine.

    I am checking what is causing  the behavior difference.

     

    I will update ASAP.

  • Ivan,

    Thanks to your help, I found the problem… it was related to the “deployment_template_evmc6678l_bypass_prelink.json” configuration file. 

     

    I have another question with your permission,

    As I mentioned before my MAD tool is working with the MSMC (instead of the DDR) – after doing changes in the “mal_app.exe”, “nml.exe” and the json configuration file.

     I wanted to boot  without using the I2C (EEPROM) workaround, therefore I am using the mad2hex (and the other utilities) after the MAD finish his work.

     

    I am burning the file into the SPI NOR FLASH – and the booting is working fine… but very slow (it takes around 3 minutes to boot all the 8 cores).

     How can I configure the rate of the SPI read in the booting process?

    Must I work with the I2C workaround for this?

     

    Thanks.

  • Yatsir,

    I am glad you were able to find your problem with the MAD boot.

    For SPI NOR flash, can you provide me with your romparse table and command? I will check to see if i can find the values you should use for 6678 SPI boot.

    -Ivan

    EDIT: Attached here is the romparse table we use for another SPI boot example. See if these settings work better for you.

     

    section {
     boot_mode = 50
     param_index = 0
     options = 1
     core_freq_mhz = 800
     exe_file = "simple.i2c.ccs"
     next_dev_addr_ext = 0x0
     sw_pll_prediv = 5
     sw_pll_mult = 32
     sw_pll_postdiv = 2
     sw_pll_flags = 1
     addr_width = 24
     n_pins = 4
     csel = 0
     mode = 0
     c2t_delay = 0
     bus_freq_mhz = 0
     bus_freq_khz = 500
    }
    

  • Ivan,

    Thank you for all the help.

    I changed the setting as below and it solved the problem:

     

    section {  

    boot_mode = 50  

    param_index = 0  

    options = 1  

    core_freq_mhz = 800  

    exe_file = "HTR-c6678-le.spi.ccs"  

    sw_pll_prediv = 5  

    sw_pll_mult = 32  

    sw_pll_postdiv = 2  

    sw_pll_flags = 1  

    addr_width = 24  

    n_pins = 4  csel = 0  

    mode = 0  c2t_delay = 0  

    bus_freq_mhz = 20  

    bus_freq_khz = 500

    }

  • Hi guys,

    I would like to ask anyone for help. I solve 8 Cores MAD boot problem similar to the one mentioned above.

    My created MAD binary (it si meant Deployment loader + my user code) works fine with default MAD settings (load address 0x9e000000). But I need to place MAD binary at the end of RAM (in my case 0xbe000000). I changed *.json files and rebuilt mal and nml apps with changed linker *.cmd files (to be placed at the end of RAM too). If I try to boot it always get stuck at address 0xbe008384. I did the same test with address 0x8e000000 with same result.

    After some time of testing I found out strange thing. I accidentally loaded my MAD bin concurrently at addr. 0x8e000000 and 0x9e000000 too (it was prepared for 0x8e...). And set PC reg at 0x8e001040. All cores were loaded correctly.

    I suspect, that there is in mal or nml apps hard coded address 0x9e000000, but I wasn't able to find it.

    Has anyone any experience with this? I appreciate whichever help.

    regards Ondrej

  • Hi Ondrej,

    For the MAL, can you check that in it's makefile (mcsdk_2_01_02_06\tools\boot_loader\mad-utils\mad-loader\mal\malApp\build\Makefile) that you have the variable "LOAD_PARTITION" to the address you want to load it at? If not, please try changing this to 0xbe000000 or 0x8e000000 or wherever you want to load it and rebuild the MAL.

    By default, this value is 0x9e000000.

    -Ivan

  • Hi Ivan,

    thank you for your answer. That is what I looked for.

    Ondrej