CC3000 initialisation issue

Fabien Gaubert1

I messed around with the wifi webserver example, on a Stellaris LM4F board, and a touch screen, and I have a really strange behavour.

This is the code.

void

SysTickHandler(void)

{

static unsigned long ulTickCount = 0;

static unsigned long touchCount = 5;

// Increment the tick counter.

ulTickCount++;

touchCount++;

//Process after 500 ms

if(ulTickCount >= 500)

{

// Handle any un-solicited event if required - the function shall be triggered

// few times in a second

hci_unsolicited_event_handler();

ulTickCount = 1;

}

if(touchScreenReady){ //touchScreenReady is always false

UARTprintf("Never here"); // never printed

WidgetMessageQueueProcess();

touchCount=1;

}

I'm in the core timer interrupt routine. When I comment "WidgetMessageQueueProcess();" the wifi is working properly. When I uncomment it, the wifi doesn't work anymore (The program blocks at CC3000Init()). touchScreenReady is always false, and then "Never here" is never printed. And this is not a joke ^^.

over 13 years ago

0 SourceTwo over 13 years ago

Expert 2355 points

Hi Fabien,

What is the definition of 'touchScreenReady' ?. Is it a variable or a procedure?

If it is a procedure, your expression will evaluate as 'true' because there are no '()' following it - its address will always evaluate as true (!=0).

Regards,

Dave

0 tibcsi over 13 years ago in reply to SourceTwo

Intellectual 360 points

Calling WidgetMessageQueueProcess() from the systick interrupt is not a good idea. What is the period of your interrupt? You can set a boolean in the interrupt function (you should make it volatile) to indicate that the display should be refreshed, and call the WidgetMessageQueueProcess() in your main program.

Furthermore, make sure that touchScreenReady is declared as volatile (if it is a variable).

0 Fabien Gaubert1 over 13 years ago in reply to tibcsi

Intellectual 460 points

Thank you for these relevant answers. But in my case, it doesn't help me.

SourceTwo, touchScreenReady is a volatile long declared as a global variable. This is the definition:

volatile unsigned long touchScreenReady=0;

And I never go inside the condition, because "Never here" is never printed. (Other things are printed in my program, so UARTPrint(...) works properly).

tibcsi, the wifi webserver use a blocking function in the main loop, waiting for socket connections. Then I can't use the main loop. But I tried using only the touchscreen without the wifi, with WidgetMessageQueueProcess() in the systick interrupt, and it works properly.

With exactly the same code, I have the touchscreen AND the wifi working separatly, but not together. And I can see no interactions between the two.

0 Fabien Gaubert1 over 13 years ago in reply to Fabien Gaubert1

Intellectual 460 points

Maybe something with the size of the ram? There is a lot of global definitions for the grlib....

The stack is large enough (2048 bytes).

Any ideas?

0 Fabien Gaubert1 over 13 years ago in reply to Fabien Gaubert1

Intellectual 460 points

When I uncomment WidgetMessageQueueProcess(), the size of the binary goes from 42.9 kb to 43.3 kb.

I can't find any information on the size of each memory segment in the final memory. Do I overflow the ram which is 32kb?

This is what's in Remote_Light_css.cmd (I use CCS5):

MEMORY
{
/* Application stored in and executes from internal flash */
FLASH (RX) : origin = APP_BASE, length = 0x00040000
/* Application uses internal RAM for data */
SRAM (RWX) : origin = 0x20000000, length = 0x00008000
}

/* Section allocation in memory */

SECTIONS
{
.intvecs: > APP_BASE
.text : > FLASH
.const : > FLASH
.cinit : > FLASH
.pinit : > FLASH
.init_array : > FLASH

.vtable : > RAM_BASE
.data : > SRAM
.bss : > SRAM
.sysmem : > SRAM
.stack : > SRAM
}

__STACK_TOP = __stack + 2048;

0 Fabien Gaubert1 over 13 years ago in reply to Fabien Gaubert1

Intellectual 460 points

No Stellaris experts willing to give me a hint?

0 cb1_mobile over 13 years ago in reply to Fabien Gaubert1

Guru 117855 points

Qualifications likely not to your spec - and perhaps more willing than able. That said/admitted:

1) Systick interrupt appears to be set to 1mS intervals. Why? We've found that key presses can be detected nicely via 100mS interval scans. Too frequent Systick interrupts may be problemmatic - very easy/fast to try.

2) Like/second "tibcsi's" suggestion about, "Not doing too much w/in an interrupt." His suggestion would be my own.

3) Can you "move" the web-server away from the main loop (as you stated) - and simply call it from main? (facilitates (2) above)

and

