CC9215 Freezing LED (LE2) blinking

Embedded Devices NET+OS
,
1

I am using a CC9215.

The LE2 starts to blink when I try to access the AWS.
The problem is that I am running the same firmware in two other computers on the same hardware (Debugging with JTAG) and it works fine.

What are the reasons for this LED to blink? Could it be caused by low memory? I already tested with more memory on the Properties of the project with no success.

The includes/libraries I am using in both computers are the same. I even tested with another JTAG. I also tested with another CC9215, finding the same results.

Could it be some general settings on the NET OS that are configured on one computer but not in the others?

Thanks,

2

The three PCs on which you are building your NET+OS application, what are they? WinXP, Win7, Win8? 32-bit, 64-bit?

Have you compared the build parameters across the three PCs?

Generally if a LED is flashing it means the device crashed.

If the system is crashing in AWS, I’d take a hard look at your “stub” functions (the functions generated by the pbuilder utility. When “get” functions are generated, they return a stack variable. This is something that in real life you really do not want to do. The problem is that based on timing, somethings it might work and other times it may not. You want to return a static or global variable so it can’t do out of scope.

1 Like
3

I changed the whole Web folder from another version of the project and it seems to have solved the problem for a while. So it seems the problem was caused by the stub functions as you said.

Right now I am having a similar problem. This time the led blinks once again when I run the project (Not when I enter the Webpage-AWS). The difference is that this time when I debug the project it runs well and others it crashes (Since the beginning of excecution)

How come sometimes it runs and sometimes it crashes? Maybe a problem with memory?

4

There are any number of issue that could cause a crash (I am guessing you are experiencing a crash).

  1. Variables not being initialized
  2. Shared resources not “protected” with a semaphore of mutex
  3. updating an array and running off either end of the array (memory corruption)
  4. Updating a buffer and going off either end of the buffer (memory corruption)
  5. using a pointer that has not been allocated (NULL pointer)
  6. starting a thread and not clearing out the thread control block and of the threads stack
  7. starting a thread and using a thread control block that goes out of scope
  8. Some sort of race condition

Remember that when you are debugging, the timing of things is different then when you are running free. Also remember that when running with a debuggable image vs. a release image, there is a lot of optimization that goes on with the release image. This can mean that if your coding has some issues then variables might be optimized out in the release version. This can cause weird issues.

Another thing you can look into. Assuming you are up to date on yoru package manager updates, in the Documentation\white_papers directory of the installation tree, there is a paper entitled crash_debugging.pdf. Maybe that will assist you in tracking down your issue. I have found that if you have a memory corruption issue (running off the end of an array or buffer) you will many times get crashes in weird places such a timer task that is part of NET+OS. This means that while your code was stomping on memory outside of where you thought you were, you stomped on something vital.

Another thing to look for is when a function returns a point to a stack variable. The pointer will be valid until the stack variable goes out of scope. Thus when debugging, many times the stack pointer will stay valid long enough to use it but when running in release mode, it will go invalid before it is used by the caller and bad things will happen.

Good luck

5

I couldn’t find that document. It is not in the whitepapers or in the docs folder of my netos75 directory. Any other place where I could find it?

Thanks for all the information!

6

You should be able to find that document at the following location:

http://ftp1.digi.com/support/documentation/crash_debugging.pdf