Project Logs

Collapse

• Production Finshed, Badges Have Arrived

  Mike Szczys • 11/08/2017 at 00:22 • 2 comments

  Numerous boxes arrived today from Macrofab, the Contract Manufacturer who handled fabrication of the badge. After quickly unwrapping the first board, we popped in a microSD card and are happy to report the production run is a huge success. 

  We have many more images to share so join us below for more.

  Read more »

• Hardware description

  Mike Harrison • 10/11/2017 at 11:11 • 4 comments

  Schematic (PDF)
  

  Power supply

  Supply is from two AA cells, nominal supply voltage is 2 to 5V ( startup). Once running it will continue to operate down to about 1.2v, depending on load ( in particular OLED content). 
  Incoming power feeds a MCP1640B boost regulator U5, which boosts the supply to 3.3v. 
  If the incoming supply exceeds 3.3v, the regulator bypasses, connecting the output to the input, so this must be bourne in mind if  the 3.3v supply is used to feed 3.3v-only devices, as the 3.3v rail will be close to the input voltage for inputs >3,3v  This is not an issue with alkaline AA cells, but may cause unwanted smoke if supplied from other power sources.

  The 3.3v supply is then regulated down to 2.8v by U5 which supplies all onboard devices except the OLED boost supply and white LED.
  The OLED boost regulator U3  provides nominally 12.7v for the OLED. The input to the boost inductor comes direct from the battery, but the boost regulator is supplied from the 2.8v supply. This to allow operation when the battery voltage falls below U3's minimum supply voltage.

  Power on/off control is via the MCP1640's ENABLE input. The power button forces the device on via D2A. When the MCU starts, it then holds the pin high using IO pin RA4 via D2B, and can power down by setting this pin low. The state of the power button can be read via RA7.

  Battery voltage sensing
  Q1 switches on a voltage divider to allow the battery voltage to be measured. As Q1's source may be higher or lower than the PIC's 2.8V supply, C12 is used as a level shifter. The POWERCON signal is set low for a very short period while the ADC samples. This period is short enough that the 3.3v supply is not affected by the momentary turn-off of U5. Battery voltage is measured relative to the PIC's internal voltage rererence, so correct results are obtained if the 2.8V rail starts to drop out.
  

  Camera

  The camera module uses the OV9650 sensor from Omnivision. There are a number of slightly different modules available on Ebay and Aliexpress. The ones pictured below have been tested & found to work with the badge hardware. There may be slight differences in lens field of view between module types.
  

  This sensor is one for which quite a lot of documentation has escaped ( see files section ), though this should still be treated with caution as descriptions of the registers are incomplete, sometimes misleading or just wrong.
  

  The PIC reads data from the camera via the parallel master port (PMP) peripheral, via DMA transfers triggered by counters clocked by  the pixel clock. The basic method used is described in This video

  The method described in the video only  captures single pixels every <n> pixels, where n>1 , as the counters cannot generate a DMA request on every clock. This works for monochrome format as you only need the Y component of the YUYV output sequence.
  This technique has been further developed In order to capture adjacent pairs of pixels necessary for the RGB565 colour format.
  This works by doing 2-byte DMA transfers, and relies on the pixel clock period being the same as the time between the two consecutive DMA transfers. There is a small amount of jitter on the time of the second transfer, but by selecting the PIXCLK phasing, this is kept within the data-valid time of the camera data. For slower capture rates it may be possible to tweak the 2-byte transfer timing using the PMP peripheral's wait-state configuration.
  

  The camera's POWERDOWN line is controlled by one of the OLED's GPIO pins. This is of limited use in practice, as when the camera module powers down, it jams the I2C bus for a second or so as the core voltage discharges ( causing the regular accelerometer reads to hang) , so this should not be used for routine on/off control, but only if a soft powerdown mode is needed. The camera's sleep I2C commands allow the camera...

  Read more »

