CC3200: Flashing Chip With External Debugger

Hi Justyn,

Are you sure the sl_Start hang is debugger related? Try running your program without debugging and toggle and LED after sl_Start to see if it's getting past it.

Jesu

Hey Jesu,

I'm sure it's debugging related.  My program is very loosely based on the TCP Socket example, and the whole system works perfectly fine when flashing via Uniflash.

I know it's hanging on sl_Start because I have prints around it.

I meant to hit "reply", not "This resolved my issue".  This didn't resolve my issue.

I think you're confused.  When I say "flash" or "debug", I mean via the external SEGGER JLink.  In order to debug embedded code, the code first needs to be flashed onto the platform, in my experience.  I am neither able to "debug" or "flash" the CC3200 chip.  I'm not using CCS in any capacity.  I'm aware that a reset will wipe anything in SRAM.  What about resetting the board and halting on startup to guarantee the NWP is reset before flashing and jumping to the image in SRAM?  Is there a specific reset strategy I should use as outlined in the attached document above, etc.

Those are the things I'm trying to figure out.

If I knew the steps that CCS took to program the board for debugging (when does it reset, when does it load, where does it jump to, etc), I could use that as a basis for programming my board.

Hi Justyn,

Okay so you're just trying to figure out how to setup your jlink debugger. Since you are not using CCS what SW are you using to debug? Also, please share the connection you have from Jlink to the device. As far as I'm aware you shouldn't have to make any changes to the Simplelink library to get your debugger working. 

Jesu

Hi Jesu,

I'm going to use the JLinkGDBServerCL program and attach a GDB debugger to it.  However, this is not the problem.  My connections are fine to the device, otherwise the JLink program wouldn't be able to identify the processor.

Please recall the problem is when I attempt to flash the image onto the chip, the program hangs on sl_Start.  If I program the board through Uniflash, it works fine, but programming through JTAG does not.  The NWP is not getting reset correctly/gracefully.  Can you provide any feedback in that regard, or forward my issue to someone who might know a solution?

How does CCS flash the board for debugging?  When does it send a reset command?  When does it halt after resetting, before or after the ROM bootloader?  What type of reset command does it perform?  Is it possible to see a log of what CCS does when attaching/flashing/debugging the target board?

Does it work if you debug it through CCS? This could indicate if it's an issue with JLinkGDBServerCL.

Jesu

Jesu,

As I mentioned a few times above in this thread, the issue is not with debugging.  Right now, I'm trying to flash the chip with JLink, and the program hangs on sl_Start.  This is because the NWP is not resetting gracefully.

Can you answer any of the following questions:

How does CCS flash the board for debugging?  When does it send a reset command?  When does it halt after resetting, before or after the ROM bootloader?  What type of reset command does it perform?  Is it possible to see a log of what CCS does when attaching/flashing/debugging the target board?

If not, can you please forward this to a subject matter expert?

Justyn,

I find it difficult to understand you when you use flash and debugging interchangeably.

In response to your question below:

How does CCS flash the board for debugging?

CCS does not flash our board for debugging. It writes your application directly to RAM for the MCU to execute. For flashing the device, you need a UART interface to the MCU or SPI interface directly to the flash. You can also conveniently use Uniflash which flashes via UART. Please refer to our production line guide if you would like to learn more.

If you still wish to find the answers to the rest of your questions in your previous response, I recommend you try using a logic analyzer to see how reset is controlled. I am not aware of any documents that discuss CCS protocol for launching debug sessions. More so, I would imagine these protocols are specific to the debugger HW given the connection has to be specified by the target config file.

Jesu

I see what the confusion is:

"CCS does not flash our board for debugging. It writes your application directly to RAM for the MCU to execute"

That is what I refer to as "flashing" the chip.  What would you call that?  I did not mention anywhere in my original post or otherwise that I was flashing the SPI memory.  In fact, if you go back and read the original post, I thought it was clear that I'm loading the binary into SRAM and changing the program counter to execute from ResetISR, please re-read that.  The program is hanging on sl_Start, which I still don't know why.  And I guess the answer is "figure out what CCS is doing yourself."

Thanks for the help.

Justyn (jbEE),

I do not find it productive to go over who said what. I only made that remark so we could establish some level of understanding between us.

For your information, our device architecture does not allow the device to be flashed when launching a debug session unlike other MCUs. The architecture is designed this way for security reasons but that's besides the point. Generally, flashing implies you are writing to flash memory so I hope it makes sense how it could be confusing since our debugger is writing directly to RAM.

