CC3200 + Linux: Trying to run getting_started_with_wlan_station

Darius,

Don't get much clue from the above log. Could you share the OpenOCD log file when debugger gets stuck in prvPortStartTask(). 

Also, can you please run cc3200-sdk\examples\blinky application and see if it runs successfully.

Regards,

Kaushal

Darius,

      Do you have any application already flashed on your LP? If yes, can you pls put SOP2 Jumper and try again ?

Thanks and regards,

Praveen

 

Sorry for the delay.

Hello Kaushal,

The excerpt is from exactly the point in time where the debugger gets stuck. The debugger getting stuck is caused by an interrupt, which I first experience, when the `svc` instruction is reached. According to documentation that I found, the lockup after double fault can be caused by trying to execute the `svc` instruction in the hard fault or NMI interrupt handler. But that isn't the case here. I really don't understand what is going on.

Here is the full content of the openocd.log file:

adapter speed: 1000 kHz
Error: session's transport is not selected.
Info : session transport was not selected, defaulting to JTAG
cc3200_dbginit
Info : clock speed 1000 kHz
Info : JTAG tap: cc3200.jrc tap/device found: 0x0b97c02f (mfg: 0x017, part: 0xb97c, ver: 0x0)
Info : JTAG tap: cc3200.dap enabled
Info : cc3200.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection from pipe
undefined debug reason 7 - target needs reset
invalid command name "delay"
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000062, MEM_AP_TAR 0xd6dffc94
Error: Failed to read memory at 0xd6dffc94
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000062, MEM_AP_TAR 0xd6dffc94
Error: Failed to read memory at 0xd6dffc94
Error: cc3200.cpu -- clearing lockup after double fault
Polling target cc3200.cpu failed, GDB will be halted. Polling again in 100ms
Polling target cc3200.cpu succeeded again, trying to reexamine
Info : cc3200.cpu: hardware has 6 breakpoints, 4 watchpoints

This is up to the first SIGINT, when I run it again, below lines will be added for each time I hit run.

Error: cc3200.cpu -- clearing lockup after double fault
Polling target cc3200.cpu failed, GDB will be halted. Polling again in 100ms
Polling target cc3200.cpu succeeded again, trying to reexamine
Info : cc3200.cpu: hardware has 6 breakpoints, 4 watchpoints