4) Strongly suspect that "Touch-Screen" is substantially less complex than "Web-Server" - so best to focus first here. Like you to progressively, methodically "piece-meal" reduce "Touch Screen" code segment - goal being the location & isolation of the troublesome function(s). May have missed - but don't recall your report of any debug results during program failure. Does the program continue to loop - is each/every segment of the program visited & executed? (how do you know?) Most crucially - and fastest fix if true - are you vectored to some fault handler?

BTW - hate chosen Subject - provides zero indication of subject. "Touch-Screen/Web-Server - apparent Conflict" - so much clearer - n'est pas? Guaranteed to attract more serious assistance...

0 cb1_mobile over 13 years ago in reply to cb1_mobile

Guru 117855 points

Vastly improved Subject! Now far clearer/inviting. (to both "would be helpers" and follow on/future visitors.)

TI's Dave W. is Gr Lib guru - hope that he'll bless this quick follow-up: (by unskilled, outsider)

Eliminate (for now!) any complex function w/in your "Touch Screen" code segment. We want to get something working in concert with your Web-Server - KISS (simple) must be our guide. I would not employ famed, "Widget' at this stage - again use most basic features of Gr_Lib - we want to achieve that which neat, new Subject promises! (i.e. Concurrency)

After we identify causal nexus w/in Gr_Lib - we can attack and solve - "kitchen sink" method beyond all efforts (apparently) to date - so onto Plan "B." (as suggested here)

0 Fabien Gaubert1 over 13 years ago in reply to cb1_mobile

Intellectual 460 points

Hello cb1_mobile,

1) I simplified the code for the forum. Actually, I use a couter, and only call the function every 100ms.

2-3) I don't understand what you are saying. Code is as follow:

while(1)

{

// Check if we are connected

if(ulCC3000Connected)

{

httpd_init(); //misnamed, should be waitForConnection() or something like this

}
}

I can't move it, as most of the time is spent inside httpd_init(), waiting for a connection. Don't ask me why this implementation, I didn't do it. This is the way it has been ported for the CC3000 wifi module.

But when I remove the wifi part, the touchscreen is working really well, with WidgetMessageQueueProcess() in the Systick interrupt, or inside another timer interrupt (tried with timer 0).

4) There is no hard fault or anything. The only issue is that the execution blocks inside hci_event_handler().

You were completely right for the name of the topic. Sorry for that. Fixed.

0 cb1_mobile over 13 years ago in reply to Fabien Gaubert1

Guru 117855 points

No apology sought - your new Subject precise - perfect I'd say.

While attracted & intrigued by CC3000 (we have dev kit here - never opened) I'm clueless. Thus my focus shifts to Touch/Displays - tad better there.

Have you tried completely replacing "Touch Screen" with some other, more basic code segment? (perhaps toggles several GPIO - several Leds - so that you know it performs) Want to see "if" it really is some "Concurrency" Issue between Touch Screen and CC3000 - or maybe just the CC3000 blocking - starving ANY function. (thus not "Touch Screen" at all. Again - this is why I suggest the creation of simple, new function - to be located just where "Touch Screen" is now - and to replace it for testing. My hope/belief is that yours may in fact not be a concurrency issue. (usually more difficult to resolve)

0 Fabien Gaubert1 over 13 years ago in reply to cb1_mobile

Intellectual 460 points

Actually I had this issue with the wifi software several time, and quite randomly. The problem is that the soft is waiting for a SPI response from the CC3000, blocking in the loop below:

unsigned char *
hci_event_handler(void *pRetParams, unsigned char *from, unsigned char *fromlen)
{
...
while (1)

{
if (tSLInformation.usEventOrDataReceived != 0)
{
....

tSLInformation.usEventOrDataReceived is always equal to 0 because SpiReceiveHandler(), the SPI interrupt handler is never called.

At first I though there were two different issues, so I also posted there: http://e2e.ti.com/support/low_power_rf/f/851/p/193099/706553.aspx#706553

0 cb1_mobile over 13 years ago in reply to Fabien Gaubert1

Guru 117855 points

So - as previously posited (suspected) - issue is not concurrency!

To attract the proper responders (those w/experience/skill) to your post - you may have to (once more) take scalpel to your Subject...

0 cb1_mobile over 13 years ago in reply to cb1_mobile

Guru 117855 points

Update: Great re:subjecting - trust this "advertises" your issue far better. (really should consider, "attracting the proper attention to your post," as advertising!) You are competing against some 20+ other posts each day. (but weekends)

Will take "one last whack" @ this Dead Horse. Our group has been trained to be most wary of, "Inadequate/SubjectiveTitling/Describing of an Issue." An improper representation of an issue may too often "shut-down" - or subdue - broader, more fruitful technical analysis. Early responders (smart, caring as they were) "bought into" your initial description - thus analysis was bit misdirected - solution-free.

You/others may wish to consider...