CC1310: Lots of issues with linux coprocessor and sensor TI154 stack example

Hi Dzuy,

Can you post the SDK number for the CC13x0 SDK and Linux SDK? (For Linux SDK the latest version that is compatible with CC1310 is 3.30.)

The linux ti_collector is from one of ti154stack_linux_x64_4_30_00_06 example.

The coprocessor is from the  simplelink_cc13x0_sdk_4_10_02_04.

Hi Dzuy,

Can you download the 3.30 linux SDK and retry? (Scroll down for previous versions.)

This is the exact version I currently have.

This is the same exact version I have now.

Sorry, ti154stack_linux_x64_3_30_00_12 proves to be worse off than ti154stack_linux_x64_4_30_00_06.

With ti154stack_linux_x64_4_30_00_06, my test can run for days.

With ti154stack_linux_x64_3_30_00_12, it freezes up with 378.524: ERROR: **ERROR** Set/Operation failed with status code: 0x19 within minutes.

I think the problem is with the coprocessor code, not the linux SDK.

Hi Dzuy,

It sounds to me like the issue could be either with the linux side or the coprosessor side, or if the two are not working together as expected.

Were you able to debug what's going on n the CC1310 side when it's hanging? E.g. you can disconnect the linux and attach a debug session.

Marie,

We've debugged the linux side and we don't think the problem is with ịt  The collector simply sends a command to the coprocessor and keeps waiting for a reply that never comes from the coprocessor, and it ceases to do anything else.

We tried to debug the coprocessor through CCS and it won't attach via XDDS110. I was hoping that since you're the expert, you can help us figure out how to use this thing.

Hi Dzuy,

Can you try following the process outlined in this post? 

I think it's worth the time to debug what's going on in this hanging device, it might tell us why it's not answering.

Can the coprocessor print out to an LCD screen or does the LCD already use UART (which is used to communicate with the linux collector)?

Marie,

That debug instruction didn't help.  The debug starts, but as soon as the linux collector starts, the debug errors out.

So we got the Sharp LCD booster pack.  Plugged it in, put

-DBOARD_DISPLAY_USE_LCD

into coprocessor.opts, compiled ok, but when run, we got:

Cortex_M3_0: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.2.1.00046)
Cortex_M3_0: Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.2.1.00046)
Cortex_M3_0: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.2.1.00046)
Cortex_M3_0: Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.2.1.00046)

Nothing prints to the LCD.  How do we unable the LCD to print to it?

Hi Dzuy,

I'm sorry, I should have clarified.

Can you connect the Linux host, run the device into the fail state, then disconnect the linux host and attach the debugger as described in the post I linked?

The error message you posted doesn't have anything to do eith the LCD but rather CCS debugger cannot get access to CC1310. (Probably because the Linux host is using the line?)

Marie,

Yes, I did what you asked. Modified the GEL file, ran the test, failed, disconnect linux host, attach debugger through CCS, didn't help.

I'd rather debug with print out. I set BOARD_DISPLAY_USE_LCD to 1, BOARD_DISPLAY_USE_UART to 0, do some lcd print, but there is nothing on the LCD. It doesn't even seem to be powered on.

Why does this thing has to be so hard?

Hi Dzuy,

What LCD are you using?

BOOSTXL-SHARP128

Any news? Do you still support your product?

Part Number: LAUNCHXL-CC1310

Hello,

I need to debug coprocessor on my LAUNCHXL-CC1310. Since the coprocessor communicates with host_collector over UART, I thought I could print out on the LCD since it uses SPI, and the code does appear to support it.

So I bought BOOSTXL-SHARP128 LCD module and plug it in, but can't seem to be able to get it working. Is there any instructions on how set up LCD print out for coprocessor?

Hi Dzuy,

Can you please post a step-by-step guide to reproducing this issue?

1, Build collector example from ti154stack_linux_x64_4_30_00_06 on Linux system. Choose uart to communicate with coprocessor.

2. Flash coprocessor example onto CC1310 launchpad. Use Frequency Hopping

3. Flash sensor example onto 3 CC1310 launchpad, use frequency hopping. Change polling interval to 10 secs.

Run the setup. The more sensor nodes, the quicker coprocessor hangs. The result is the coprocessor stops responding to the host_collector, hence the host_collector cannot send out commands to the node and the whole network setup hangs.

I want to debug the coprocessor with prints. I bought a  BOOSTXL-SHARP128 and mount it on the launchpad.  However, no matter what I tried, I can't seem to print anything to the LCD.  Is there any instructions/examples on how to use SPI to print out to the LCD?

Hi Dzuy,

I'm sorry, there is very little capacity on the team right now and I haven't been able to test this yet. 

Please let me reiterate that the SimpleLink Linux GW SDK 4.30 does not support CC13x0.

This is not the GW on Linux problem! It is the coprocessor thread that hangs on the cc1310 launchpad even with moderate load.

I suppose you won't be able to sell your product if you can't prove that it works.