Incoming serial halts code

So I have an interesting issue. Incoming serial data halts code dead in its tracks. I am running a 2560 at 8MHz. I have a SM130 RFID module connected to Serial1 (18,19).

The issue occurs whenever I'm expecting the first response from the module either after a reset or immediately after the csum of the first command. The 2560 completely freezes. Everything stops. I have used these modules before without issue.

I wrote a quick program which removes all other libraries and things not involved with the RFID/serial and the issue still occurs so there doesn't appear to be any contention with other parts of the project/circuit board. This simplified version is shown below. When the code is run as is, I get a 300ms ish beep. When I comment out Serial1.begin, I get an infinite beep. I added serial buffer drains in multiple places to eliminate the possibility of a overflow (even though the module should only respond with 8ish bytes) and this didn't help either.

void setup()
{
  pinMode(4, OUTPUT);//a piezo beeper
  tone(4, 500);
  pinMode(38, OUTPUT);//reset line of RFID module
  Serial1.begin(19200);

  digitalWrite(38, HIGH);//high=in reset
  delay(1);    
  digitalWrite(38, LOW);
}

void loop()
{
}

Because I am using a modified board profile for compiling the code to run at 8MHz, I included my board profile below as well. I am uploading the code via ICSP. My only guess is something to do with "build.variant"? I want to note that I don't think it is a baudrate issue because when I issue a command via serial at 19200 the 2560 locks up right after the csum is sent and I would have expected a response.

##############################################################

mega25608.name=Arduino Mega 2560 8MHz

mega25608.upload.protocol=wiring
mega25608.upload.maximum_size=258048
mega25608.upload.speed=57600

mega25608.bootloader.low_fuses=0xC2
mega25608.bootloader.high_fuses=0xD8
mega25608.bootloader.extended_fuses=0xFD
mega25608.bootloader.path=stk500v2
mega25608.bootloader.file=stk500boot_v2_mega2560.hex
mega25608.bootloader.unlock_bits=0x3F
mega25608.bootloader.lock_bits=0x0F

mega25608.build.mcu=atmega2560
mega25608.build.f_cpu=8000000L
mega25608.build.core=arduino
mega25608.build.variant=mega

##############################################################

This is driving me crazy and must be something very simple. Any help is greatly appreciated!

I suspect that Serial1.begin is upsetting the beep function by messing with the interrupts while the beep is in mid stream.

What happens if you setup the Serial1 first?

like so?

void setup()
{
  Serial1.begin(19200);
  pinMode(4, OUTPUT);//a piezo beeper
  tone(4, 500);
  pinMode(38, OUTPUT);//reset line of RFID module
  
  digitalWrite(38, HIGH);//high=in reset
  delay(1);    
  digitalWrite(38, LOW);
}

void loop()
{
}

No difference. This code is way simplified down from the original code. The full code has WS2812B LEDs, and a multiplexed display as far as visual outputs go and everything stops. I actually did try taking the tone stuff out at one time to test for interrupt issues.

Just to be sure interrupts are not an issue I changed the "heartbeat" to a blinking segment on the 7seg display with the below code. Again the segment blinks a couple times then stops and commenting out the Serial1.begin allows it to keep blinking.

void setup()
{
  //Serial1.begin(19200);
  pinMode(38, OUTPUT);//reset line of RFID module

  DDRC = 0xFF;//7seg anodes
  pinMode(26, OUTPUT);//one of the cathodes

  digitalWrite(38, HIGH);//high=in reset
  delay(1);    
  digitalWrite(38, LOW);
}

void loop()
{
  PORTC = 0x01;
  delay(100);
  PORTC = 0x00;
  delay(100);
}

Just to be sure, This IS a mega2560?

Yes, it's a mega2560. It's not a Arduino Mega board but the same processor in a custom PCB with the code written in the Arduino IDE and the hex uploaded with AVR studio+MKII I just don't have an external crystal on this one hence the above board profile so it will compile for 8MHz. If this wasn't the last SM130 I had and it wasn't soldered into my board I would test it with an actual Arduino Mega board (16MHz) and see if the issue persists. That's my only theory now is it is something in that board profile.