prvPortStartFirstTask:
20009d58: ldr r0, [pc, #12] ; (0x20009d68)
20009d5a: ldr r0, [r0, #0]
20009d5c: ldr r0, [r0, #0]
20009d5e: msr MSP, r0
20009d62: cpsie i
20009d64: svc 0

The pc is at 0x20009d64, right at the `svc` instruction.

The blinky application runs just fine. So does the WLAN station example up to the `svc` instruction.

Hello Praveen,

The SOP2 jumper is in place and LP is flashed with the out-of-the-box application. I haven't flashed anything myself.

I want to thank both of you a lot for your support. I try to be as informative as possible, but currently I don't know what to try next.

Maybe you could send me a binary that runs on your LP and I could try that one? If it would work I could try to spot where the differences are.

Best regards,

Darius

Hi Darius,

Apologies for diverting your post, but I see you have been able to get the CC3200 working with Eclipse on Linux.

I have had reasonable success with CCS on Windows (under duress) but would like to move back to my preferred Ubuntu environment.

I have Eclipse Kepler installed and working with J-Link etc, but having problems getting anything going with the CC3200/Linuc. Any chance you can help with some pointers to get going?

Thanks in advance

Andre

Hi Andre,

No problem. I have created a document that should provide the necessary instructions for you here: https://gist.github.com/dariuskl/086823c781bfb61af361. If you still run into problems, feel free to contact me here or at GitHub.

If you succeed to build something for the CC3200 that includes FreeRTOS and actually works, please report here. That might help me with my problem!

Best regards,

Darius

Thanks Darius, will give your HowTo a try this weekend.

Regarding the FreeRTOS question, what problems are you having. I have gone trough a LOT of pain for a period of about 2 weeks but, touch wood as they say, it has been running extremely well the last 2 weeks. Only problems I still have are related to I2C hangups, but the rest keeps running well.

Drop me an email and I will try to help.

Andre

Did you ever get further with this?

I am having this exact problem, except I'm using the cygwin environment as suggested in the programmers manual.

Hi Kristian,

Unfortunately not. I am currently waiting for the new SDK release, which is supposed to be published in the next few days.

The most plausible explanation for this behavior would be that something goes wrong during the linking process. At least that's currently the only thing I can think of, that I haven't already ruled out. To verify this it would be handy to have a working binary of any application that uses FreeRTOS, but I don't really have time to set up a Windows environment at the moment (and won't have for the next few weeks probably).

If you happen to solve this problem or have any idea what else to try, please let me know.

Best regards,
Darius

Hi Darius,

I have the same problem. The interesting thing is that if I flash the getting_started_with_wlan_station example to the board it works fine. But if I run it with arm-none-eabi-gdb execution stops in prvPortStartFirstTask with SIGINT. So looks like the problem is not in linkage but probably it's related to gdb.

Hi Konstantin,

This is a very interesting remark! It might be possible that interrupts have to be disabled in this section of the code and gdb forces them to be processed. That gives me some hope again, that I might someday actually use the CC3200 for something productive.

I will report back as soon as I found out more.

Another thing that I noticed is a string "undefined debug reason 7 - target needs reset" in openocd.log. So I tried to hard reset the board then run gdb. And it was running continuously then. However when I manually interrupted execution, it appeared to be running the infinite loop in FaultISR () at ../../common/startup_gcc.c:279

According to comments in the source file: "This is the code that gets called when the processor receives a fault interrupt. This simply enters an infinite loop, preserving the system state for examination by a debugger."

So it really seems like something wrong with interrupts. But why then it works when flashed into the board?

P.S. I also tried to use newer openocd (0.8.0), but all is the same.

Hi Darius,

I have not yet had ANY success with getting CC3200 code build using Eclipse on Ubuntu working, and close to giving up.

However, if it will help you I will send you a solid working binary to test with FreeRTOS, IP statemachine, LAN, WAN and SSL connectivity and console (UART) as well as LED notifications.

If that moves things forward I will create a working subset of my source code (removing the confidential bits) and share that with you.

If you can get that compiled and working under Eclipse on Linux, it will be appreciated if you can share the workspace with the CC3200 & Eclipse settings, back with me.

Let me have your email address and and I will send it on...

Andre

I have found a solution.

It looks like to execute the program correctly the board requires a hard reset so the program counter starts with the bootloader and only then goes to the start address of the main program. This is why I could see the "board needs reset" messages in openocd.log.

It is appeared to be possible to emulate hard reset by executing the 'monitor soft_reset_halt' command in gdb.
After that if you run 'continue', the program executes successfully and is not stuck in "svc 0" anymore.

A few observations that I have made during debugging this issue and that could be useful to others:
1. Interrupt vector table can be checked with command:
x 0x20004040 (and higher, see "Table 2-7. CC3200 Application Processor Interrupts" of CC3200 Technical Reference Manual )

In particular, the SVCall interrupt vector can be checked as:
x 0x2000402c
The result points to vPortSVCHandler, and this is correct. So the problem is definitely not in interrupt vector table.

2. I couldn't use gdb and uart simultaneously in Linux. (Does anyone know how to do that properly? Once I load the ftdi_sio module, dgb could not connect to target anymore.) So I had to map UART0 to pins 3 and 4 (in pinmux.c) and connect a USB<->UART adapter.

3. After I exit gdb and enter it again, it can't connect to the board anymore. I have to use a 'usbreset' utility to reset the USB device. That is a nice tool available on the Internet as a single small c source file.
For example:

$ lsusb
Bus 001 Device 069: ID 0451:c32a Texas Instruments, Inc.
$ usbreset /dev/bus/usb/001/069
Resetting USB device /dev/bus/usb/001/069
Reset successful

The above allows to develop/debug the board 100% remotely. No need to touch anything, press reset, etc. Hope that helps someone else.

UPDATE: if you do like I described in the post above you will simply run the program which resides in flash memory insead of debugging the new one. So in order to make it properly it is required to reset the board before loading the binary. I simply modified the gdbinit file like this:

#*****************************************************************************
# Load the binary
#*****************************************************************************
monitor soft_reset_halt # this emulates hard reset of the board
load

#*****************************************************************************
# Initialize the SP and PC values from the application's
# vector table
#*****************************************************************************
set $sp = g_pfnVectors[0]
set $pc = g_pfnVectors[1]

#*****************************************************************************
# Set break point at main and run to main
#*****************************************************************************
break main
continue

Note the 'monitor soft_reset_halt' command before 'load'. With this little fix it now runs flawlessly.

Hi Konstantin,

That's great news! Congratulations and thank you very much for sharing your findings.

2. Did you take a look at the link that I posted above? I have UART and gdb running simultaneously with ftdi_sio. What versions of ftdi_sio and OpenOCD are you using? Did you modify the OpenOCD ftdi config file (I forgot its exact name and I'm not at my work computer currently)? This is necessary for newer OpenOCD versions.

3. Will I also need the usbreset utility if I have my gdbinit as in your update?

I'll see if your method works for me this weekend. I will also look up my UART-related configuration and give you some additional information tonight.

With best regards,

Darius

Hi Darius,

2. I followed your instructions regarding UART, and indeed after running

# modprobe ftdi-sio
# echo 0451 c32a > /sys/bus/usb-serial/drivers/ftdi_sio/new_id

I have two more serial USB devices. But gdb can't connect anymore:

Remote communication error. Target disconnected.: Connection reset by peer.

It looks like I can either use gdb or UART. Once I remove the module

modprobe -r ftdi-sio

I can connect with gdb again. It's the same with openocd 7 and 8. I didn't change cc3200.cfg if you mean this file.

3. Regarding usbreset - once I disconnect from the target, gdb can't connect the second time. It outputs some error messages like:

Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
...
Malformed response to offset query, OK

Once I run usbreset gdb starts working fine. Maybe I am supposed to run something before disconnecting from the target in order to be able to connect without reset later. I have no idea.

So I currently need both: the gdbinit modification (monitor soft_reset_halt command before loading the binary) and usbreset before each run of gdb.

Just created a simple python script to use instead of usbreset:

#!/usr/bin/python

import usb.core
import usb.util

devices = usb.core.find(find_all=True, idVendor=0x0451, idProduct=0xc32a)

if len(devices) == 0:
  raise ValueError('No devices were found')

for device in devices:
  print("Found CC3200 Launchpad at bus " + str(device.bus) + ", address: " + str(device.address))
  device.reset()
  print("Reset complete")

exit(0)

It doesn't need any input parameters, so can be executed right before gdb. I'm simply using an alias in bash:

alias armdebug="ti-reset.py && arm-none-eabi-gdb -x /your/path/cc3200-sdk/tools/gcc_scripts/gdbinit"

This saves me some time. No need to run lsusb and usbreset.

Hello,

I've managed to build and debug the wlan_station example (and other) on Eclipse Luna with OpenOCD. Works fine. I've shared my work on http://cc32xx-4-linux.io/ (there are explanations there)

and on my github account: https://github.com/monnoliv/CC3200

Olivier

Hi Darius/Konstantin,

Has either of you been able to get the Eclipse Luna/Linux/CC3200 combination working with OpenOCD 0.8.0 or 0.9.0

I have built both versions with the ft2232 as well as the new ftdi interfaces, have also tried to modify the cc3200.00 to work with the ftdi interface but so far no luck.

Andre

Hi Andre,

Unfortunately I haven't had time to try out any of the new findings up to now and probably won't be able to do so in the near future. For now I have given up on the CC3200.

I wish you good luck!

Best regards,

Darius

Hi,
I hit exactly the same issue on sdk-1.1.0.
Can you share how to fix this issue?

Thanks,
Axel

Axel, could you be more specific about which problem? If it is not being able to get CCS running under Linux, I gave up on CCS and am now using the emacs/gdb environment, this is working well. It also has the advantage that once you get it going, it is easier to change from one board to another; we will probably stay with it going forward.

-Ken

Hi Kenneth,
The problem i hit is fail to run gdb for getting_started_with_wlan_station.
I found the fix now, just adding monitor soft_reset_halt before load in gdbinit.

Alex, that is good; a small consideration, it may be that monitor soft_reset_halt has been deprecated (at least in openocd 0.9); it has been changed to monitor reset halt (I believe). If you are running openocd 0.8 and decide to upgrade to openocd 0.9, you may need to change this.
-Ken

Hi Konstantin,

I got gdb and UART working at the same time, by change the debug interface used in OpenOCD from ft2232 to ftdi, then modprobe ftdi-sio after OpenOCD connected, in this way I have only one serial USB device in /dev and that's the UART interface. The reconnection issue also gone after changing to ftdi interface.

microcom sometimes get a 'quiet' UART connection for the first time, but anyway it works again after reconnection.

Hi
Could please tell me how to execute cc3200 on Ubuntu 14.04 by using Eclipse Luna and openocd
your reply is most valuable to me
Thanks in Advance
Regards
Ashok