• Hardware hacking

  Mike Harrison • 10/11/2017 at 11:04 • 3 comments

  Expansion header and hardware test/access points
  

  DXF of board layout for mechanical dims
  
  PIC32MX1xx datasheet
  

  PIC32MX1xx errata

  Expansion header pins
  
  

  Pin	Function	Comments. See Datasheet section 11.3 for pin remapping details. Only functions that don't clash with existing badge functionality are listed below. IC - input capture, OC = Output compare (e.g.  PWM)
  1	0V	Ground. Also on ISP header pin 3 and TTL232 header pin 1 Also available on several pads around prototype area
  2	I2C SDA	2.8v levels. Used onboard by accelerometer and camera Also available at edge of prototyping area
  3	I2C SCL	2.8v levels Used onboard by accelerometer and camera Also available at edge of prototyping area
  4	+2.8V	Logic supply. Also on ISP header pin 2 Also available at edge of prototyping area
  5	RA2/RPA2	PIC pin 30. I/O or mappable peripheral RPA2 Set to output by default RPA2 can be mapped to inputs INT2,T4CK,IC1,IC5,OCFB, and outputs SDO1,SDO2,OC4,OC5,REFCLKO
  6	RB4/RPB4	PIC Pin 33. I/O or mappable peripheral RB4 Set to output by default. RPB4 can be mapped to inputs INT4,T2CLK,IC4,REFCLKI and outputs U1TX,OC1,C2OUT
  7	RB0/RPB0/PGD1/AN2	PIC pin 21. I/O or remappable peripheral Configured as UART2 TXD by default. Also on ISP header pin 4 and TTL232 header pin 5 Shared with ISP, so add at least 2K2 in series if driving pin to avoid interfering withe programming functionality. RPB0 can be mapped to inputs INT1,T5CK,IC2,OCFA and outputs U2TX,OC3,C1OUT Analogue channel 2 ( need to set ANSELB bit 0)
  8	RC5/RPC5	PIC pin 38. I/O or remappable peripheral. 5V Tolerant. Configured as output by default. Reconfigured as UART1 TXD the first time u1txbyte() is called. Note as this pin is shared with PMA3, it is subject to device errata. TL;DR : no problems if used as mappable peripheral or input, but to use as output you need to set the corresponding bit in PMAEN and write the output value to PMADDR instead of LATC  RPC5 can be mapped to inputs INT4,T2CK,IC4,REFCKI and outputs U1TX,OC1,C2OUT
  9	+3.3V	Output of 3.3v boost regulator. Note that if the incoming supply is >3.3v, this pin will rise to the input voltage!
  10	RC3/RPC3	PIC pin 36 Configured as input with pullup by default. UART1 RXD by default. Reconfigured as UART1 RXD the first time u1txbyte() is called. RPC3 can be mapped to inputs INT2,T4CK,IC1,IC5,U1RX,SDI2 and outputs SDO1,SDO2,OC4,OC5,REFCLKO
  11	VBAT	Unswitched battery supply
  12	RB1/RPB1/PGC1/AN3	PIC pin 22 Configured as UART2 RXD by default. Also on ISP header pin 5 and via 2k2 resistor R10 to TTL232 pin 4 Shared with ISP, so add at least 2K2 in series if driving pin to avoid interfering with  programming functionality. RPB1 can be mapped to inputs INT3,T3CK,IC3,U2RX,SDI1 and outputs SDO1,SDO2,OC2,C3OUT. Analogue channel 3 ( need to set ANSELB bit 1)

  
  Power
  Sugested maximum draw from +3.3v or +2.8v is 200mA, maybe 300mA for brief periods.
  If the OLED starts dimming, you're pulling too much!
  Power may be fed into VBAT if batteries are not fitted, however note that if the supplied voltage exceeds 3.3v, the 3.3v rail will output the incoming supply voltage. This is not a problem for the badge up to about 5V, but be aware of possible dissipation issues in the 2.8v regulator if you are also pulling a lot from 2.8v.
  If you have 3.3v -only devices and want to supply from >3.3v ( e.g. lipo), you should use your own 3.3v regulator. You can use the 2.8V rail as an enable to switch your local 3.3v supply if needed.
  

  Firmware support for hardware
  

  All I/O used by the badge is intialised in inithardware() in hardware.c
  

  UARTs :
  

  u1txbyte(c) and u2txbyte(c) Send 1 byte to UART1 and UART2 respectively. Baudrates are initialised with values in cambadge.h
  UART1 is not mapped to pins at startup, but is mapped, and the UART configured, on the first call to u1txbyte()
  A simple receive handler is set up for UART2 - this is in serial.c - see code for more details.

  I2C :
  

  On-board I2C device addresses : Camera 0x60 Accelerometer 0x3A (8  bit addresses).

  ... Read more »