"That is what I refer to as "flashing" the chip.  What would you call that?"

I would simply say debugging. Anyone who understands our device would know what is going on. 

I would like to help you it has just been difficult to understand what is going on. I hope we are on the same page now when I say you are simply trying to figure out why sl_Start gets stuck when debugging but not when you flash the device. Please confirm before we move on.

Jesu

Fair points.  I will not use the term "flash"; it looks like the term that you guys use is "memory load".

I took a step back, installed CCS, and tried to debug the TCP example for the CC3200, with the SEGGER JLink target, using the debug library, as advised in this thread:

However, it is hanging in the sl_Start call within ConfigureSimpleLinkToDefaultState call which is the exact same thing that's happening when I try to debug from outside of CCS.

Can you please verify that the TCP example with no-os does/does not debug on your end?  Am I forgetting to do something?

ALSO: After waiting a long time, I get the following error at my UART output after sl_Start hangs for a long time:

I think whatever gets this to work from within CCS will also solve my non-CCS issues.  Any advice?

I also tried just importing the Simplelink CCS project into CCS and building with target Debug (as suggested in the above linked thread).  Verified simplelink.a was built (timestamp), and it still doesn't work.

Hi,

If you talk about issues with sl_Start() during debug session, few thing comes to my mind:

• I suppose that you have own hardware, right? Do you have available any kind of TI LaunchPad with TI XDS-100 or XDS-110 debugger? Can you test this debugger with CCS?
• How do you power your board? I think JLink is not able to provide sufficient current for PHY calibration during sl_Start().
• What do you mean by hangs at sl_Start? It does mean that debug session is terminated or code execution "stuck" at some state but code is still running and debug session is still live?
• If you want to know if you have same issue same as described above, please follow steps (all steps are important):
  
  1. Connect your hardware and debug probe
  2. Using Uniflash software perform format of sFlash, upload of latest Servicepack, do not upload your MCU binary
  3. After successfully SP programming set proper SOP mode (e.g. 0-0-0) and restart your board (use physical reset of CC3200)
  4. Try connect your debug session
  5. If you will be able goes through sl_Start(), that you have a same issue as is described above thread.

BTW ... what part-number is marked at your CC3200 QFN chip? It is not a XCC3200?

Jan

Hi Jan, thanks for following up.

1) Yes, I'm using a CC3200-LaunchXL dev board.  The same one as this: www.ti.com/.../CC3200-LAUNCHXL

2) I power via the Micro USB connection to the LaunchXL board.

3) Code execution is stuck for a long time.  When I try to debug my program, I put a print before and after the sl_Start call, and can see only the print before gets called.  In CCS, I place an actual breakpoint before and after the sl_Start call and can stop before the sl_Start call, but it never reaches the one after (until a very long time after, it spits out an error over UART as described above).

4)

It appears the default debugger on the LaunchXL board is the Stellaris in circuit debugger, is that right?

I'm a little confused about this.  This must not be the right part.  Which connection should I choose, because this doesn't work.

The part number on the package of the chip is CC3200R1.  Do you need the other numbers?

Hi,

Please provide photo of your LaunchPad when you try to use on-boad debugger. I want to check your jumpers settings.

• settings of your target configuration in CCS looks OK
  
• did you changed SOP mode and press restart button after Uniflash programming?

Jan

Good catch.  My external SEGGER debugger was still plugged in.  I reattached the jumpers across TDO, TDI, TMS and TCK and the Stellaris debugger works.

It successfully makes it past the sl_Start call.

However, this is definitely not the workflow I'm interested in because

1) It looks like I have to close my serial connection (Putty) to the board in order for the debugger to work.

2) In the future, I would like to create a custom board with the CC3200 part on a PCB with JTAG/SWD straight out from the CC3200, and no XDS emulator/FTDI chip.

Hi,

OK, now we know that development with CCS and XDS-100 worked at your case without any isse. Also we know that you are using LP. From this reason we know, that your issue is not a hardware related (you have production version of LaunchPad). These information we did not know before. From this information it looks that your issue is really related to J-Link itself. Unfortunately I can't help you with this, because I haven't J-Link  available.

BTW .... nothing prevent you to connect XDS-100 from LaunchPad to your own board as will be available.

BTW2 ... from my point of view it not sounds me a reasonable to start new project based on CC3200 chip. Because CC3220 or CC3235 chips are available. These chip are much better then old CC3200.

Jan

Hi,

Glad to hear that you was able resolve your issue.

Jan