I did that too–there’s no difference in behavior. It’s exactly the same as I showed in the previous screen shots I posted. I just didn’t grab new ones of that today as it would be redundant information, and just more information for you to wade through.
I should have mentioned that though, so thanks for reminding me.
TB
Hi all,
Thanks for investing time to this problem and i have also just tested the problem myself. After some debugging, i have figured this is a big mistake on our half. The pinout diagram was incorrectly labelled and caused all the issues. I have updated the pinout digram on the wiki and bazaar page. Please also check below image for reference.
And you were correct, RX and TX on the 4-pin header refer to Serial2 in Arudino, and RX and TX on the 28-pin header refer to Serial1 in Arduino. For more, the USB serial is just Serial.
Sorry for the problems caused and thanks again for spotting out.
Anson
Wow! How did that get so screwed up?!? LOL…
I will test it today with the new pin mapping, but I hope I (we) didn’t screw up anything due to using the wrong pin assignments. It’s also good to see that there will be another UART available (Serial2).
Regarding Serial vs SerialUSB though, @ansonhe97… I have tried to get output using “Serial” on the Arduino IDE serial monitor, and it just didn’t work. The “SerialUSB” object (in code) worked fine. So I can’t necessarily agree with that part of your post–but I will certainly test it again today. But with the test code I was using yesterday, I should be able to test all the serial ports. I am quite shocked though, regarding what you now say is the placing of the voltage rail and ground pins!
The other day I wondered about whether or not the pins were mislabeled on the board, so I went to the Arduino online store and looked at the Zero board. But since it is laid out like the Uno, there really isn’t a way to tell anything for sure as to whether or not the Odyssey board might be mislabeled.
Do you think there is a chance that I have damaged my board through testing, with these incorrect pin assignments? (EDIT: I don’t think so–see below in my next post). I don’t have the old pin assignment diagram to look at on the computer I am writing this on now, but the power rails were NOT in the same location as they are in your current diagram. So I hope I didn’t mess up the GPS either–although I was seeing normal output when I probed it with the logic analyzer yesterday.
Anyway, I’ll test the new pin assignments here and report back a little later today.
Thanks for working on this.
TB
I am testing this again in my electronics lab. Here are today’s findings:
I was mistaken when I wondered (in my earlier post today) if the power rail and ground pins changed in position. I see now from the diagram I was using yesterday, that they were where @ansonhe97 has listed them in the new diagram. I was upstairs when I wrote my first post this morning, so I didn’t remember correctly. But I was in fact using the power pins where they were indicated in both the original and the new diagrams. Checking the voltage on both pins now just to be sure, I do read about 3v3 on pin 24, and around 5v on pin 26.
There doesn’t seem to be a Serial2 object recognized by the Arduino IDE for the SAMD21 library. I grepped for it under the /home/user/snap directory where the Seeed stuff gets installed by default–but it’s not any source or header file. See the output of grep, here: https://pastebin.com/mQ3N6j3q
That said, it IS in the Arduino core code, in /snap/arduino/. I didn’t post a grep output file as it’s in LOT of places in that directory tree–but the SAMD compiler is apparently not looking there. This brings up a question:
Should we be installing the Arduino SAMD Boards library as well, in the Boards Managers utility in the IDE? I don’t know if the arm-none-eabi-g++ compiler that Seeed Studios has configured for this board is actually looking there…so I thought I should at least ask.
SerialUSB IS the serial object we need to be using in order to get output from the Arduino serial monitor. I am positive of that. I’ve tried using the “Serial” object in code many times (including again just now), and there IS NO OUTPUT on the serial monitor. Change all the “Serial” calls to “SerialUSB” and you get output immediately.
I strongly suspect that here is still a major issue with the serial functionality of this Odyssey board, in general. Although I no longer seem to lock up the serial monitor after trying to send characters to the board three or four times, I still must force-kill it in Ubuntu. It seems that I can now send characters as many times as I’d like, and the serial monitor (and IDE) continues to function. However when I then try to close the serial monitor using the little ‘X’ button in its upper right corner, the entire IDE locks up. Neither the IDE nor the serial monitor responds after that–and I must force-kill them and start over. I didn’t try this on Windows yet–only Ubuntu. Maybe @wx4cb or someone else can confirm this behavior.
So although I appreciate it that you looked into this issue @ansonhe97, it’s far from being correct. The only thing that I can really see that’s changed is your diagram of the pins on the 4-pin header (swapped Rx/Tx positions), but I cannot test this because the Serial2 object IS NOT recognized by the SAMD21 compiler (arm-none-eabi-g++). Therefore I cannot test and farther.
I am happy to report that placing the logic analyzer on the Rx/Tx pins on the 4-pin header no long causes the board to reset (YAY!!!), and I do NOT see that semi-symmetric square wave signal. I suspect that is because I was actually reading the RST pin signal (LOL!!!), which likely explains the weird waveform I was seeing previously.
TB
ill take a look now, vbut this is the previous image:
Yes–I have saved it on my lab computer, so I was looking at it down there earlier today. That signal is I showed in the screen shot I posted, was coming off the RST pin as it turns out–because that’s the pin that was labeled “TX” in the old diagram. I should have figured that out before he corrected the pin diagram, but there were a number of things going on so I couldn’t quite converge on the problem.
I’ll stand by to hear what @ansonhe97 can find out about the Serial2 pin issue. I suspect there is something missing from the Seeed library that got downloaded in the Arduino IDE, because the ARM compiler being invoked certainly doesn’t know anything about the Serial2 object, as my grep output indicated.
Thanks for working on this.
TB
ok quick sketch pumping out in the loop:
“SerialUSB” is the monitor
“Serial 1” is the D0/D1 pins
“Serial” is the 4 pin header as described.
Now to try input
here’s the code I used:
int i = 0;
void setup() {
// put your setup code here, to run once:
SerialUSB.begin(115200);
Serial.begin(115200);
Serial1.begin(115200);
}
void loop() {
Serial.print(“Serial Loop #”);
Serial.println(i);
Serial1.print(“Serial1 Loop #”);
Serial1.println(i);
SerialUSB.print(“Serial USB Loop #”);
SerialUSB.println(i);
i++;
delay(500);
}
Oh–it’s “Serial” in the 4-pin headers?!? He said Serial2 so that’s what I checked for. But I’d certainly take Serial!
I had a furnace & A/C guy come to the house while I was down in the lab working, so I didn’t get a chance to fully test some things. I also wanted to test my code on a Teensy too, just to “sanity check” it’s behavior there.
Can you reproduce the IDE freeze problem I’m seeing? Try sending characters a bunch of times in the serial monitor text entry field. Then see if the serial monitor (and IDE) locks up either 1) while trying to send additional chars, or 2) when you try to close the serial monitor. Please let me know what you find out.
TB
that said, I did just have the serial monitor lock up the IDE
yup ok that’s the deal…
There’s still framing errors occasionally but i think that’s more of a buffer issue on the library or uart.
i’m running 115k2 and here’s the sketch below.
Wiring was:
FTDI from windows machine to 4 pin header
28 pin header D0/D1 to 40 pin header RX/TX and using cutecom with /dev/ttyS4 @ 115k2
/*
Multiple Serial test
Receives from the main serial port, sends to the others.
Receives from serial port 1, sends to the main serial (Serial 0).
This example works only with boards with more than one serial like Arduino Mega, Due, Zero etc.
The circuit:
created 30 Dec 2008
modified 20 May 2012
by Tom Igoe & Jed Roach
modified 27 Nov 2015
by Arturo Guadalupi
This example code is in the public domain.
*/
void setup() {
// initialize both serial ports:
Serial.begin(115200);
Serial1.begin(115200);
SerialUSB.begin(115200);
}
void loop() {
// read from port 1, send to port 0:
if (Serial1.available()) {
int inByte = Serial1.read();
Serial.write(inByte);
SerialUSB.write(inByte);
}
// read from port 0, send to port 1:
if (Serial.available()) {
int inByte = Serial.read();
Serial1.write(inByte);
SerialUSB.write(inByte);
}
// read from port 0, send to port 1:
if (SerialUSB.available()) {
int inByte = SerialUSB.read();
Serial1.write(inByte);
Serial.write(inByte);
}
}
now im still getting occasional lockups on the IDE when using the serial monitor, but that’s irrelevent now that I know what pins are what and that the 3 serial ports all work as intended.
also, don’t forget that you can also access the serial monitor/usb via the /dev/ttyACM0 port in linux too 
@ansonhe97 i think what we need to do is to update the wiki with the information i just provided in the previous couple of posts and also. maybe some “hard” documentation on how to access etc. you are welcome to use the above sketches as they are just examples from the library.
It is now a proven fact that with the current released version of the seed library that I have here the serial device names are not what you have said. and still it makes sense to leave them as they are now and not even worry about Serial2 - unless that’s another port broken out somewhere that we can play with 
:
With regards to the seeed library, it is my suggestion that you use the correct serial names and at least document them somewhere.
i’ll settle for the 5G PCIE LTE board
Looking at the SAMD21 datasheet, it appears as though we might indeed be able to have 4 UART ports. I see this:
Up to six Serial Communication Interfaces (SERCOM), each configurable to operate as either:
I see one each SPI and I2C bus on the 28-header, and SerialUSB is one UART. So Serial1 and (now) Serial makes three serial ports (5 total SERCOMs). So it’s conceivable that there might be a Serial2 after all. That might be a reason @ansonhe97 mentioned it by name in his post earlier today.
TB
ok i did a quick test with /dev/ttyACM0 in cutecom.
Ther’es DEFINATELY issues on the SerialUSB side. Same setup as before but instead of the serial monitor I just used a dumb terminal on /dev/ttyACM0 (which is what it should be connected to as that 's the progrmaming port too). The IDE was NOT running at all during this test and you can see garbage characters being sent out from the device node.
Ah, there you go. There might well be framing errors on that SerialUSB as well?
I’ll need to look through the BIOS some more. There are settings for some of the pins there, but I can’t recall if it was just for the 40-pin header? I’ll look later today. Maybe there’s something tweaky in there about the SerialUSB?
Did you see any framing errors on Serial1? I found all kinds of them there using the LA the other day, so I am wondering if you were able to confirm them on that port as well.
TB
