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.

AM437x IDK - sysbios_ind_sdk 02_00_00_02

Other Parts Discussed in Thread: SYSBIOS, AM4379, TMS320C6678

Issue: sample programs not able to start vie IDE

Hardware: TMDXIDK437X Rev: A

CCS: 6.1

SDK: AM437x_sysbios_ind_sdk ... 02_00_00_02

SYSBIOS 6.40.3.39 Real Time Operating System

xdctools_3_30_04_52_core_win32_nojre

Compiler GNU v4.7.4 (Linaro)

Build: ok

Gel: runs ok

program (led_toggle) load: ok (main label visible in ASM)

cpu runs after download, no JTAG control, no breakpoints possible

Target configuration Connection Test: ok, no errors

wondering: project settings show Generic CortexA8 Device (should it not be CortexA9?)

tried other variant (Generic Cortex A9 Device and IDK_AM437x [Cortex A]), but build failed

Viewing various Memory locations also failed.

I have three suspicious aspects then

a) the JTAG connection/settings

b) the project build settings (which are the original ones from the IDK SDK)

c) platform does not match SDK

appreciate some comments in case anyone also works on the AM437x IDK

thanks

Thorsten

  • Thorsten Gonschior1 said:
    cpu runs after download, no JTAG control, no breakpoints possible

    At this point, can you do a "Suspend"(Pause symbol) and a "Restart"?

    Regards,
    Vinesh

  • Vinesh, thanks for your reply.


    - resume and suspend is possible (still no breakpoint)
    - CPU goes to resumed mode after program download
    - PC is always 0x00030004 when suspended afterwards. code in that address is "00030004: E59FF018 LDR PC, 0x30024".
    Single stepping remains in that location. 0x30024 is not loaded to the PC. but ... I am not an assembler guy :/

    Debug Probe denotes:
    Texas Instruments XDS100v2 USB Debug Probe_0/CortexA9 (Suspended)
    0x00030004 (no symbols are defined for 0x00030004)


    - main program is @:
    .text.main 0x80002024 0x80 ./led_toggle.o
    0x80002024 main
    Disassembly:
    main ()
    -> 80002024: E92D4800 STMFD R13!, {R11, R14}

    How can I determine the CPU behaviour, when it directly starts resumed mode after download (starting Address for example)

    For F28 DSP I have a similar problem in mind when AET(?) Resources blocked breakpoint setting.

    Since this is an LED toggle program and I dont not see any toggling LED it may indicate that the program is not operating ;) @last one definitive observation :)
  • Thorsten,

    Did you try a restart after Suspending the core(after loading the app?) processors.wiki.ti.com/.../AM437x_SYSBIOS_Industrial_SDK_Getting_Started_Guide

    Regards,
    Vinesh
  • I did the launch exactly as described in the getting started guide plus some variations with the cpu and system reset.
    still wondering about the platform settings. Tried to start a new project but neither the IDK nor a generic AM473x Cortex A9 is available.
  • We had a number of problems getting reliable JTAG debugging on the AM437X IDK EVM. I have previous posted about these, you can probably search.

    The key issue was that CCS 6.0.0 was not resetting the board properly. I don't know if this has been fixed since. So "System Reset" was generally doing something unhelpful which confused the emulation logic and locked everything up. The SDK notes recommend "Restart", as Vinesh has quoted, but that does not reset the SoC or put it in a known state.

    Our workaround was to disconnect, reset the board using the reset button (or power cycle) and reconnect every time we wanted to load code. Make sure the "reset on connect" setting is cleared. This did seem to work reliably for us as long as the engineers were disciplined in following the steps.

    Gordon
  • Gordon, thanks for your reply. I will check that.


    I am still wondering about the project settings issue (wondering: project settings show Generic CortexA8 Device (should it not be CortexA9?))


    Thorsten

  • Some of the IDK projects are like that for me too, while others use "AM437X [Cortex A]" targets. However, I don't think that switch by itself affects code generation - GCC's target is specified under 'GNU Compiler > Runtime', and RTSC's under 'CCS General > RTSC' if using RTSC. Debugging config is specified in a combination of the .CCXML target file and the Debug Configuration settings in your workspace. I think the target you're talking about triggers auto-generation of the .ccxml but not much else (?)

    If you didn't produce your own CCXML but just used one from CCS or the IDK, I would definitely recommend going through the steps to produce your own, even for the EVM. Or at least change to the "EVM437X" (GP) or "IDK_437X" (IDK EVM) to get something sort-of appropriate automatically.

    Also, I don't trust CCS' "upgrading" of project files from earlier CCS versions much, especially for RTSC project. For your own apps, I recommend trying to produce your own from scratch on the CCS version you plan to use.
  • no autogeneration, I built my own target file and the JTAG test validated the connection. Your are probably right with your suggestion building the project from scratch without wizzard. Nevertheless, the non-halting @ main remains a pain i.t.a. problem after all ;)
  • Oh, and I should mention the mode problem.  We got *much* better results when we forced the processor modes on boot, including disabling thumb mode.  GCC sets thumb/not thumb for you later anyway, and you probably set up the MMU yourself.  By "much better" I mean faster JTAG start times and fewer random crashes.

    The required function AM43xxStartState() is in TI's supplied GEL files, but for some reason it's invocation was commented out in the GEL in the CCS version we were using.  We use:

    //this function changes certain states of the processor to 
    //allow proper access from CCS.  May not be needed in all situations
    hotmenu AM43xxStartState()
    {
      CPSR &= ~0x20;				 //set to ARM mode
      CPSR = (CPSR & ~0x1F) | 0x13;  //set to privledged mode
      REG_CTXA9_CP15_C1_SCTLR &= ~0x1; //disable MMU
    }
    
    OnFileLoaded()
    {
       AM43xxStartState();
    }
    
    OnRestart()
    {
       AM43xxStartState();     
    }
    
    OnReset()
    {
       AM43xxStartState();
       Disable_Watchdog();
    }
    
    OnTargetConnect()
    {
        AM43xxStartState();
        AM43xx_IDK_EVM_Initialization();
        Disable_Watchdog();
    }
    

    We haven't worked out what the comment "May not be needed in all situations" actually translates to.  Your Mileage May Vary.

    Our own A9 project is on hold at the minute, so this is all stuff we did months ago.  Good luck!

  • why is your A9 Project on hold? (If I may ask :) ) Are there further issues, show stoppers? We are currently developing our own embedded platform basing on the AM4379 and its architechture is closely derrivred from the IDK. Since we have no hardware yet I am trying to work with the IDK instead. I am experiencing a number of aspects where the information available is not that good as it is for other TI products. I am working for about 20 years now with TI embedded technology and my current issues are not verry encouraging.
  • I can't say too much. We found that our application is likely to be more CPU intensive than we had originally thought, so we're probably targeting another chip architecture. We remain interested in TI's A15-based Sitara (eg. as announced for the BeagleBoard X-15) though we have not been able to get any early silicon for that.

    I say 'on hold' because there are circumstances where we might go back to an AM437X for part of our product. On paper it's a very appealing chip.

    Our change in scope isn't anything to do with TI, but it is fair to say that we were disappointed with both the software support at the present time (both IDK and CCS - all this pain with JTAG debugging) and with the benchmark results. The AM437X under SYS/BIOS was substantially slower than a single core of a Freescale iMX6 at the same clock speed, which we hypothesise might be L2 cache related, since the A9 core is nominally very similar. The AM437X under Linux does somewhat better, perhaps because the cache settings are somehow better. (No idea why). Because of the change of direction we have not had time to investigate or to work through these issues with TI. The IDK 2.0.0 does not have any benchmarks so we wrote our own application specific ones, which I don't think I can publish.
  • thanks, thats good enough :) our applications is a very close real time one and after understanding that the main core is absolutely not suitable for RT, which is why we do not apply the SysBIOS, I hope that we can manage this with the PRUs. Cache ist probably one of the main, advantages or disadvantages of this SoC, depending on what you are targeting :) I will drop a note when I will be able to fix this issue here. If you have some direct questions regarding the BIOS performance I would provide some insights from my application with a F28 and DSP/BIOS. TI mentioned that almost noone applies a BIOS @ a 28x because of performance issues, but I managed to apply a 2ms time slice scheduling multithread system with multiple industrial communications protocols (CAN, EtherCAT, Profinet) plus high power controller app @ the same time. I think that the PRUs are also a good processing power source, once reasonally applied.
  • I have previously used SYS/BIOS 6 on a TMS320C6678 (Keystone I DSP) and liked it very much.  The cache controller on the C6678 was great - very fast and predictable. The C66 DSP cores were essentially deterministic too as long as you avoided DDR loading.  The A9 takes a bit more getting used to.  If Keystone II chips were cheaper we would potentially have leaped from Sitara to those. 

    The PRU is indeed an interesting technology - we were hoping to use one for industrial Ethernet comms independent of the main CPSW GMAC.  Firmware for that is one of the things not released for the AM437X yet, though TI say it's in progress.  Unfortunately the MACs within the PRUs are not officially documented which put us off rolling our own.