• Firmware hacking and adding new applications

  Mike Harrison • 10/11/2017 at 11:00 • 0 comments

  
  

  Firmware APIs
  

  These are not documented here, but in the globals.h include file. This avoids the need to keep this page synchronised with the current firmware version as features are added or modified.
  

  Tools required
  

  Microchip MPLABX (4.0x) and XC32 1.44 (free version). You do NOT (thankfully) need Microchip Harmony.
  Although the project compiles using the MPLAB XPRESS online IDE, it does not appear to be possible to download the generated .hex file so it's not useful.
  

  If you want to get more serious you will want a PIC programmer such as PicKit 3 or MPLAB ICD3/4, or a 3rd-party programmer that supports the PIC32MX170F256D. When installing MPLABX, if you have a Microchip hardware programmer, also install IPE (MPLABX installer installs it by default), which is used for device programming outside MPLABX - this will be useful for restoring the bootloader.
  
  

  The firmware is compiled with -01 optimisation, which is the highest available in the free version of XC32. Higher optimisation levels in the paid-for compiler (available as a free trial) may improve speed for compute-heavy tasks ( like particle demo), but things like display and camera grab/save are mostly limited by hardware clock rates etc. so won't see much benefit.Teh compiler flag compiler flag -fno-aggressive-loop-optimizations appears to be needed to avoid some problems seen with -01 optimisation. this is all set up in the project.
  

  There are two MPLABX projects - cambadge and camboot.
  See files section for latest version of cambadge project.
  Camboot is the bootloader, which you will only need if you want to modify the bootloader.
  

  The cambadge project is compiled to a .hex file  ( <project path>.cambadge.X\dist\Normal\production\cambadge.X.production.hex) which can then be loaded from the MicroSD card via the bootloader, or programmed directly onto the device via the ISP header using a programmer such as PIckit 3 or MPLAB ICD3/4. (The ICD  programmers are significantly faster than Pickit 3 - it may actually be quicker to use the MicroSD card+bootloader method than a Pickit 3!).
  For fastest programming speed within MPLABX, be sure to select  the MPLABX option "Maintain active connection to hardware tool" in options->embedded.
  

  Note that direct programming will overwrite the bootloader! To restore it, you need to program this .hex file which contains the factory-programmed image containing the bootloader and early application code. This can be programmed using MPLABX IPE.

  Important note when using a hardware programmer
  As the power is soft-switched, when a programmer starts programming the PIC, the power-control line will float, and turn off the power, so programming will fail. To avoid this you need to hold the power button for the duration of programming.
  An alternative is to fit the header at J6 (next to the power button), and put a jumper on it. this holds the power always on, avoiding the need to press the button.
  The jumper does not affect the use of the power button asn an input. With the jumper fitted, if the badge wants to power down (e.g. timeout) it will sit in a screen showing "awaiting powerdown" and a button to allow a reset.
  
  

  The linker file  ( link_forboot.ld ) has been set up to compile to the correct memory locations for use with the bootloader, but also patches a jump into the reset vector, so the same .hex file will run standalone when programmed direct via a device programmer. This avoids the need for seperate standalone and bootloader build variants. 

  Project Files

  apptemplate.c : Demonstration application for use as template for user applications
  browser.c : file browser application
  cambadge.c  : main(), main menu polling loop
  camera.c : Camera application
  codescan.c : Barcode reader application
  display.c : OLED display drivers and display formatting/font stuff
  fileformats.c : Routines for parsing, displaying and creating...

  Read more »

• Bootloader

  Mike Harrison • 10/11/2017 at 10:59 • 0 comments

  Bootloader

  A bootloader is included which allows  firmware programming from .hex files from the SD card.
  

  At startup, the bootloader first verifies a checksum on the application area, and if valid, enters the application code after approx 1 second. Pressing the bottom-left button during this period (or holding it when turning on) allows manual entry to the bootloader menu If  the application checksum is invalid, it displays a warning message and allows the user to enter the bootloader menu or attempt to run the application code anyway (the latter will usually fail). The checksum is created by the bootloader when it has finished programming the flash, ensuring that a failed or incomplete programming operation will not result in a valid sum.
  The bootloader uses the PIC user ID config locations in the hex file to verify that the code is intended for the badge hardware. A warning will be displayed if there is a mismatch. Any addresses in the hex file outside the application area will be ignored.

  While the bootloader is active, the LED will blink periodically. This is mostly to indicate that the bootloader is running, in the case of a faulty display, to distinguish from lack of power etc.
  

  The bootloader will power down after 2 minutes of inactivity.
  

  Flash memory usage

  0x1D00 0000 to 0x1D00 7BFF : Bootloader
  0x1D00 7C00 to 0x1D00 7FFF : Reserved for application nonvolatile settings.
  0x1D00 8000 to 0x1D03 FFFB : Application code
  0x1D03 FFFC to 0x1D03 FFFF : Checksum on application code. 32-bit sum of all bytes in application area, LSByte first
  0x1FC0 0000 to 1FC0 0BEF : Reset vector and boot area (part of bootloader)

  Files
  

  See files section for bootloader MPLABX project and combined bootloader+application code .hex file
  

View all 5 project logs