MP3/FLASH Test Platform (Update 2)

Surprisingly the FLASH portion fired right up and worked.  I am now cleaning up the code.  first step was to correct all the USB descriptors so the Brick Buddy PC software will properly recognize the device.  Since the Brick Controller II will be sold without this module, the firmware had to be modified to only check for the device once and not continually.  Dont need to be wasting PIC32 bandwidth looking for things that are not there.  Other cleanup is needed as I dig into this deeper.  But next I am going to modify the Brick Buddy PC GUI and software to handle the new controller.

MP3/FLASH Test Platform (Update 1)

The PCBs are assembled as shown below.  The MP3 decoder has not arrived yet, thus I will only be testing the FLASH drive for now. 

More later as we progress with the testing.

MP3/FLASH Test Platform

While I am waiting for the main BCII PCB to come back, I am building a test platform for the MP3/FLASH  add on module.  I had developed the code for this module using the Microchip PIC32MX Curiosity Board, a MikroBus Click MP3 module and a MikroBus Click 64Mb FLASH Module.  There is still more code development and I thought it would be better to use the known Microchip Curisoity board to develop on than the new untried BCII PCB. 

I designed a small carrier PCB that would plug into the two MikroBus slots on the Curiosity board and pickup all the signals. 

Then the completed MP3/FLASH module would plug into the carrier board.  Here is a picture of how that will look.

Now all I have to do is assemble the two boards.  The carrier will be easy.  The MP3/FLASH module will be more challenging.  Plus the MP3 portion is handled by a VS1053B and only AdaFruit had them in stock.They are in NYC, so we will see how long this takes for them to come in.

COSMAC 2020 ELF Build (part 1)

Glue Logic Design

One of the first decisions that had to made was how to handle the glue logic.  When I fist started working on this many years ago, my idea was to use an ALTERA (Intel) MAX7000s CPLD.   This was one of the first in system programmable, inputs were 5V tolerant and the outputs could be made 5V CMOS compliant with a pull up resistor.  Well fast forward to 2020 and MAX7000S is only available in the excess inventory market.  Prices are not bad ($10-$30 each for 7128 in a TQFP100), but who knows what you are really getting. 

Why ALTERA (Intel)?  Mostly because it is what I am familiar with and the free software still has schematic entry.  Not motivated to learn VHDL at this point.  That could change, but not for now.  So I then moved onto more active parts, MAX II and MAX V.  Well MAX V was more than half the cost of MAX II and more recent.  So I started looking at this family first.  The CON to these families was limited package options.  BGA packages were out for two reasons, I cant solder these down and they drastically increase the PCB layer count and complexity.  So this left just two packages, EQFP64, TQFP100 and TQFP144. 

They way I partitioned the logic would require at least 3 TQFP100 packages. The EQFP64 just never had enough pins.  With common pins and interconnects eliminated, it would all fit in one TQFP144. Another MAX V advantage was part migration with in a package.  With a TQFP144, there were 4 different parts.  Using the middle part, 5M570Z, I have used 25% of the internal resources and 103 of 114 pins.  This gives a lot of flexibility for future improvements.  Having all the logic in one part is also useful, since only one change is needed.  Finally these parts come with 8KBits of FLASH.  I am going to look at how this might be mapped into I/O for configuration or storing nonvolatile data.

Now for the very big disadvantage to this family and every family after MAX7000S.  There is no simple 5V CMOS compatible interface.  The inputs are not 5V tolerant, a resistor and a diode are needed to prevent damage.  The outputs also need a diode and a resistor to produce a 5V CMOS compatible signal.  Not very enticing.  Looking at some commercial development boards on the market showed they were overcoming this by using 74LVC voltage translators (74LVC8T245, 74LVC1T45 and 74LVC2T45).

So after some soul searching, I have decide to go this way, a MAX V part and multiple voltage translators. Once I finish the design I will publish the higher level CPLD schematics to show how I did this.

Bricks By The Bay 2020

We had hoped that this excellent convention would happen in July.  But the organizers have had to cancel.  They do have a date in Jun 2021 for next year.  They are organizing a virtual expo, how this will happen is still being worked on.  It will be interesting to see how this happens.

For more information, go to the Bricks by The Bay website.

More BC II Progress

The last few days since the last post on this have been trying.  Lots of information to plow through on how to make a bootloader work on a PIC32.  After solving the bootloader connecting as a USB HID device, it was off to loading an application.  This required modifying the linker script.  One would have thought this was straight forward, but it wasn't.  Reading the Micorchip forum found lots of people looking and what appeared to be lots of solutions.  Plus Micorchip had an old App Note (AN1388) that described the process.  So here are the parameters I used

