Uart.sendByte makes us reboot :'(

debe

We are trying to send a message through bluetooth and when it gets to sendByte, more precise CPU.writeRegister, it reboots. I read that you can make the javelin stamp reboot by connecting a pin to reset but i dont know how to do it.

Plz help

Peter Verkaik

I assume you don't want it to reboot?

Check if your transmit pin is connected (accidently) via a resistor (or has a short) to
the reset pin. It may also be that your transmit pin sources a large current.
Leave your transmit pin disconnected and see if the javelin still reboots when
using sendByte().

regards peter

debe

Thanks for the fast answer

We tried writing a "spammer" that just send a message every second (almost) by using the timer. This works.
We have a hard time to understand why our calculations that happen before might mess things up.

What does sendByte try to do? And what does writeRegister do?

PS. Yes we do not want to reboot :P DS.

Peter Verkaik

Uart.sendByte() places a byte in the uart transmit buffer.
The buffer contents is transmitted in the background.
If your transmit pin only connects to your
Bluetooth input terminal, I don't see how that
could enforce a reboot.

You could post your code and tell exactly at what point in your
code the javelin reboots.

regards peter

debe

The code is below. It crashes on this line "txUart.sendByte(id);" when uart calls on CPU.writeRegister.
Could it be when we cast our int to char?

public boolean send(int p_id, int p_hazardlvl){
  System.out.println("Trying to send message");
  return c_Inic.Send((char) p_id, (char) p_hazardlvl);
}

public boolean Send(char id, char hazardLevel) {
    txUart.sendByte(id); // send the id of the target vehicle

    txUart.sendByte(hazardLevel); // send the hazardlevel message

    char response = (char) rxUart.receiveByte(); // wait for ack
    if (response == 0)
      return true;
    else
      return false;
  }

Peter Verkaik

I don't see how this causes a reboot.

You mentioned calculations before using sendByte().
These calculations might cause a stack overrun which
could result in a reboot.
Can't really tell without the full code.
Why not attach your main class (and involved class if any).

You could also single step through your code using the debugger.
If it is a stack error it should show up there.

regards peter

debe

Hmm it might be the buffer over run, we'll have to look into that a little more...

You can find (almost) all our source code here http://hem.bredband.net/bihel/avss.rar

Thanks for all your help so far

Peter Verkaik

Although it should not give problems,
why defining in class INIC() the private txUart and rxUart static?
Try running your code with txUart and rxUart not static.
Report the result.

regards peter

debe

Unfortunately it didnt give us a problem. We tried to remove stuff and see what happens. When we removed intersectionSignals and USSController it worked. The only thing they both have in commen is that they both use Timer. Could our implementation of timer be wrong??

debe

It works now...
The problem was the initiation of the obejcts in the constructor in Controller.
We rearranged the initiations and it worked fine.
Not sure why this is a problem... but it works.

Peter Verkaik

Good to hear you found the cause. I don't think I could have spotted it,
due to the large number of classes.
I noticed many of the class constructors do not take arguments
but do use the keyword new frequently, so objects are created
almost everywhere. I find this difficult to track.
Here's a tip:
Create your objects in your main class.
Then pass the required objects to the contructors of your classes.
This gives you a single place where objects are created and thus
also allows you to change the initialization order easily.
You then also see in your main class what hardware resources (eg.·pins)
are used, and what VP objects your program uses.

regards peter