AW: AW: [microblaze-uclinux] Xmdstub connect on serial port

["Schunke Jan-Hendrik" <Schunke@shf-communication.de>]

Hi John,

Converint to mcs and writing to prom worked for your bistream. I have tried it with my bitstream but that did not work.
Can you send me your reports (srp, par, mrp, pad, bld) and I can check if I find any differences there?

Thanks
Jan

> -----Ursprüngliche Nachricht-----
> Von: John Williams [mailto:jwilliams@itee.uq.edu.au] 
> Gesendet: Donnerstag, 24. Juli 2003 12:21
> An: microblaze-uclinux@itee.uq.edu.au
> Betreff: Re: AW: [microblaze-uclinux] Xmdstub connect on serial port
> 
> 
> Schunke Jan-Hendrik wrote:
> 
> > Hi John,
> > 
> > Your bitstream does not work either :-(
> 
> hmm..
> 
> > 
> > I have a revision 1 board. What board do you have? I know that the 
> > added quite a lot decoupling capacitors to rev 3.
> 
> yes also revision 1.
> 
> > When I run loopback I get
> > 
> > Com1:
> > Hello from debug UART
> > Hello again from debug UART
> > ^w~~
> > 
> > Com2
> > Hello from console UART
> > Hello again from console UART
> > ^w~~
> > 
> > Having typed Hello on the Terminals so there might be a problem.
> 
> make sure you have your terminal software set to flow control: off
> 
> > Also when I use dip sw 1 to reset the messages should be 
> reprinted on 
> > the terminal, right?
> 
> Yes.
> 
> > That does not seems to work well. Only once in 10 tries, I 
> would say.
> 
> Something flakey there for sure.
> 
> > Why do not you use a pushbutton, for example the reset 
> button. That is 
> > connected to an external reset generator that makes sure 
> that you do not get any debounce problems.
> There is no good reason, the mbvanila platform is an 
> evolution from my 
> earliest microblaze designs, at one stage the reset moved 
> onto the DIP 
> switch and has stayed there!
> 
> > Also I would suggest that we put the reset signals of the 
> dcm's onto 
> > an external pushbotton and the locked signal to a user led. 
> That makes 
> > debugging hardware a little bit easier. I will do this for 
> my design 
> > and send you the chandes as soon as I have time.
> 
> Yes, I've done this before - actually what I have if you look 
> at the way 
> the DCMs are handled in the design, the external reset triggers the 
> "primary" DCM's reset, whose "locked" signal then is inverted 
> onto th e 
> next DCM's reset, and so on.   I haven't had any problems 
> with this so 
> far, mbvanilla starts every time as far as I can tell.
> 
> One thing that might be relevant, I always convert my bit 
> files into MCS 
>   prom files and put them on the XC18V04 and configure from that - it 
> makes things much more reliable.  The bank of 4 jumpers on the board 
> (M0,M1,M2 and one other) are all closed on my board.  I 
> program the PROM 
> via JTAG then just hit the "program" button on the board to 
> reconfigure.
> 
> I've seen the kind of random stuff that you are reporting, absolutely 
> mystifying things where designs that previously worked seemed to fail 
> for no reason, including the xmd connection failures you are 
> describing. 
>   I rarely found good explanations for them.
> 
> Let me know how you go with these other ideas - we'll get it 
> sorted out 
> one way or another.
> 
> Has anyboy else had strangeness with the mbvanilla design?
> 
> John
> 
> 
> ___________________________
> microblaze-uclinux mailing list 
> microblaze-uclinux@itee.uq.edu.au Project Home Page : 
http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/



___________________________
microblaze-uclinux mailing list
microblaze-uclinux@itee.uq.edu.au
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/