• Bootloader occupies 56K bytes(debug console/lots of printf), allocated 0x1000 space to it.
• The PIC32MX470F512H has 512K bytes of program space, allocated 384K for the App.
• App Space starts at  0x9D01 0000
• Interrupt Vector table is at 0x9D01 0000
• Reset Address is at 0x9D01 1000
• App code starts at 0x9D01 1200

Through basic testing it all works as I expect.  There is still more testing needed and I need to update the PC program I use with my PC based applications.  Any firmware upgrades need to be part of the user application and not a separate program.

The important part of the linker script is shown below. The bootloader linker script was the default with only the length of the kesg0_program_memory changed.

OUTPUT_FORMAT("elf32-tradlittlemips")
OUTPUT_ARCH(pic32mx)
ENTRY(_reset)
/*
 * Provide for a minimum stack and heap size
 * - _min_stack_size - represents the minimum space that must be made
 *                     available for the stack.  Can be overridden from
 *                     the command line using the linker's --defsym option.
 * - _min_heap_size  - represents the minimum space that must be made
 *                     available for the heap.  Can be overridden from
 *                     the command line using the linker's --defsym option.
 */
EXTERN (_min_stack_size _min_heap_size)

/*************************************************************************
 * Processor-specific object file.  Contains SFR definitions.
 *************************************************************************/
INPUT("processor.o")


/*************************************************************************
 * Processor-specific peripheral libraries are optional
 *************************************************************************/
OPTIONAL("libmchp_peripheral.a")

/*************************************************************************
 * For interrupt vector handling
 *************************************************************************/
PROVIDE(_vector_spacing = 0x00000001);
_ebase_address =  0x9D010000;

/*************************************************************************
 * Memory Address Equates
 * _RESET_ADDR      -- Reset Vector
 * _BEV_EXCPT_ADDR  -- Boot exception Vector
 * _DBG_EXCPT_ADDR  -- In-circuit Debugging Exception Vector
 * _DBG_CODE_ADDR   -- In-circuit Debug Executive address
 * _DBG_CODE_SIZE   -- In-circuit Debug Executive size
 * _GEN_EXCPT_ADDR  -- General Exception Vector
 *************************************************************************/
_RESET_ADDR              = 0x9D011000;    /*  0xBFC00000;*/
_BEV_EXCPT_ADDR          = (0xBFC00000 + 0x380);
_DBG_EXCPT_ADDR          = (0xBFC00000 + 0x480);
_DBG_CODE_ADDR          = 0xBFC02000;
_DBG_CODE_SIZE           = 0xFF0;
_GEN_EXCPT_ADDR          = _ebase_address + 0x180;

/*************************************************************************
 * Memory Regions
 *
 * Memory regions without attributes cannot be used for orphaned sections.
 * Only sections specifically assigned to these regions can be allocated
 * into these regions.
 *************************************************************************/
MEMORY
{
  kseg0_program_mem    (rx)  : ORIGIN = 0x9D012000, LENGTH = 0x60000 /* All C Files will be located here */
  kseg0_boot_mem             : ORIGIN = 0x9D010000, LENGTH = 0x0 /* This memory region is dummy */
  exception_mem              : ORIGIN = 0x9D010000, LENGTH = 0x1000  /* Interrupt vector table */
  kseg1_boot_mem             : ORIGIN = 0x9D011000, LENGTH = 0x1000 /* C Startup code */
  debug_exec_mem             : ORIGIN = 0xBFC02000, LENGTH = 0xFF0
  config3                    : ORIGIN = 0xBFC02FF0, LENGTH = 0x4
  config2                    : ORIGIN = 0xBFC02FF4, LENGTH = 0x4
  config1                    : ORIGIN = 0xBFC02FF8, LENGTH = 0x4
  config0                    : ORIGIN = 0xBFC02FFC, LENGTH = 0x4
  kseg1_data_mem       (w!x) : ORIGIN = 0xA0000000, LENGTH = 0x20000
  sfrs                       : ORIGIN = 0xBF800000, LENGTH = 0x100000
  configsfrs                 : ORIGIN = 0xBFC02FF0, LENGTH = 0x10
}

Soft Wear Efforts

The soft wear side of the house has been quite busy the last month+.  They have made over a 100 masks for the local hospital here in Reno and for Kaiser in Santa Clara (still have connections and friends in the Bay Area).  Here is a picture from earlier of one, when it was still rather cold in Nevada.

 Here are some samples of the ones they are churning out.  All sizes, shapes, and colors.  Right now we are only doing these for the local communities and their efforts to help those in need.  So we are not taking any orders for custom masks, but check back things can change.