Project Logs

Collapse

• Fritzing Part

  Blecky • 06/12/2017 at 07:56 • 0 comments

  I have added a basic Fritzing part to the EEEmu repository - https://github.com/EEEmu/Assets/tree/master/Fritzing
  

• Rev 2 Boards Arrived

  Blecky • 06/11/2017 at 10:12 • 0 comments

  The Rev.02 EEEmu boards have arrived. The boards are looking pretty full, but they are the same size (51.5x20mm) and still have single sided component placement to make manufacturing easier.

  The Rev.02 boards have quite a few changes:

  • Extra GPIO break out pins.
  • High-Z control for SPI outputs.
  • Modified diameter for programming pin holes.
  • New footprint for 4UCON SD card slot.
  • USB voltage monitoring for smarter sleep states and operation.
  • Additional resistors to comply with JTAG spec.
  • Placement fixes for parts.
  • Better silkscreen text sizes.

  These should be made up shortly. The only change before production for this board is to swap the USB footprint for the new connectors.

• Testing Connectors

  Blecky • 06/11/2017 at 08:23 • 0 comments

  I've been recently looking for a cheap supply of USB and SD card mounts/connectors to bring the costs of the board down (some SD card mounts from other manufacturers are a few dollars each even in large quantities). I found what seems to be a decent supplier of all different connector styles from 4UCON, however they took a while to send samples, because they normally do business in larger quantities. They eventually shipped and arrived in the end.

  From left to right the part numbers are 15882, 20696 and 11071.

  The only downside if that they don't have much in the way of datasheets, only that we can assume the plastic insulator is a Liquid Crystal Polymer (LCP) with a UL94V-0 flammability rating (with the 11071 connector being LCP with glass fiber).

  So what sort of characteristics or tolerances do these connectors have under reflow conditions?

  Read more »

• EEEmus Can Run Fast

  Blecky • 04/28/2017 at 19:15 • 0 comments

  One of the main design constraints behind the EEEmu SPI is that it has the ability to emulate some of the faster Flash SPI chipset specifications to allow for BIOS Flash ROM emulation.

  Enter the SAM4S. These 120MHz ARM based devices are capable of running with various programmable delays for flexible SPI compatibility and an SPI slave frequency of 25MHz. This speed is a reasonable compromise on price and performance and covers most use cases for embedded design.

  These microcontrollers are no slouch when it comes to performing operations either. However this is not the only hurdle when designing such a system. The choice to allow users to store the ROM information on an SD card also brings about significant design considerations. SD cards by nature are a sector addressable device and cannot be read byte by byte like traditional EEPROM. So how do you get low latency performance out of a setup like this?

  Firstly you must consider that the speed of the card plays a significant factor. So choosing the right card is crucial to getting decent performance. For testing, a card with a read write speed of 95MB/s has been chosen. This speed of card has been selected to allow the lowest reasonable latency while operating at higher SPI bus speeds. Secondly, we don't want to tie the CPU up with performing SPI and SD transactions. The good thing is these devices have their own SPI and HSMCI peripherals which do most of the work and provide data as registers when available. Once the hardware side of things is sorted, you then move onto software.

  Initially through testing a sequential SPI read transaction from a ROM file, the system would take around 320us to read the next sector once the SPI interrupt requests byte information on the sector boundary (every 512 bytes). This was by no means good enough. The EEEmu sources use the Atmel ASF libraries to operate the SD Card, SPI interface and FAT(32) filesystem.

  These libraries are "basic" and designed to run the demonstration application. A few tweaks are required to get them running the way you like. The first main issue with these libraries is that they will first do a check to see if the SD card is inserted. This first check has a massive timeout delay of a second to make sure the insertion has "debounced". Subsequent checks don't have this debounce delay however. So to speed things up on startup, this delay is removed on the first check only and if the card is removed while running, the check will be performed again. It turns out they also had several nested redundant checks (4) to see if the SD card was still inserted and operational on every byte read, even if it was reading from the FAT library’s sector buffer.

  Once fixed, the performance was much, much better, but still not good enough for 25MHz. To operate a byte addressable ROM format, you must tell these FAT libraries to perform an f_lseek operation to access the byte you are looking for. Unfortunately this seeking is a little slow, even if it’s from the sector buffer. So you have to put statefulness procedures in there to check if the next byte to read is the byte being requested and to ignore the use of f_lseek (note that on each byte read operation, the byte pointer moves to the next byte for the next read).

  After all of this, we bring the read latency on a sector boundary down to around 10us or less (with no perceivable latency on a next byte read). While a whole lot faster than 320us, it can still be much better (for example for loading BIOS program data), considering we want operate up to an SPI data rate of 25MHz.

  Enter the Buffer

  One thing these embedded FAT libraries lack is decent buffering. This is due to the fact they are designed to operate within small memory restrictions and multitasking is difficult on smaller microcontrollers. Well the SAM4S has a fair bit of memory, so why not use it?

  Well we don’t want to use it all because we will want a large buffer for optimal write operations and RTOS task stacks, so let’s get smart...

  Read more »

• The EEEmu Lives

  Blecky • 04/24/2017 at 13:33 • 0 comments

  As a first post, I just wanted to give an update on where the EEEmu SPI development currently is.
  

  I started designing this project around the end of February this year after I became frustrated with having to manually re-flash 20 out of warranty server BIOSes. These machines needed updating to work with some specific PCI-e hardware, and unfortunately they would brick after a software based flash. Pulling the ROM, manually flashing, then re-inserting worked, so it wasn't a firmware issue. Since the manufacturer was less than helpful, other than to suggest to RMA them, I wondered how I could provide a quick, easy and software-less update method to prevent this issue from ever occurring.

  Development of the first prototype board then started in March. Things have progressed rapidly since then and I hope to have everything on the prototype fully operational by mid May. From there, a new revision of the hardware should be finished and I will start producing the first batches of boards after testing.

  This project has been designed to be produced easily on a smaller scale. I now also have the capability to build small batches myself (about 100/day). The plan is to have these boards available on Tindie as soon as they are ready.

  So onto the current status. All the code for the USB mass storage, SD card, configuration files and SPI is currently operational. The emulation code is still being worked on as I want it to be as flexible and easy to use as possible. Code will be made available once this and the firmware bootloader is finalised.

  The hardware on the prototype is also fully working. The dual power supplies work under all conditions without fault. The level conversion works as expected with different voltages (1.8-5V) and the SPI works well at 25MHz:

  Testing SPI reads from a ROM file stored on the SD card with a Teensy 3.2 @ 25MHz
  

  Connecting the Teensy to the EEEmu SPI is easy:

  Everything is coming together quite nicely without too many issues. I did have a minor one which "bricks" the ATSAM4S2B MCU. When entering a certain sleep state, the system controller switches off the internal 1.2V regulator, which then powers off the ARM core and prevents it from being programmed afterwards. There is a flash erase pin that you can bring high on startup for 10 seconds to erase the flash, but this is a frustrating design decision made by Atmel/Microchip.

  That's it for the moment. Stay tuned for more updates!
  

View all 5 project logs