[hpsdr] Flynn

[Jeremy McDermond]

On Mar 23, 2011, at 8:11 AM, Stijn wrote:

> ***** High Performance Software Defined Radio Discussion List *****
> 
> Hi Chris and group,
> 
> I do think that this procedure has made it to the list sometime, it is the procedure that I was also using.
> At this point and only concerning the programming of cards, I think Metis is a downgrade. It would be great if we could get that functionality back. Not necessarily using Quartus, using HPSDR programmer or a similar program would also do. I would just get rid of the need of pulling cards to up- or downgrade firmware.

There are a couple of issues here.

1)  Pulling Metis to put on JP1.  We decided that the upgrading of cards would be better in the "bootloader" portion of the code instead of in the main image.  We did this for a few reasons.  The first is just so that errant packets won't set your Metis into bootloader mode and you end up programming garbage into your Mercury board.  By making you set the jumper, we make sure there's a fairly low amount of time that you're in a mode that can corrupt flash on the target board.  Second, because of the architecture of Metis, Phil is using lines on the Atlas bus to put the firmware into the flash chip.  If the system were in full "running" mode, this could cause problems with other cards in the system.  This made it make more sense to require bootloader mode for the flash programming.

2)  Specific card placement.  The programming procedure for a card other than Metis requires that we first, via JTAG, upload a "helper" FPGA image into Mercury of Penelope.  We then use that image to program the flash.  This is because the flash chip is not directly on the JTAG chain.  After this "helper image" is loaded, we then send the image to be programmed into the flash.  Phil is reusing Atlas bus lines to transfer the flash image, so this means that there has to be a very specific configuration for it to work.

We could eliminate the JP1 requirement conceivably, but I think it'd be a bad idea.  It would still require that you place the cards correctly, so while you're in there, you might as well throw on a jumper.

This may be perceived as a step backwards for some users.  For Mac users (and probably Linux users), it's a leap forward.  Our programming procedure before this was "you don't."  Quartus Programmer doesn't run on the Mac, so to upgrade our boards required that we obtain Windows, load Quartus Programmer and perform updates from there.  If you didn't happen to own a copy of Windows, you were SOL.

Hopefully it helps explain why we made some of the decisions we did.  It actually took Phil and I (more Phil than me) a significant amount of effort to reverse engineer the protocols and come up with a programming procedure that would work at all.  We really didn't want to make people run out and buy USB Blasters just to be able to update things.

> Don't see this as criticism against Metis or it's developers, as an interface for the radio I think it is a giant leap forward against Ozy.
> 
> 73 de Stijn PE1RKS

--
Jeremy McDermond (NH6Z)
Xenotropic Systems
mcdermj at xenotropic.com




 1300905410.0