Either the code above has been edited, or some of the tests do the correct and test if the return from strcasecmp() is zero, e.g.

if(strcasecmp(msg,"led3-on")==0)

and the others (erroneously) take the return value as the condition of the if-statments, e.g.

else if (strcasecmp(msg,"led2-on"))

david.prentice wrote:

But strcasecmp() returns 0 when it matches.

Indeed.

As do most (all?) ..cmp() functions.

They do so for the reason that you don't only want to have a match/no-match return, but you want to know if one is "less" than the other. E.g. for using when sorting data. The ..cmp() functions returns -1 first parameter is less than second, 0 if they are equal and 1 of first parameter is greater than second.

reza_mslm wrote:

only PB2 is toggled (doesnt matter what text i send.)

if sending "led3-on" isn't working then it might be because the message does not contain exactly "led3-on" when received. Could there be a line ending character, e.g. \r or \n or a combination of those two?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

If that was re my post, then I wasn't talking about what "you" (i.e. the AVR) is sending.

You are having problems interpreting what the SIM module sends to the AVR. Are you sure the SIM module does not send line endings?

reza_mslm wrote:

now none of PB3 and PB2 toggle.

We can say nothing about that unless you post the code you have "now".

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

The include thing doesn't seem entirely likely to be relevant, if things are building at all it's probably unidiomatic but not breaking anything.

What you probably need here is some more insight into what's happening.

I note that you have a couple instances of |=, and a couple of ^=, for LED toggles. Probably ought to be using |= to turn on, and &=~ to turn off, so you know which way each thing is setting the LED. An LED being toggled really fast can be invisible.

I don't see the declaration of sim300_buffer. I guess what I'd probably do first is, on message receive, set one LED to indicate which of the SIM300 codes you got back (_OK, _MSG_EMPTY, _SIM_NOT_READY, _TIMEOUT), and delay for a little bit so you have time to see the light flash. If you consistently see the light for _OK, then you know you should at least be getting *some* kind of string back. Obviously, if you can get a console you can dump things to, that'll make it a lot easier...

Fault-seeking is about forming hypotheses about an isolated cause of the problem and the n test those hypotheses. One by one. In a structured manner. Isolated, so that you know what you're testing.

Ideas for a list of isolated hypotheses:

Something is wrong with how responses from the SIM module is interpreted. (E.g. see my ideas above about the SIM module possibly not sending the exact strings you're thinking it does - e.g. it might add line ending chars". Ways to test: Hook up the SIM to a PC serial port (with a level converter) and use a good terminal software so that you can get "raw" unfiltered/untranslated views of what the SIM module actually sends. Or.. Change your AVR program to test on beginning of SIM message string using strncmp() (rather than the complete message).

Something is wrong with how you toggle pins. Start by doing a structured inspection of all your togglings. Make them uniform - i.e. do it the same way everywhere (not ^= in some places and |= in others.

Something is wrong, hardware-wise, with some of the port pins. Or with one of the LEDs! Easily tested by swapping a toggle that works to one of the non-working pins.

As I said above. Test one of these at a time. Work slowly and structured. Be meticulous with making notes - pen, paper and brain are the prime tools here!

This is all standard procedure and way of working when debugging. The Devils is in the details, and in the situations where several things are wrong. "Combinatory bugs" are at least as much hell as are intermittent faults, and require a very structured way of working to get solved. You don't know if your problem is a combination of faults so be structured and prepared from the start!

HTH!

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

I assumed it was declared in sim300.c, but since we can't see it, we don't know what type it has, or how much storage it has, or anything else. There's a lot of things here that look like they might need bounds checking, or could be overflowing bounds. I'd check on that, too.

The problem is very likely in your usart.c file - which seems to me to be handling a ring buffer, though in a somewhat "exotic" way making it a hard read (for me). I might review your code in usart.c a bit more later today, but my advice to you is to look in that file first for the problem.

This is an excellent case for testing without involving AVRs or Atmel Studio at all. Get your favourite "C for PC" IDE up and write a small test-bench that runs the functions in usart.c. Make extensive use of your favourite IDEs debugger and step through code while debugging.

Another possibility to investigate is the code in sim300.c. It might do bad readouts from the ring buffer. E.g. is that read-out code atomic (non-interruptable)? Since the reception proper is interrupt-driven this is more or less a requirement.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

This is an excellent case for testing without involving AVRs or Atmel Studio at all. Get your favourite "C for PC" IDE up and write a small test-bench that runs the functions in usart.c. Make extensive use of your favourite IDEs debugger and step through code while debugging.

+999 !!

Also note that the ATMega16 has on-chip debug:

The ATMega16 Datasheet wrote:

• JTAG (IEEE std. 1149.1 Compliant) Interface

– Boundary-scan Capabilities According to the JTAG Standard

– Extensive On-chip Debug Support

– Programming of Flash, EEPROM, Fuses, and Lock Bits through the JTAG Interface

Two obvious things. One, you're allocating a 300-byte buffer to use, and that's large enough to be a likely problem on machines with only 2K or so of memory. The other is, you've got a lot of points at which you skip past things (like the strcpy starting from buffer+1) which could be resulting in skipping past some characters.

I still argue that the code for circular buffer and the whole SIM part of the code is actually not relying on an AVR, or a microcontroller in general. It can be developed and tested in the less "awkward" environment of a IDE targeting any "PC operating system". There, it can be debugged in a controlled manner.

This will also have the additional advantage that the code will be clearly modularized.

I'd also replace the somewhat "hacky" implementation of the circular buffer with something proven and tested, e.g. Dean Cameras work.

I have the code given above in a NetBeans project and might rig it up for testing tomorrow. Or I might not, so don't stay up waiting.. ;-)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

I still argue that the code for circular buffer and the whole SIM part of the code is actually not relying on an AVR, or a microcontroller in general. It can be developed and tested in the less "awkward" environment of a IDE targeting any "PC operating system". There, it can be debugged in a controlled manner.

Obviously the intent is to "skip CR or LF characters". But if you aren't checking what the actual values are, who knows?

Basic advice for debugging: If your code is not doing what you think it should be doing, you know that something you believe about your code or its inputs is wrong. So any time you say "well, this must be right, because...", stop and say "have I tested this?"

Put another way: Assumption is the mother of much evil. The process of debugging is much about removing assumptions and instead establish facts.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

I want to state for the record that i cannot possibly stress enough how completely, totally, insane it would be to use anything this poorly understood or maintained for any kind of thing for which "voting" would be at issue. If you don't know *why* that code was there in the first place, or what it was trying to do, just commenting it out may make things better, today, but it may break something else tomorrow.

And voting is way too important to leave to "we don't really understand this". Get someone more qualified in to review the code carefully. Seriously.

Indeed. Just because a problem stops occurring does not mean the problem is actually identified and removed/rectified. Removing the symptom and believing the problem has been removed is also possible.

the_real_seebs wrote:

And voting is way too important to leave to "we don't really understand this"

Sort of depends, eh? Could be the European Song Contest, SomeCountry Got Talent, or a family voting for Tacos v/s Pizza for dinner..

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Absolutely. I was just hinting at the consequences might not be so severe as if this was a general election or some such. And I should have placed a winky-smilie on my post. Here it is: ;-)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]