Well...That is sort of progress. Cards on the table. I was using my Mimas v2 for other very important PacMan playing purposes today so I'm just reflashing the card with the Linux bin file. I will film my trials and tribulations and share them with you. I haven't found the issues you are discussing to be as bad. I have not ever powered the board other than from USB so I have no experience of using an external power supply. I don't see why it would make a difference though unless the supply being used is a switch-mode supply and is not particularly clean. I haven't really tested this that much so I'm learning just as much as you are. As for the robustness of the system...I think this is all pretty experimental to be honest. The guys at J-core would be the ones to contact with respect to any further issues. I am still available to chat if you like - I've put the time aside.
Ok, so here is what I have found. It appears that programming a bitstream into my board is somewhat problematic. Sometimes it works, sometimes it doesn't. It doesn't appear to depend on whether I am powered over the USB directly or running on an external power supply. It may depend on the length of the bitstream; the sample file has failed to load once, the 115200 file has failed to load multiple times. In order to get the system to come up and operate I appear to have to successfully load the 115200 bitstream, after successfully loading the sample bitstream. Any other combo of operations and I get no I/O from the board, even if the 115200 bitstream has loaded OK. Once the board is running, as long as power remains applied, it seems to work fine. I can reboot it via command or via sw7 and it comes back up no problem if power is cycled to the Numato baord for any reason, the board is back to being dead as far as I/O is concerned, even though it outwardly appears to be booting up normally. Not sure where to go from here. I MAY be able to use it this way (how many reprogramming cycles is the Spartan FPGA good for? ) but it is pretty underwhelming. ML
Alex, Thanks for the support. I think this really smells like something beyond your procedure, as it works if I follow a strange set of extra steps. I still cannot rule out an issue with my hardware. But I don't think tying you up over it makes sense, now that I have been able to get it to work a couple times (now actually 3 times to be exact, each time following procedure shown above...) The first time this worked I stumbled onto the proper sequence by accident. Doing it twice more deliberately has made it work. I would like to stay in touch here if either of us turns up anything that might seem germane to my issues. I will also possibly bring the Numato folks up to speed on my situation, although I suspect they may balk on helping me now that I have a BETA programmed PIC in the mix... In any case I am most grateful for your help. I am sure I could not have gotten this far without your support. I would still be looking at what looked like 'Klingon' coming out of my board at 19200 baud... So feel free to go about your evening and I'll keep you posted if I make any more progress. At least I can tell my boss the board isn't 'bricked' - now that IS progress! best Regards, ML
Mike...I found the below to work repeatably every time. Try these steps please: 1. Disconnect the Mimas V2 board and remove the microSD card - have it close by though resting in the slot. 2. Set SW7 to be closest to the USB connector 3. Load up realterm. 4. Connect up the Mimas V2 to a suitable USB cable and apply power 5. Set the settings on realterm for the correct COM port and 115200 baud, 8 N 1 with no flow control and ANSI settings for the display 6. Insert the microSD card and then connect to RealTerm. 7. set SW7 towards the VGA port and observe the countdown on the seven segment display 8. Watch the boot up of linux on Realterm after the CPU tests are complete. 9. Enjoy. 10. Type exit to safely shut down linux. I'm still learning this myself. I have attached my capture file from realterm which appears to work quite well. Good luck and have a good weekend - it's Miller time for me!
Alex, Have a pint for me Nice thought, but that procedure kills the serial on next boot up. Nothing coming out of the board. Very strange. I'll keep you posted. ML
Hmm...that is odd. It works for me every time. Can you elaborate on what happens when it kills the serial on the second boot? Had my pint...it was a great!
Well, everything looks fine up through step 7 that you list above. When I flip Sw7 to the right (towards the VGA connector) I get a normal boot up sequence indication on all the displays and LEDs of the Numato board, but I never see any traffic coming from the board onto the Realterm display. Any keystrokes I might eventually enter also have no response. At that point. The board is dead for I/O. I found out after this last try that the procedure I have come up with did not recover it yet either. I am hopeful I can be repeating my process. It is like something in the previous bitstream is setting something that is required for the next bitstream to work, or somehow the PIC must not be properly initializing on powerup. I have tried just flipping the Sw7 back and forth a number of times (with appropriate delay in between to allow a boot to occur) thinking that might eventually show a good start. But it hasn't so far. Nor have repeated power cycles either. ML
I'll make a video of my boot up sequence. I did have to show some patience waiting for the serial communications to start. Realterm doesn't indicate anything by the way which is annoying. It just worked.
Mike, I have been playing around with the Mimas and Linux and I believe I have found the cause of the problem. It would appear that the PIC programming the FPGA does not reset properly and so does not always re-initialise serial communications which means that the darn thing won't display any information and therefore no-one knows whether things work or not. Here is what I do know: If you find it won't communicate via the serial terminal, slide SW7 over towards the USB connector, close the port in Realterm and power cycle the board. Then apply power to the board, open the port in realTerm and then move SW7 across. All SW7 does is allow serial communications from the FPGA to pass through the PIC through the USB into your serial terminal program. Type Exit to shut down linux. Typing reboot at the command prompt does not work - there is no way to signal to the PIC that the system needs to reboot. Currently the only way to reset the PIC properly is to power cycle it. I found this site useful for storing the realTerm settings: http://nushair.blogspot.co.uk/2010/06/some-tips-to-use-realterm.html I updated my shortcut settings to the following to ensure that realTerm opens correctly with the settings needed everytime: "C:\Program Files (x86)\BEL\Realterm\realterm.exe" tab=Port Baud=115200 Display=1 Rows=50 Port=3" You may need to change the port number to suit your system. This sets realTerm to start on connected to COM 3, 115200 baud, Ansi Display with 50 rows The steps I took to achieve this are: 1. Connect the Mimas V2 board to the PC and set SW7 towards the USB port 2. Load up Realterm and if required apply the settings required - Baud rate, ANSI etc. 3. Watch the bootup sequence. 4. Once the command prompt appears perform whatever linux commands requird. 5. If you type exit - Linux will shut down but in order to reboot you will have to either power cycle the Mimas V2 board or manipulate SW7. I'll be honest it still isn't consistently booting. I don't have any way to improve this situation. There is no button on the board to physically restart the PIC and MCLR pin is not exposed so we cannot add a button to reset the PIC. Resetting the PIC from the FPGA is not really a good idea as the PIC controls the FPGA. SW7 sometimes manages to reset the PIC but I don't know why...there may be something in the PIC firmware which does that under certain conditions. Without a little help from the team at Numato there is not much more we can do to improve this. In fairness the designers at Numato probably did not anticipate users wanting to run embedded linux on the FPGA. This board is a training and development board for people to learn how to code and control an FPGA.
Alex, that is all great information. My supposition of the issue matches what you have found - that the gate array is booting up correctly but that the PIC ends up somehow not initializing properly when power is reapplied. I will try running through your sequence above and see if I can recover the serial I/O once I have power cycled from a good session. it would be nice to not to have to reprogram things every time just to get the system to come online. Unfortunately, at the end of the day Friday I went through my arcane procedure and still couldn't get the board back online, so that will be the first thing to try to get working going forward. I cannot thank you enough for all the thought and effort you have put into this - my boss is much happier once I got the board to come online the first time with clean I/O, which I was apparently never going to get to work back when I was still trying to run at 19200 baud. It IS interesting that in the 19200 config, the system always had serial I/O every time you would power it up, but it was always corrupted, where now, it takes a bunch of fooling around to get it to come up correctly, but if it does, it is bulletproof until the next power cycle. Definitely smells like a PIC startup issue; perhaps some race condition in the PIC boot code that is borderline at the faster baud rate. Does the PIC code exist as source code anywhere? And if so is there anyway to recompile it? I have some PIC programming experience in my not too distant past (including some serial port emulated over USB code) - too bad we cannot gain access to the PIC source code for the BETA 115200 load. Perhaps it is an easy issue to fix if one had the ability to modify the PIC code being loaded. In any case, I will work through your suggestions from above. If I could ever recover the system without any reprogramming having to have been done, that would be a big improvement. As you say, the Numato folks were likely not expecting this sort of a usage of their board. Although I bet the j-core folks have greatly increased the number of boards they have sold too Best Regards, ML
