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.

Boot_defaultLimpAbortFunction

Dear TI E2E community,


i have a problem with concerto F28M35H52.

We have built our own pcb with Concerto F28M35H52, we have rebuild the Concerto Controll Card on our own pcb.

For flashing and debbuging we use a XDS100v2 from TI and connect it with the JTAG connecotor.

When we flash the M3 controller it runs in "Boot_defaultLimpAbortFunction"

We have test the Quarz and the Quarz work correctly.

When we flash the same programm on a Controll Card everything work very good.

In appendix the schematic of our pcb.6567.Concerto integration.pdf

Have you any idea that we can do to solve the problem?

Thank you very much.

Best Regards

Sebastian Hörlin

  • Hello,

    I will look more into your issue. In the meantime, can you let me know what version of TIRTOS are you using?

    Gilbert
  • Hello,


    I use the TIRTOS version "tirtos_c2000_2_12_01_33" and the Code Composer V6

    Regards

    Sebastian

  • Are you using one of our examples in Code Composer's Resource Explorer to flash onto the M3 or your own custom program?
  • Dear Gilbert,


    I use my own code to flash the controller.
     I habe tested this code on a controll Card and it work very good.


    Best regards

    Sebastian

  • Hi Sebastian,

    Can you try one of the examples from resource explorer and see if you run into the same issue?

    Gilbert
  • Hi Gilbert,


    we have test it with an TI example (the big dual core demo with webserver etc..)
    With standard Target Configuration we can not flash the C28. We have the following report

    For our own projects, we always use a modified target config (see appendix) - with this file, it worked.

    Afterwards, we tried our old program again, and - it works! BUT WHY?

    The project is for an industrial customer, and we can not deliver when this issue is not 100% fixed. What if this happens with every controller chip?

     

    I hope you can help us

    Thanks and regards.

    Sebastian

     

     

    ----------------------------------------------------------------------------------------------------------------------

    <?xml version="1.0" encoding="UTF-8" standalone="no"?>
    <configurations XML_version="1.2" id="configurations_0">
    <configuration XML_version="1.2" id="Texas Instruments XDS100v2 USB Emulator_0">
            <instance XML_version="1.2" desc="Texas Instruments XDS100v2 USB Emulator_0" href="connections/TIXDS100v2_Connection.xml" id="Texas Instruments XDS100v2 USB Emulator_0" xml="TIXDS100v2_Connection.xml" xmlpath="connections"/>
            <connection XML_version="1.2" id="Texas Instruments XDS100v2 USB Emulator_0">
                <instance XML_version="1.2" href="drivers/tixds100v2icepick_c.xml" id="drivers" xml="tixds100v2icepick_c.xml" xmlpath="drivers"/>
                <instance XML_version="1.2" href="drivers/tixds100v2cs_dap.xml" id="drivers" xml="tixds100v2cs_dap.xml" xmlpath="drivers"/>
                <instance XML_version="1.2" href="drivers/tixds100v2cortexM.xml" id="drivers" xml="tixds100v2cortexM.xml" xmlpath="drivers"/>
                <instance XML_version="1.2" href="drivers/tixds100v2cs_child.xml" id="drivers" xml="tixds100v2cs_child.xml" xmlpath="drivers"/>
                <instance XML_version="1.2" href="drivers/tixds100v2c28x.xml" id="drivers" xml="tixds100v2c28x.xml" xmlpath="drivers"/>
                <platform XML_version="1.2" id="platform_0">
                    <instance XML_version="1.2" desc="F28M35H52C1_0" href="devices/f28m35h52c1.xml" id="F28M35H52C1_0" xml="f28m35h52c1.xml" xmlpath="devices"/>
                    <device HW_revision="1" XML_version="1.2" description="" id="F28M35H52C1_0" partnum="F28M35H52C1" simulation="no">
                        <router HW_revision="1.0" XML_version="1.2" description="ICEPick_C router" id="IcePick_C_0" isa="ICEPICK_C">
                            <subpath id="C28x">
                                <property Type="numericfield" Value="0x11" desc="Port Number_0" id="Port Number"/>
                            <cpu HW_revision="1.0" XML_version="1.2" description="C28xx CPU" deviceSim="false" id="C28xx_0" isa="TMS320C28XX">
                                    <property Type="filepathfield" Value="" id="GEL File"/>
                                </cpu>
                            </subpath>
                        <subpath id="M3">
                                <router HW_revision="1.0" XML_version="1.2" description="CS_DAP router" id="CS_DAP_0" isa="CS_DAP">
                                    <subpath id="CortexM3">
                                        <cpu HW_revision="1.0" XML_version="1.2" description="Cortex_M3 CPU" deviceSim="false" id="Cortex_M3_0" isa="Cortex_M3">
                                            <property Type="filepathfield" Value="..\..\emulation\gel\f28m35h52c1_m3.gel" id="GEL File"/>
                                        </cpu>
                                    </subpath>
                                </router>
                            </subpath>
                        </router>
                    </device>
                </platform>
            </connection>
        </configuration>
    </configurations>

  • Can you explain why you are using a modified target config file?
  • Dear Gilbert,

    We are working with TI’s Concerto chips since 2011/12. In the beginning, there were some bugs, for example, the PWM frequency: When connected with the debugger, it is only half the frequency than when starting directly from flash. Very strange effects! So there was this page in TI’s wiki:

    http://processors.wiki.ti.com/index.php/Concerto_Dual_Core_Boot#Debugging_Flash_Dual-Core_Boot

     

    Sadly, this page has now been deleted, but there it was explained how to create a modified target configuration file for Dual Core Flash Boot applications, and we have never had any problems using this target configuration file.

    And even now, with this new board: The standard target config did not work, but this one did. With TI’s own demo example.

    Best regards,

    Sebastian

  • After getting some feedback from some other engineers, it seems like the issue isn't directly caused by TIRTOS. Your original issue of the Boot_defaultLimpAbort() is caused by a clocking fault from losing the OSCCLK. If you were able to create a working example with your modified target config file, then I'm not quite sure what the issue is. It might be better to borrow the knowledge of someone from the device forums:
    e2e.ti.com/.../171

    Regards,
    Gilbert