1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Numato Mimas V2 Serial Console Responses Dropping Chars

Discussion in 'FPGA Boards' started by another_mikey, Jun 14, 2016.

  1. another_mikey

    another_mikey New Member

    Joined:
    Jun 10, 2016
    Messages:
    16
    Likes Received:
    3
    Trophy Points:
    3
    Gender:
    Male
    Location:
    Longmont, CO, USA
    Hi,

    I am running the Linux load on the Numato V2 Spartan 6. I have successfully flashed the bitstream into the board for the SuperH CPU and I appear to be booting up to Linux OK. My problem is I get corrupted responses back from the board over the serial console. A simple 'ls' command will return a list of the / directory, but with characters dropped. I started out running the specified baud rate (19200) and 8 bits, no parity and 1 stop bit. I have now tried most every combo of parity and stop bits with both 7 and 8 data bits, at many of the baud rates between like 9600 on up to 115200 and cannot get a clean print coming back. This is running Windows, having tried with 2 separate computers and running 2 separate terminal programs (HyperTerminal and PuTTY.) I have also tried swapping the power source jumper and powering the board off a a separate supply instead of the USB, with no improvement seen. Interestingly, the data that I send to the board seems to be interpreted correctly, as I can change directories (do a 'cd dev' for instamce) and then do an 'ls' command, and I am obviously listing out the contents of the dev directory. But it is dropping (or sometime misprinting) maybe every 3rd or 4th character, which makes things very hard to read to say the least. Sending ls 3 times in a row results in 3 outputs that are mostly the same, but always slightly different. Certain settings of data bits, stop bits and parity can make the output worse, but nothing gives me a clean print.

    Can anyone shed light on exactly what the comm parameters are to make this work? Is it required to run under Linux instead of Windows to talk to the serial console? Any insights would be appreciated, as the system is pretty unusable with this problem ongoing.

    Thanks bunches,

    Mike L.
     
  2. mistery

    mistery Member

    Joined:
    May 26, 2015
    Messages:
    66
    Likes Received:
    4
    Trophy Points:
    8
    Gender:
    Male
    Location:
    Zagreb
    Home Page:
    I have tried SuperH but with 115200 numato firmware and it is working nice.
    I use linux screen program to connect to the board.
    If you using 19200 (default firmware) then you need to use the same speed in program and bitstream with 19200.
     
  3. Alexander Lang

    Alexander Lang Member

    Joined:
    May 17, 2015
    Messages:
    81
    Likes Received:
    15
    Trophy Points:
    8
    Gender:
    Male
    Location:
    Manchester, UK
    The first time I tried this I must admit I saw issues similar to those Mike L is describing. I then changed my Terminal program and found the issues went away. I would like to reassess this and see if I can find out where the issues lie. I am like Goran using the 115200 baud firmware....we both upgraded ours so we could make use of the arduino build :D.

    I will post details of my investigation later.
     
  4. another_mikey

    another_mikey New Member

    Joined:
    Jun 10, 2016
    Messages:
    16
    Likes Received:
    3
    Trophy Points:
    3
    Gender:
    Male
    Location:
    Longmont, CO, USA
    I loaded the prebuilt vmlinux image from here:

    http://j-core.org/downloads/linux/vmlinux

    I did not see any variations on different versions to download (there is only one file present), nor any mention of what baud rate there. Likewise, I loaded a prebuilt binary from here:

    http://j-core.org/downloads/binaries/mimas_v2.bin

    I see no mention of baud rate there either. With my existing setup I have already tried both 19200 and 115200 (and a bunch of rates in between) with no success.

    Can someone verify for me if it is using 8 data bits, 1 stop bit, and no parity (or if not, what those settings need to be?) I am not sure how much some of the settings (like stop bits) matter when running serial over a USB emulated serial port, but might as well have them set as intended in any case.

    Mistery, I have not tried the screen program in Linux, I will have to see if I can get that up and running. I have tried 2 terminal programs in Windows, getting ready to try some more in Linux. Alexander - where you running the terminal software under Windows or Linux? Could you pass on the name of the terminal software that you ended up using to make your system work OK?

    Do I need to investigate building my bitstream from source just to make this work?


    Thanks bunches for the replies,

    ML
     
  5. Alexander Lang

    Alexander Lang Member

    Joined:
    May 17, 2015
    Messages:
    81
    Likes Received:
    15
    Trophy Points:
    8
    Gender:
    Male
    Location:
    Manchester, UK
    Hi Mike,

    Both Mistery and I updated the stock firmware on the PIC micro which is used to flash the FPGA with a custom version. The custom version communicates at 115200 baud. I will send you the hex file and provide instruction on how to update your Mimas V2 to use the faster baud rate. If you intend using linux on the Mimas V2 you will need it! A word of caution however...there is no current method of returning to the previous firmware so once you flash your Mimas that is it. Neither Mistery or myself have had any issues with doing this.

    Once you have increased the baud rate you can then reflash the FPGA with the linux bit file - which I will also supply!

    I have tried using puTTy in windows as a serial terminal and found issues similar to those you described.

    I then tried realTERM and found that to work with no issues.

    I will attach the bit files and talk through how to update the firmware when I get home - still supposed to be working at the moment!

    Hopefully that should sort your needs out!

    Alex
     
  6. another_mikey

    another_mikey New Member

    Joined:
    Jun 10, 2016
    Messages:
    16
    Likes Received:
    3
    Trophy Points:
    3
    Gender:
    Male
    Location:
    Longmont, CO, USA
    Alex,

    Thanks so much for your help, that sounds great.

    ML
     
    Alexander Lang likes this.
  7. Alexander Lang

    Alexander Lang Member

    Joined:
    May 17, 2015
    Messages:
    81
    Likes Received:
    15
    Trophy Points:
    8
    Gender:
    Male
    Location:
    Manchester, UK
    mistery likes this.
  8. another_mikey

    another_mikey New Member

    Joined:
    Jun 10, 2016
    Messages:
    16
    Likes Received:
    3
    Trophy Points:
    3
    Gender:
    Male
    Location:
    Longmont, CO, USA
    Alex,

    Thanks, I will let you know how I make out. Much appreciated,

    ML
     
    Alexander Lang likes this.
  9. another_mikey

    another_mikey New Member

    Joined:
    Jun 10, 2016
    Messages:
    16
    Likes Received:
    3
    Trophy Points:
    3
    Gender:
    Male
    Location:
    Longmont, CO, USA
    Alex,

    A quick update. I have soldered in the 2 pin header to allow for reprogramming of the PIC. My boss is was a little leery about me flashing that part to beta version code with no exit strategy, but I think he has now agreed to it.

    Your step by step instructions seem very thorough and clear, so seems like it will be simple with your excellent provided guidance. I'll let you know how it goes...

    Best Regards,

    ML
     
  10. Alexander Lang

    Alexander Lang Member

    Joined:
    May 17, 2015
    Messages:
    81
    Likes Received:
    15
    Trophy Points:
    8
    Gender:
    Male
    Location:
    Manchester, UK
    Mike, you don't have to update the firmware if you don't want to. It just means that vmlinux will run slowly.

    The most important part was the serial terminal settings to display in ansi format which prevents the odd characters.

    If your boss is concerned test it with the slower serial communications first and then if needed try the faster build.

    I would be interested to know what your final goal is...I haven't found many programs which cross compile for vmlinux. I think there is more work to do before it becomes useful.

    Good luck
     
  11. another_mikey

    another_mikey New Member

    Joined:
    Jun 10, 2016
    Messages:
    16
    Likes Received:
    3
    Trophy Points:
    3
    Gender:
    Male
    Location:
    Longmont, CO, USA
    Alex,

    WEll unfortunately, I seem to now have an issue I cannot fix. I went ahead and uploaded the new firmware to the PIC, and then reloaded the new 115200 bistream to the board. It appears to boot up fine, but now get I no response back from it at all. The boot sequence looks like before (short blue LED, followed by the 888 with 3 of the green LEDs lit, followed by the countup on the 7 segment display, followed by 3 dashes. But I never see anything on my terminal, using either Hyperterminal or realTERM, both of which were giving me responses before. I didn't reload the vmlinux file to my card, as it appeared your link just went to the j-core.org page, where I had downloaded it from the first time.

    Given that I cannot go back to my original setup, do you have any ideas?

    I do know that my original issue (whatever it was) was more than just getting strange unprinting chars in my output. I did try realTERM on my system before changing anything and the results I got looked basically identical to what I was getting with Hyperterminal.

    Best Regards,

    ML
     
  12. Alexander Lang

    Alexander Lang Member

    Joined:
    May 17, 2015
    Messages:
    81
    Likes Received:
    15
    Trophy Points:
    8
    Gender:
    Male
    Location:
    Manchester, UK
    Hmm....have you started from the beginning.

    Close the serial terminal....
    Disconnect the Mimas V2 from the USB
    Set Sw7 to the left
    Reconnect the Mimas V2.
    Load up serial program...
    Connect it to the com port relating to the Mimas V2.
    Set the switch Sw7 to the right
    Watch the seven segment and the display.
    Linux should boot and there should be things on the display.

    If you like I can post a video on YouTube.

    Good luck
     
  13. Alexander Lang

    Alexander Lang Member

    Joined:
    May 17, 2015
    Messages:
    81
    Likes Received:
    15
    Trophy Points:
    8
    Gender:
    Male
    Location:
    Manchester, UK
    If you still need some help email me or we could chat on Skype or Google Hangouts.
     
  14. another_mikey

    another_mikey New Member

    Joined:
    Jun 10, 2016
    Messages:
    16
    Likes Received:
    3
    Trophy Points:
    3
    Gender:
    Male
    Location:
    Longmont, CO, USA
    Alex,

    Thanks for the reply. yes, I have followed the procedure as described.

    I did have some initial issues the very first time I went to load the mimas_V2_115200.bin file. I didn't mention it intially as it seemed to get sorted out. perhaps in some fashion it caused an issue? The first time I went to load that bitstream, after the reprogramming of the PIC itself with the jumper connected (which went with no issues), the programming halted about 2/3 of the way through with an error. Since I was self powering off the USB port at the time, I decided to try again with the power jumper moved over to external power, and a cable going to an external power supply set to 5v. In that configuration, it programmed without a hitch. But as stated above, although all indications are that it is coming up and booting as expected, I get no comms between my laptop and the mimas board (making sure the Sw7 is swapped back to the proper config...). No boot messages and no responses to any typing. RealTerm shows the TX line state changing momentarily when I type (as expected) but I never see any RX traffic.

    I have gone all the way back to start and reflashed the PIC (on external power as well) and then again programmed the 115200 enabled bitstream into the FPGA, following all the steps for Sw7 states, etc. It would appear that the Beta load into the PIC has, for some reason on my board, broken the serial comms. I even tried booting up without the card installed to see if I got the intial message that is supposed to come out about not finding Linux.

    I appear to be now unable to get any I/O out of (and probably into as well) the FPGA based SuperH CPU, even though I suspect it is booting up just fine.

    So do you know why the original firmware load for the Numato board is not available? In my case, if I had it I could presumably go back to my original configuration, and at least have garbled traffic. Right now I have bricked my board. They obviously have the file internally. Do you know of any contacts there? Since I have already voided my warranty for this baord anyway it is hard for me to see why they wouldn't be willing to let me have that file to get things back to where they were.

    It is starting to feel to me like I may have had a defective board in the first place, that I have now made un-returnable :)

    In any case, I don't blame you, as it is clear your procedure worked fine for you, and seems like it also should have worked for me. Since I am still able to either flash the PIC (but only have the beta file) or load the FPGA (both the original mimas_V2 and the 115200 version appear to load OK) but cannot communicate, that if I had the right file I might be able to restore my limited functionality.

    My original task with this board was to get it up and running and try to run some benchmark code on it to see how those results compared with the real, non-FGPA full in silicon published benchmarks. of course, I have not even started trying to figure out how to comile on/for this CPU, or what benchmarks might have been out there, or what type of timings might ever have been published for this CPU running as a native chipset. of course, that is all moot now unless I can somehow still make this work, or buy another board and manage to make it work.

    This stuff is fun when it all plays - not so much in cases like this :)

    To top things off, we are having company-wide internet and internal networking issues today (it's currently up now, but no guarantees...). But if you have some availability tomorrow (accounting for the time differences between us) that overlaps with mine, perhaps we can rig up some sort of a chat that lets us walk through a few of these steps in real-time, if you are willing.

    Best Regards,

    ML
     
  15. Alexander Lang

    Alexander Lang Member

    Joined:
    May 17, 2015
    Messages:
    81
    Likes Received:
    15
    Trophy Points:
    8
    Gender:
    Male
    Location:
    Manchester, UK
    Mike...let me know when you are free and I'll talk you through it.

    I have a couple of things I would like to try. I don't believe the board is defective although interrupting programming the FPGA isn't a good idea.

    Try flashing something else to the FPGA. Do you have any other bin files you can try. If that works then the board works...

    It's getting a bit late here so I can't help now. Email me tomorrow with a suitable time and I'll sort something out.

    Cheers

    Alex
     
  16. another_mikey

    another_mikey New Member

    Joined:
    Jun 10, 2016
    Messages:
    16
    Likes Received:
    3
    Trophy Points:
    3
    Gender:
    Male
    Location:
    Longmont, CO, USA
    I can reload the sample file. That would verify that the bitstream flashing process is still working OK and that the FPGA is still running OK. I'll try that today before I leave and then try to ping you early my time tomorrow (I think this time of year we are 6 hours behind UTC; not sure what your time zone is in relation to that) and see if we can coordinate. Thanks again,

    ML
     
  17. another_mikey

    another_mikey New Member

    Joined:
    Jun 10, 2016
    Messages:
    16
    Likes Received:
    3
    Trophy Points:
    3
    Gender:
    Male
    Location:
    Longmont, CO, USA
    Alex,

    Quick update before the end of my work day. The sample bin file loads and runs OK. Board is back to original behavior of counting 7 segment display and walking green LEDs. So apparently, that much is still working even with the new BETA load in the Microchip...

    Will connect with you first thing tomorrow...

    ML
     
  18. Alexander Lang

    Alexander Lang Member

    Joined:
    May 17, 2015
    Messages:
    81
    Likes Received:
    15
    Trophy Points:
    8
    Gender:
    Male
    Location:
    Manchester, UK
    Mike,

    Good to know that the board is working as intended. I would then if I were you reflash the FPGA with the linux bin file and then reconnect everything up and check the serial terminal. I admit that sometimes I found that the response from the FPGA was not always perfect. I tested it again today and found all was working but I have had glitches like those you describe. As we have a seven hour time difference at the moment it will probably be best to sync up messages etc. 18:00 UK time = 11:00 Loungmount CO time. If you need my help message me at 18:00 and I'll see what I can do.

    Alex
     
  19. another_mikey

    another_mikey New Member

    Joined:
    Jun 10, 2016
    Messages:
    16
    Likes Received:
    3
    Trophy Points:
    3
    Gender:
    Male
    Location:
    Longmont, CO, USA
    Sounds good. I have tried re-flashing a few times but I will very methodically give it another try, and then I'll plan to contact you around 1800 your time.

    Best Regards,

    ML
     
  20. another_mikey

    another_mikey New Member

    Joined:
    Jun 10, 2016
    Messages:
    16
    Likes Received:
    3
    Trophy Points:
    3
    Gender:
    Male
    Location:
    Longmont, CO, USA
    Alex,

    Well, definite progress of a sort.

    Came in this morning, reloaded the 115200 bitstream again (gotta be maybe the 4th or 5th time), brought up RealTerm, hit a few enters, then flipped Sw7 from program to console I/O out, system rebooted and voila! I had the system up and running. Output looked fine, no strange chars (making sure I was in ANSI mode) - everything working! 'It's fixed!" I thought. Before sending out a post here saying all was well, I decided to just make sure it was able to come up properly from a cold start. No go. Spent the last hour trying to get it back online. Lots of false starts with loading of the 115 bitsream, getting errors during load. Finally, by first loading the example bin file, then loading the 115200 bin file, then flipping the Sw7 to the proper position to reboot, I am online again.

    Nice to see it running, but needless to say, things are not reliable at all yet, and having so much trouble getting the FPGA to take the 115200 file is puzzling and very frustrating, to say the least. This has all been done running on external power. My bench supply shows only a draw of slightly over 200 ma when running, so one would think that should not be a problem for even a laptop USB port. I will try going back to USB power only and see what happens, and transfer over to a desktop machine too to see if that has any effect. If I can come up with any sort of a reliable way to bring this up, short of spending an hour fooling with multiple bin file reloads I'll consider this working 'well enough' but until then it is still a problem.

    ML
     

Share This Page