SLEEPING within debug

Keith M

I've been using the SX28 for awhile with virtually no problems on the eval board.

I went away from my current project for awhile, came back, and now the debugger reports "SLEEPING" at the top of the debug window during a certain point in execution.

I'm using the latest version 3.1 IDE, and just reinstalled for the heck of it.· Same problem.

I'm sure my code is actually running, because it takes one of my "commands" via·some UART(bit-banged non-interrupt based)·code.· I can't step through it because of the fact that its a uart.· Right after the command is read, it immediately goes into "SLEEPING" mode, and everything halts.

I'm not using any watchdog timers or anything of that sort.

I've never seen "SLEEPING" across pretty extensive usage of the debugger.

What's going on here?

Thanks.

Keith
·

pjv

Keith;

It could be any number of things, from intermittent connectors to software.

If you post your code we can try to replicate the problem.

Without the code, there is not much anyone can (or is prepared) to do other than say "good luck", as you are then asking someone to help you chase ghosts, and that's a waste of time.

Cheers,

Peter (pjv)

Keith M

Peter,

What does the message mean? I can't find word one within any documentation that even mentions this state.

When does the message get displayed, when the processor is not executing instructions? When its in a brownout condition, when its in an infinite loop?

What's it mean for a microcontroller to be sleeping?

Or put another way, what conditions must exist for the SX-KEY to display "SLEEPING" ? Doesn't get a response from the debug interface?

I can find the problem within my code if I know what I'm looking for.

I've also found a "SLEEP" state, which is separate from, "SLEEPING"

The IDLE and RUNNING states seem self-explanatory, but I'm lost on the meaning those error states.

Thanks.

Keith

pjv

Hi Keith;

As I stated, there are several things that can cause the "sleeping" message to appear.

One is an intermittent connection from the SX-Key; this is my most frequent occurrence.
Another is unstable power.
Another is corrupted shadow registers (most probably by your software).
Another is your software not doing the right thing.
Another (albeit rare) is the debugger hiccuping.

While the debugger typically goes goes to sleep when it encounters an invalid situation, the most typical reason will be caused by your software.

I expect that because the causes can be so varied, it is really difficult to documented well.

As I said, post your code so we can try to replicate it and hence eliminate·your specific·hardware cause. Anything else is a waste of time.

Cheers,

Peter (pjv)

Rsadeika

Keith,

My advise is, post your code, I speak from experience on this. If your code is not to long, somebody will look at it, and tell you if it is your code that is the problem. On a rare occasion, sometimes it turns out to be a hardware problem.

Ray