• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 65 subscribers
  • Views 1047 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.

UCD3138064EVM-166: CCSv7 and JTAG - problems with debug session on ANY built code

Daniel Havener
Prodigy 90 points
Part Number: UCD3138064EVM-166
Other Parts Discussed in Thread: UCD3138, , UCD3138064

Trying to take a step back from a development board we had made with a UCD3138, I acquired a UCD3138064EVM-166 and an XDS100v2 JTAG pod.

I've now tried various demo projects, example project, lab projects, and "wizard" created empty projects.  They all compile and link just fine. I've setup proper target configurations for the UCD3138064. I can "Test connection" on the XDS100v2 with full success.  Whenever I start a debug session, programming and verification runs just fine. But the debug session stalls / suspends before ever getting into c_init0() or main().

I'll try to throw out some things that seem like possible stumbling blocks to me just getting some code written for the EVM board as a base to add to.

Compile warning:
#10247-D creating output section ".data" without a SECTIONS specification 3138064EVM_Base C/C++ Problem

Console output on starting debug session:

ARM7_0: GEL Output: /nMemory Map Initialization Complete/nARM7_0: GEL Output: /tMemory Map Setup for Flash at Address 0x0ARM7_0: Missing String property "FlashVerboseMode"
ARM7_0: Device Identification (DEV) 0x147F, Device is UCD3138064
ARM7_0: Remapping PFlash to 0x00000000, DFlash to 0x00068800
ARM7_0: Remapping PFlash1 to 0x00008000

The "Debug" dialog window shows that the XDS100v2 is "(Suspended) - 0xE1E1F1C4 (no symbols are defined for 0xE1E1F1C4)"

Disassembly just shows that the "Memory map prevented reading 0xE1E1F1C4"

This same pattern existed in CCSv6.3 with the UCD3138 Training lab projects, and some of the projects from "BidirectionDCDCFirmware-1.2" that I was able to download and try.  What part of setting up a JTAG debugging session on this family of controllers and I missing!?  Thanks for the help!

  • 0
    TI__Genius 13570 points

    Hi, Daniel,

    We will get back to you soon.

    Regards,
    Sean

  • 0
    TI__Mastermind 18370 points
    Hi Daniel,

    Here are two recommendations:

    1) If you are single steping, make sure you use the right one, or use hardware breakpoint instead.

    2) Make sure that the "Rom back door" function in the beggining of your main does not stop the application program from running.
    In most of our firmware examples(including in the labs), certain combination of GPIO pin states invokes this "Rom back door" function".
    When this function is called the control is sent back to ROM and your code will not work.

    Hope this makes sense.

    Regards,
    Yitzhak
  • 0 in reply to Yitzhak Bolurian
    Prodigy 90 points
    Well, no solutions thus far. I've actually reverted all the way back to the Digital Power training series of labs. Built them for the EVM board (166), target configuration correct. I've switched over to using the USB GPIO (PMBUS) pod and connection. So, explain this (I'm starting to think the EVM is just BAD?!).

    UCD3138xxx GUI application:
    1. "Scan Device in ROM Mode" -> Returns great, finds "UCD3138064 Rev 1"
    2. "Scan Device for Program Mode" -> All fail
    3. So, build (no warnings, no errors) the Lab_1 "Hello World" project for UCD3138064 configuration (now back on CCSv6.2 after getting compile/link errors from same lab code in CCSv7, btw).
    4. Go to Debug -> Memory Debugger: just to check IOMUX register and see that PMBUS really seems to be pulling register values
    5. Flash -> Firmware Download -> Select the just build .x0 file. Select; Download data flash (mass erase first), WRITE program checksum, Block 0 (32kB).
    6. Click Download, log shows flash complete (erase, flash, verify, checksum verify in program flash, sends ROM execute command, then Scan for DEVICE_ID fails.
    7. Repeated attempts to get the program to begin execution, fail as it never responsds to a DEVICE_ID request!

    Now, to go further down the rabbit hole.
    8. Go to Flash -> Flash Test Tool: Test "Data Flash Only", PASS
    9 Test "Program Flash Only", complete FAIL!!!

    So, what gives here guys! I've read through documents and watched videos numerous times, and not seeing ANYTHING I've done wrong to make this device completely and totally unuseable. Please help!
  • 0 in reply to Daniel Havener
    TI__Genius 17090 points

    6740.converting to 6.1.docxHere are some guidelines that you may want to check the code against:

  • 0 in reply to Daniel Havener
    Prodigy 90 points
    So, I think we can close this issue (somewhat). The problem with the 3138064EVM-166 and the Digital Power Lab examples is rooted in the
    clear_integrity_word() function. If you do NOT get FAULT3 properly grounded (as they note in the Lab code itself), the main code will immediately call that function and "crash". It will not fall into the main loop, thus no PMBUS handler is running, thus the UCD3138xx GUI will never get a DEVICE_ID response.

    I'd still like to know why the above function is causing problems. And looking back at the UCD3138xx GUI utility, once I've got a program running and can be found by Scan on DEVICE_ID, the "Flash->Flash Test Tool" is disabled. I'd still like to understand why I had the EVM in a mode that would pass the Data Flash tests, but fail the Program Flash tests?
  • 0 in reply to Daniel Havener
    TI__Genius 17090 points
    In the first case, the code should go back to ROM mode, so if you do a scan for ROM mode, it should find it. If that's not happening, make sure that zero_out_integrity_word.c is being compiled in ARM mode, ie. 32 bit mode. Right click on the file name in CCS and then select Build Options.

    The reason you can't test the flash when Device ID is working is because the program you download is running in flash. Can't test it while it's being used. You have to go back to ROM mode for that. Then you are running from ROM.