I've been using the new 3.5 image for some time now.
It seems that if I pump data through the ttyMFD2 serial port it makes the Edison boot process crash. Note, that I know about the u-boot console and its "Press any key to stop autoboot" feature.
Edison crashes even if I start the data stream after u-boot finishes.
Is there any way to stop this behavior? Or at least debug it?
I would love to help you with this issue, so can you show me the steps that you are doing?
I want to do the same, and check if I get the same error and try to find it.
I will be waiting for your reply to assist you in a better way.
To recreate this issue you need to do the following:
1. Connect to Edison's serial port
2. After u-boot is loaded and you skipped the option to enter its console, u-boot starts loading the kernel with the typical linux kernel console output
3. If you start spamming the console hard at that time, the device will crash, and sometimes, reboot. I was not able to do this with my keyboard, however, pumping a big file to the serial console will help. I used something like cat bigfile.zip > /dev/ttyUSB0
Hope this helps!
I tried to recreate it, but I couldn't. How are you doing the step 3? I can't access to the serial port, because I'm already using it, check this error:
I also tried it on Windows using PuTTY, I pasted like 16 pages of characters on it, but it didn't crash.
I will be waiting for your answer to help you further.
You need to kill screen, minicom or whatever you are using for serial communication on the left screen as this takes the /dev/ttyUSB0 resource. To debug this issue I made some special wires so I could connect two cp2102 chips to the same UART. For you, I think, it will be easier to just monitor if the new USB-Ethernet interface shows up in ifconfig, or whether Edison will connect to a known wi-fi network.
Also, you should use a really big file, I used 200 Mb+ archives for this
I sent a file of 250 MB while the kernel was starting, and it seems that the Edison doesn't crash because the board keeps blinking, but I couldn't star the serial port using the command screen after I did this, so maybe the port crashed.
It is weird, and I need more information to help you more, so can you tell me why are you sending these big files when the kernel is starting?
I will be waiting for your answer.
The thing is I want to use the Edison's ttyMFD2 for data transfer, rather than a user console. Sometimes the unit will be turning on with the data stream already incoming, and sometimes Edison will crash, which is very upsetting. The large files thing is just the most simple way to recreate the issue.
Well, now I understand. Anyways the data that the Edison receives when it is booting is going to be lost. Because the Edison is not ready to read it because he is booting.
In that case I have a little suggestion to avoid this issue. Personally I recommend you to try to use an external buffer that is going to send the data when he receives the signal from the Edison that it already booted and it is ready to receive the data without problems.
Please let me know if you are going to try my recommendation, because this is a weird issue.
Have a nice day.
Yeah, I understand data is going to be lost and that's ok. The problem is this same data stops the device from booting.
The setup I have in mind is connecting a UART radio which might be active during boot. You should try that too. The data stream prevents Edison from booting quite regularly.
What I tried is removing ttyMFD2 from the kernel's console variable in u-boot. However, without a console there, the device seems to reboot in a short while(up to 30 secodns) after reaching multi-user target. You should definitely try that, as this is also really weird.
At the moment my solution is to use ttyMFD2 as the first console parameter and ttyS0 as the second. I believe it makes the first option non-interactive in some ways and therefore Edison does not crash in the circumstances. I've also added quiet to lessen the output.
This is what I have at the moment:
bootargs_console=console=ttyMFD2 console=ttyS0 quiet
I really don't like this solution as it seems like a hack. I wish I could just turn off the console on the UART with no consequences.
We need more information about your issue, so please try to answer the following questions:
Are you sure that your Edison crashes? Is there any LED activity when it crashes?
Does Edison crash with smaller files?
How can you determine if your Edison is receiving the transmitted files/data?
Check this thread, maybe it can be helpful for you: https://communities.intel.com/thread/75745 https://communities.intel.com/thread/75745.
We will be waiting for your answers.
I am sure Edison crashes as it is unusable, none of the network services start and I can't log into it.
Like I said, it's not about the file size, but about a constant data stream on the port.
At this point I am more worried about Edison rebooting if ttyMFD2 is not in the kernel's console parameter.
Thank you for the answers. Please let us work on this, and I'll let you know when we got something helpful.
We really appreciate your patience.
We replicated the problem, and we found out that there isn't a way to fix it, because it isn't an issue since that port is intended to be used to access the console and not to send data like customer is using. Using this port for other purposes require modifications (maybe at kernel level) that are not supported.
Anyways I can suggest you different ways to avoid it:
1. Wait until Edison has booted up.
2. If not possible to wait, I recommend you to use an external hardware that includes a buffer (the same suggestion I gave you before).
3. If you need more than one serial port, you can use a multiplexer to have multiple TX/RX lines, all connected to the RX/TX line of serial port (pins 0 and 1), and select the proper lines using GPIOs.
Hope you find this helpful.
No, I haven't. I ended up using the solution mentioned in one of my posts above.
Your work looks very interesting! I will build a custom image with this kernel, try it and contact you. How's your experience with it so far?
egorf After fixing annoying issue with UART interrupts I couldn't blame much. Since I'm alone (volunteers wanted even for testing) I can't cover many areas, so, that's why it's not comprehensive solution.
It seems you've put a lot of energy into this. This is a good opportunity, so I definitely will test it and provide feedback.
I wonder what intel_corp has to say about your work and about Edison's kernel situation in general.