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.

Can flash standalone CC3200, but cannot run Blinky or OOB - advice?

Other Parts Discussed in Thread: UNIFLASH, CC3200, ENERGIA

I was wondering if there was a specific forum or documentation/advice for people having issues bringing up their CC3200 standalone custom boards? I am able to run Uniflash successfully to format, load a service pack, and reprogram the chip + memory, but am unable to determine if the program is actually running.

What documentation do you all use for debugging these things? Sorry to ask such a broad question, I'm hoping there's some wiki page I just missed.

  • Hi,

    There is no specific document for debugging application for custom boards. By the way, are you able to run any of the application directly from the Serial flash?

    For debugging, you would need CCS IDE with JTAG on the custom board. You can also take a look at a similar discussion e2e.ti.com/.../398958.

    One other way to check the initialization would be to see the application logs on the Tera Term.

    Regards,
    Raghavendra
  • Hi Raghavendra,

    Thank you for your reply!

    I am able to flash the programs using Uniflash, but I cannot tell if they are running - there is no wifi, and I cannot get the LEDs to blink. So I assume they are not running. I will check TeraTerm, though, and see if anything comes back. Thanks for the suggestion!

    I do have the four JTAG pins on the custom board, but the CCS debugger hangs before entering the main function in the code.
    From reading the forums, perhaps we need a JTAG emulator to have this work with the CCS debugger? Is there a way to have it work with CCS without a separate JTAG emulator?

    thank you very much,
    Yoo-Yoo
  • Unfortunately nothing comes back on TeraTerm with the OOB flashed application, and the CCS debugger is still hanging.

    Any suggestions for things to try would be very appreciated!
  • Hi TI,

    I'm a FW engineer working with Yoo-Yoo.  I'll try to outline some of the experiments we've tried / things we've observed.

    1. Trying to boot from SPI
      1. We are able to format the SPI from UniFlash
      2. We are able to load the 1.1 service pack
      3. We are able to flash out-of-box demo and our own blnky demo (we've moved the GPIO from LaunchPadXL Leds on 9,10,11 to GPIO 1, 30, 31 on our board -- yes, 1 is the UART0 TX, which we may want to change... The LED is not tied directly to the pin, we have FET in there to drive the LED)
      4. When we reboot after flashing, leaving SOP2 disconnected, and so, pulled low, the device appears to load a program from SPI, but we never see the LEDs blink or the OOB demo smartconfig or present an AP if we do the SW3/SW1 dance outlined in SimpleLink start app for Android to force AP mode.
      5. We see CS on the SPI, and we see a bunch of data shifting out, but we the code appears to not run.  No GPIOs toggle.
    2. Trying to run from CCS6.1 using JTAG debugger
      1. We have jumpered the 4 JTAG signals, RESET, and the 2 UART lines from a LaunchPadXL over to our board.
      2. From CCS, we are able to connect to the cortex_m4_0 because if we don't hook it up, we don't get this far.
      3. We "start" our program by clicking on Debug, and what we see in the CCS console is:
          1. Cortex_M4_0: GEL Output: 
            Memory Map Initialization Complete
            Cortex_M4_0: GEL Output: 
            Target Reset
      4. At that point, CCS debug session hangs
      5. If we look at TDI/TDO/TMS/TCK at this point, we see periodic bursts of activity, every couple of seconds.  This continues on indefinitely as far as we know.  We never see "unable to connect to device" or anything like that.
      6. These debugger results are the same if we have SOP2 connected to high or not

    3. Note, we are using the Macronix MX25L12835F, but we believe this is a compatible device.

    It feels like we are being hung is some software reset state, either debugging or booting from SPI.  Our reset signal has 100K and 0.1uF on it.  We've also brought reset over from the LaunchPadXL, because the Emulation Circuit seems to want to drive RESET.

    • Is there a way for us, using CCS or UniFlash, upload the contents of SPI or the /sys/mcuimg.bin file so we can verify that indeed our program is loaded?
    • Is there any debugging or log output from CCS debugging that might say more than just "Target Reset"?

    Thanks for reading this very long comment,

    Robert

  • Hi Robert,

    What indications do you have that a program is running after flashing via Uniflash? Are you able to share your schematic?

    Thanks,
    Aaron
  • This appears to be similar to my problem. The debugger hangs when trying to debug. Try pressing the pause button, then restart button then pause again. In mine it is stuck in rle_decompress_core. I think the project needs some change for the R1 version versus the pre production versions found on the eval boards? What to do about it, I don't know yet.
  • Hi Aaron,

    Well, my proof is indirect and may be wrong.

    In one respect, code from flash is NOT working...App code (blinky, provisioning_ap, oob) are not showing any signs of activity.

    So my evidence that code runs at all is that Uniflash handshakes with the board, fetches the version numbers, formats, and programs.  AFAIK, this requires code in the ROM to execute correctly because the UART is the only input from Uniflash.  But this is speculation on my part.

    As I write you now, I realize I need to retest to see if the Program step shows the same Verify messages as it does on the LaunchPad.

  • I have found that there is linker command file in the project which allows selection of "cc3200v1p32.cmd" or "cc3200R1.cmd" . In this file the location and size of code and ram differs according to which version of cc3200 you are using. This would most likely cause code not to run correctly when the incorrect linker file is used. I have tried with the cc3200R1 linker file but it still does not work. Not sure what other steps to take to account for the differences in production and pre production IC's?
  • Further Update. To confirm my suspicions this is a software setup problem I swapped the pre production IC on the eval board with the cc3200R1 IC. I tried to debug this board, (which with the pre prod device worked) does not now debug and gets stuck in the same place as with my own design PCB. This verifies the problem lies squarely with configuration of the code for the specific IC used. Again I have changed the linker command file to no avail. Can someone please tell me how to change the project to support the cc3200R1?
  • I found this forum post useful: https://e2e.ti.com/support/wireless_connectivity/f/968/p/406244/1487706#1487706

    We were able to get the debugger working using the Energia software within CCS, but not the SDK code within CCS.  The Energia code, based on the ifndef comments seems to be built for the CC3200R1M1 .

    Will dig into potential reasons later.

  • My problem and probably this one relates to the use of the cc3200R1M1 not cc3200R1M2.
    The M1 variant only has 128K RAM where M2 variant has 256K RAM.
    The linker file needs to be changed to "cc3200R1.cmd" and then edited like this
    SRAM_CODE (RWX) : origin = 0x20004000, length = 0xE000
    SRAM_DATA (RWX) : origin = 0x20012000, length = 0xE000
    This will make the RAM line up with the cc3200R1M1.
    Would be nice if TI could change the name of cc3200R1.cmd to cc3200R1M2.cmd
    and add another file cc3200R1M1.cmd so people can choose the right one.

    Happy hunting!
  • I saw one line about this in the swru369b data sheet! But I haven't had time to try it out.  Did that make everything work for you? If so, that is AWESOME.

  • Yes, this makes it work.
    However you might like to try
    SRAM_CODE (RWX) : origin = 0x20010000, length = 0x10000
    SRAM_DATA (RWX) : origin = 0x20000000, length = 0x10000
    putting data first means you can overlap the ram used by bootloader, and get some more space, otherwise you might not be able to fit the simplink library in. This chip is quite limited in space and might only be suitable for some applications. Might want to use M2 variant for larger projects.