As I was explaining to someone recently, bootstrapping a completely new, custom design is hard. There are no tools or pre-existing software to manage the device (Atmel/Altera tools aside). Everything has to be built from scratch. It’s been quite a while since I started this project to get to this point, but I’m getting close now to a workable infrastructure. Once the foundation is in place it will allow rapid development of the CPC portions of this project. Here’s the UI part of the work so far:
It’s been a while since my last post, so I thought it about time I provided an update. I’ve been working on the supervisory software inside the SAM4 microcontroller.
Here are the planned features for this chip:
- Flash management including flash translation layer
- MRAM management
- Provide an interface to the FPGA to access these two memories
- Provide a debug console for both the monitor program and the FPGA
- Provide an upload facility to both the FPGA and to memory
To date, I’ve:
- Written the MRAM interface, using the Atmel ASF libraries to handle the SPI
- Connected and passed traffic between the FPGA and the SAM4 supervisor using the 40MHz SPI interface
- Started the user interface for the monitor program. At the moment, all it shows is one active item to upload the bitstream to the FPGA and several templated inactive items.
- Connected and can read/write the RAW flash layer
Where I’ve gotten bogged down is in the flash translation layer (FTL). Continue reading
In my last post I pushed a ‘Hello World’ configuration to the FPGA through the JTAG port. Since then, I’ve been working on the Altera Fast Passive Parallel configuration ports. The intention is use the microcontroller to manage the register transfer logic (RTL) configuration of the FPGA. Essentially this means the Altera SAM microcontroller can load a ‘personality’ for the dongle. Personalities will be stored in the Flash memory, loaded as required and pushed to the FPGA.
I wrote very simple data transfer program to ensure a correct transfer from the PC to the microcontroller. Continue reading
Still on a high from my last success, I moved onto testing the FPGA. The only way this would work at the moment, is through the JTAG port. The software that will eventually configure the FPGA through the fast passive parallel port is not ready, and there’s a lot to learn first, so I’m going to leap frog that and use the JTAG port to configure the FPGA to get the LED to blink.
Just like this :
Yes, you read that correctly. I managed to get the board working from my last post. Lucky post 13! I removed the SDRAM chip and the short between GND and the 3.3v line disappeared. Perplexed, I re-checked the data sheet and yes, I’d made a mistake. There are three VCC and three VSS pins. I’d transposed the last two of these. Ah well. This board was never going be the final build anyway, so I just removed the SDRAM chip with my hot air hand tools.
The regulators and inductors were still running hot, so I suspected there was a further issue, but the LED was alight now, which was a good sign. The voltages out of the regulators were a bit low, so I checked some key components, such as the clocks and lo-and-behold, I’d placed the 50MHz oscillator at 90 degrees out. These chips are 2mmx3mm, so excuse this minor fault. I removed the oscillator and the line voltages returned to tolerance and the heat in the regs and inductors went away. Woohoo!
I soldered on the JTAG port for my Atmel-ICE programmer and programmed an initial hello world program. I upped the PLL so that the ARM core ran at 120MHz and it was quite stable. If you switch from low speed to maximum clock it sucks a huge gulp of power from the supply lines, so if the regs, inductors and noise suppression capacitors are not sufficient the core self-resets. I didn’t see any behaviour like that, so I’m confident the Atmel SAM core is good.
I also found a few other stupid mistakes, like I’d provided a jumper to erase the ARM microcontroller, but jumpered it to ground and it needs +3.3v to erase. I also managed to set the security bit while fiddling with the programmer, so I was locked out of the chip. Luckily, the Atmel-ICE cable has two connectors, both a 0.05″ and a 0.1″ pitch connector. So I took 3.3v from this ribbon connector and zapped the erase pin during power up and wiped the security bit, allowing me back into the chip programming mode.
I wrote a quick program to toggle the FPGA configuration lines and managed to get an acknowledgement level-shift on the status line, so all good so far! I tried to get a fault condition, by sending zeros and all-ones to the FPGA, but couldn’t elicit a fault response, so I suspect it’s waiting for specific value before it starts it’s configuration process.
As I write this, I’m installing Altera Quartus on my new HP all-in-one, so that I can create a bitstream simply to turn off the LED (it defaults to on) and see the CONF_DONE line go high. That’s probably some way away, but I thought it worthwhile to report this success after another apparent failure.
I’ll be able to test the other components on this build, so it’s not a waste and I’ll perfect the supervisor programming software and test the remaining components before the next build.
Stay tuned for my next post!
Welcome back to the next part of this retro adventure. Last time, I told you the new boards are back from the fabrication house. These are the same logical design (called schematic) as the previous boards, but use a different and simplified layout and I’ve removed some components to make the assembly easier. I also changed my assembly approach.
I’m pleased to say I had a 50% success rate, which is 49% better than last time! The board assembled beautifully.
Unfortunately, I still have some problems but let’s go through the new assembly process before we go further. As I mentioned last time, I intended to assemble the board using a dry layout process first. This means I can take all the time I need to get the components out of their packaging and lay them out on the board and not worry about whether the solder paste is going off. Continue reading
A couple of weeks after my last post, my new boards are back! So now, I have my new boards from OSH Park, my paste mask from OSH Stencils and my replenished component stocks from Mouser. I have a new plan for assembly and a simpler board. I’m feeling hopeful!
Apart from the simpler layout and fewer components on this version, my plan is to correct the mistakes of the last build. The main changes are:
- Sparing use of solder paste – last time the paste mask moved and spread solder unevenly over the board, outside the pads. Ensure the paste mask is held in place and doesn’t lift to allow paste under the mask.
- Larger (oversize) holes in the paste mask to ensure the 0.8mm pitch devices, such as the SDRAM center bottom in the image, get enough paste to reflow properly.
- Assemble the board dry first and transfer the components quickly from one board to another once the paste is applied. This will reduce the actual build time. If I don’t have a spare board, a laser print of an actual size board would work as well (and might be better).
- The small components will be laid out first. This is at odds with typical build methods, but will allow me to determine if I can accurately place the small components before I commit the big expensive FPGA, ARM microcontroller, Flash and video chips.
There’s no going back on this build, I’m determined to get this working if only partially. If I have an issue in the build, I’ll try to analyse the the fault and if needed I’ll rework the SMT devices using hand tools.
The board is designed from left to right, so only populating the left hand side components will get an element of the board working, specifically the ARM microcontroller and flash memory. So a partial success could be just the ARM micro working, or the ARM and FPGA, or if we’re lucky, the ARM, FPGA and video chips.
I’ve made quite a few changes since the last build, so I’m feeling hopeful this one will work. Look out for details in a later post.
While the layout is quite different from the previous version, the schematic is quite similar. I’ll talk through the changes in this version and the method that I used to build this layout. Continue reading
OK, so I had a setback. Not a major one, but enough to make me want to go back and redo the design and incorporate all of the learning to date on this project. The key mantra for me is “simplify, simplify, simplify”. If I can do more of the complexity in software rather than hardware without sacrificing the goals of the project, then I’ll do that.
Below is an updated block diagram. Compare this to the original and you’ll see that I’ve simplified the memory interface to connect through an Atmel SAM4S processor. This will handle configuration of the FPGA as well as handling the system storage and pass the data through the support CPU. The system interface (system I/F) will be a fast interface to the internal structures of the FPGA.
The flash memory is required to be connected to the SAM4S because this will also handle the FPGA configuration through the passive parallel port and needs the storage of the flash device to hold the FPGA images. The MRAM is also connected to the SAM4S as this will be used to manage regular configuration changes and assist with the flash translation layer (FTL).
Moving the storage devices off the FPGA will reduce the number of pins required for connection to the FPGA, making the wiring of this device simpler. I’ve added an ESP32 module from Espressif to handle Bluetooth and Wifi. This won’t be available on the first incarnation of the board, but will be added later as the ESP32 becomes available for sale.
So, same functionality, simplified connections, fewer components.
Watch this space.
Following on from my last post my hardware order arrived from Mouser and RS Components and I set out to assemble my CPC2.0.
This was a nervous build for me because I’ve created complex 4-layer boards before with fine pitch BGAs, but never anything this complex. Something was bound to go wrong.
Still, I was prepped and ready, so time to dive in. Continue reading