OK so more interesting info. I have access to Serial2 via the main connector that feeds power and talks to this board via RS485. I told the host board to send a byte every two seconds and had this problem board beep for a receive and continue to blink the segment. When receiving a byte on Serial2 the board does not halt and performs as expected.

BTW Which version of the IDE are you using.

Hmm good question. 1.5.5-r2

GTech13:
Hmm good question. 1.5.5-r2

Agh, I haven't got that one on board. You didn't mean 1.0.5-r2 ?

Definitely says 1.5.5-r2. More info... neither lines are shorted to ground, both sit at high idle during the freeze. I tried multiplying and dividing the baudrate by 2 with no difference in effect. I actually don't even need to issue the reset command toggle reset to get a freeze up. The module does seem to send out version info upon power up so it will freeze after a power cycle but not after a reset/programming cycle on the 2560. (Makes sense.) ....Provided Serial1.begin happens before the module gets that info out.

So if you push the reset button, it gets it over the lockup?

The 2560 does yes... that is provided the SM130 does not issue any more info into Serial1 which it won't unless I give it a hardware reset or issue any command which it then responds to. AHH something really interesting has been discovered! So I power it up, the SM130 sends out version info thus freezing 2560, I short 2560 reset to ground, 2560 heartbeats fine, I short RX1 to ground and it immediately locks up. So it's triggered by the falling edge of RX1 not any special data or baudrate. It could still be interrupt related but would be specific to that interrupt. I don't know enough about interrupts to know if that tells me anything though.

Ok so I enabled all the serial ports and shorted all the RXes to ground. Only RX1 has the problem. Serial0 and Serial3 are unused so I guess I will try to cut the traces and patch over which is way easier said than done considering my particular board layout having two daughter boards and the TQFP100’s pitch. I would still really like to find the source of the problem as this board is a prototype and changing the layout won’t be easy. Best case is the 2560 is damaged I guess.

Well RX1 is on pin 19 which is also responsible for responding to external interrupt 4. So perhaps it's your interrupt vectors that are up the wall.

Perhaps you could attachInterrupt(4,somefunction,FALLING); early in your setup.

and include a function with just a single return statement.

I'm confused as to how that would help...I can't have a hardware interrupt going when I need the serial. I tried detachInterrupt(4) then serial1 begin then reset SM130. Still freezes.

I tried attaching a falling interrupt as well and same thing again.

I just figured that perhaps the interrupt is being invoked by the external interrupt and getting sent to some corrupted address. If you were to set it to something that at least won't crash, it might sort out the problem.

I short RX1 to ground and it immediately locks up.

Wiring fault? Load up a blink sketch and then short RX1 to ground.

Nick, I loaded up blink. Only changed the delays a bit because 13 happens to be a npn driving a small relay. Grounding RX1 does not halt the code unless Serial1.begin(xxxxx); is added to setup. It’s specific to the hardware serial internal stuff.

I was somehow able to solder wire wrap wire to the tiny legs of another serial port without getting into anything else. There is no mask on this board so there is ground plane everywhere besides! Stuck those over to the RFID module without even cutting serial1 traces. Provided I don’t call serial1 begin (or make 18 or 19 an output) it works fine now but is only a bandaid to get this prototype running. I’m still incredibly frustrated and perplexed by this and still consider this to be an open issue. Thanks for all your help guys. I won’t be checking back tonight but maybe by tomorrow there could be more ideas.

Nick, I loaded up blink. Only changed the delays a bit because 13 happens to be a npn driving a small relay. Grounding RX1 does not halt the code unless Serial1.begin(xxxxx); is added to setup.

Just to clarify, loading Blink with altered delays, but no other changes, halts the code (the blinking stops) if you add Serial1.begin() ?

It's specific to the hardware serial internal stuff.

I can't really come at that. What internal stuff? Nothing Serial1.begin does makes the processor fail/loop if you ground RX1.

And to clarify some more:

  • Adding Serial1.begin() doesn't cause any failure, on its own?
  • Grounding RX1 doesn't cause any failure, on its own?
  • Doing both causes the sketch to halt?

Can you add a debug print (eg. using Serial2) like "starting" (in setup) and see if the sketch simply goes into some sort of loop, or in fact restarts.