Go Down

Topic: MKR Problems - Serial Monitor, COM ports, Libraries, etc. (Read 443 times) previous topic - next topic

Ralph100

I started working with the Arduino Mega and Nano and really enjoyed putting projects together with those.

So, when I found out about the MKRZero/MK1000 I was appealed by the small form factor, speed,  larger memory, SD card and Wifi, so I purchased a few of both. This however turned out to be a very frustrating journey.

In the end the only things I got working on the MKRZero, was playing a WAV song from the SD card to a UDA1334A and generate output on the LCD1602 and Nokia5110 displays.

It was difficult getting there though: the MKR seems to change it's COM port at random after every sketch download, the serial monitor mostly does not work (while it's working fine for my other Arduinos) and  compiling sketches generate warnings that they may not work properly "on this architecture" (but they do). I've also tried very hard to get the touch screen to work (which works fine with the other Arduino's (yes I did use the level shifter), but did not succeed.

Must frustratingly, there seem to be few info and examples available online about the MKR's and the problems I encountered. I'm starting to wonder if I'm maybe the only one left still using this not so good Arduino?

pert

the serial monitor mostly does not work (while it's working fine for my other Arduinos)
We'd need a detailed description of the problem to help with that.

compiling sketches generate warnings that they may not work properly "on this architecture" (but they do).
This is about 3rd party libraries. I don't know why a library author wouldn't specify support for architectures that their library is compatible with. People do strange things. A bigger problem that you apparently haven't encountered yet is that some libraries indeed are not compatible with the SAMD architecture of your MKR boards. The AVR architecture based Arduino boards has been around the longest so you'll always find that the support is best for those boards. If you want things to be as easy as possible and you can work within the constraints of the 8 bit microcontrollers, stick with the AVR boards. If you want better performance and learning about the more modern architecture, then you need to be willing to deal with more challenges. That said, the SAMD architecture boards have been around for a good long time now too and the support for these is getting pretty good.

Must frustratingly, there seem to be few info and examples available online about the MKR's and the problems I encountered.
The original Arduino board that used the SAMD architecture is the Arduino Zero so there is a lot more information available related to that board. Your MKR boards use the exact same microcontroller as the Zero so most of the information you find about the Zero will also apply to your MKR boards. There are some exceptions, like the WiFi functionality of your MKR 1000, which is not present on the Zero.

I'm starting to wonder if I'm maybe the only one left still using this not so good Arduino?
Lots of people are using them. Just not so many as are using the AVR boards.

Ralph100

Thanks for your response, you motivated me to give the MKR's one final go. So, I looked on the Zero forum, updated the IDE and libraries and ran this sketch:
 

void setup()
{
  Serial.begin(1200);
}

void loop()
{
 Serial.println("hello");
}

For some reason the port toggles for every upload between COM 8 and COM10, which is less than ideal, but manageable, but more importantly for the first time ever I saw the MKR generating text on the serial monitor! Of course there was still all the stuff I never saw before with the AVR's such as: COM8 suddenly appearing twice in the IDE's Tools-Port Selection, errors like "touching serial port Com8" and "busy port", but by restarting the IDE and disconnecting and reconnecting the MKR's USB cable regularly, I got this sketch to work most of the time.

Strengthened by this result I tried the "Basic Example" of the TinyGPS++.h library, which runs fine on my Nano with the original baud rate of 115200. The sketch uploads to the MKRZero also fine, but unfortunately I again get a completely blank serial monitor. I tried a few other speeds (19200 and 1200) but empty serial monitor all the time. 

My main interest is measuring stuff and trying to put a program together that does something smart with the data. For me personally there's no challenge in spending a lot of time figuring out how to get the basic functionality to work. Therefore, I have decided to take up your advice and go back to the AVR boards. 


pert

For some reason the port toggles for every upload between COM 8 and COM10
The way uploads on the native USB boards like your MKR boards (and also the classic ATmega32U4-based boards like the Leonardo) work is the microcontroller is reset and the bootloader runs. When the microcontroller runs the bootloader code, it is enumerated a COM port by your computer. The microcontroller running the bootloader has a different VID/PID than the microcontroller running your sketch so the computer assigns it a new COM port. After the upload finishes, the bootloader exits and your sketch runs, which causes the computer to enumerate another serial port. Normally what you would see if you watched Windows Device Manager during an upload is first it would show your board's normal COM port (say COM8), then it would get a new COM port (say COM9), then it would go back to the original COM port again (COM8 in this example). If COM8 was in use then the computer would enumerate to another free port. It seems that for some reason on your computer, COM8 is not being freed up during the course of the upload to COM9 and so the computer has to use COM10 when your sketch runs. Then the next time you upload COM10 is still busy so it picks the free COM8 port. Occasionally, people do report this happening, but it's not common. I don't know what causes this.

Of course there was still all the stuff I never saw before with the AVR's such as: COM8 suddenly appearing twice in the IDE's Tools-Port Selection
This is caused a bug in the IDE:
https://github.com/arduino/Arduino/issues/8851
It has already been fixed in the beta version of the Arduino IDE. The thing that causes the double ports listing also causes a problem with the upload. They are two separate bugs, but are triggered by the same thing. The upload failure problem has been fixed in the hourly build of the Arduino IDE, but the hourly build doesn't have a fix for the double ports listing issue. The double ports listing issue is only a cosmetic problem so the spurious upload failure issue is the more serious (even though the upload actually completes successfully even with that issue). Those issues occur with all native USB boards, including the ATmega32U4-based AVR boards like Leonardo.

The Nano, Uno, Mega's microcontrollers don't have native USB capability so they use a separate USB chip to handle that stuff. I find the native USB boards to be more finicky, but they do have some nice extra features like keyboard and mouse emulation and faster serial communication with your computer.

One thing to keep in mind with the native USB boards is that they don't reset when you open the Serial Monitor like the non-native USB boards do. This means that if there is anything printed to serial between the time the sketch starts running and when you get the Serial Monitor open you'll never see it. For this reason, you might like to add this line after Serial.begin():
Code: [Select]
while(!Serial){}
That will cause the board to be stuck in an infinite loop until a connection is opened on Serial (which happens when you open Serial Monitor). That way you don't miss any output. However, if you wanted your sketch to run when you didn't have Serial Monitor open then you would want to comment that line out.

For me personally there's no challenge in spending a lot of time figuring out how to get the basic functionality to work. Therefore, I have decided to take up your advice and go back to the AVR boards.
I understand that point of view. Some people love playing with the bright and shiny new stuff, and enjoy the quirks and challenges that are inherent. Others prefer to stick with the older well supported stuff so they can get to a working project with a minimum of headaches. I tend to fall into the latter category, but I have been using the MKR and megaAVR boards quite a bit lately in the course of my work duties and have been having some fun with them.

Go Up