The Snickerdoodle Book/PlatformController

From krtkl wiki
Jump to navigation Jump to search

Platform Controller


Snickerdoodle's platform controller is a STM32F0 series 32-bit ARM®Cortex-A0® microcontroller connected to and in control of various signals. See "Chapter 9" for a bit of an introduction.

15. Peripherals


Several 12-bit analog to digital converters (ADC) on the platform controller are used to monitor the on-board systems. The power supply levels are monitored using the ADCs.

TODO: insert Table 15.1: ADC Port Connection




The platform controller is connected to 5 LEDs that are used to indicate various states and events of the board. These LEDs are connected to peripherals that are configured as PWM timers for brightness control on the LEDs through the PWM duty cycle.

Table 15.2: LED PWM Timer Channels
PA8 D11 TIM1 CH1 Red (fault)
PC6 E12 TIM3 CH1 Green (USB/Power)
PC7 E11 TIM3 CH2 Blue (Bluetooth)
PC8 E10 TIM3 CH3 White (Application)
PC9 D12 TIM3 CH4 Orange (Wireless Link)



USART1 is connected to the Zynq processing subsystem on UART0 and is normally used to bridge the Zynq console output to the USB device peripheral. Normally the USB device is configured as a communications device class (CDC) interface.

Table 15.3: Platform Controller USART1 Configuration
Mode Asynchronous
Hardware Flow Control (RS-232) Disabled
Baud Rate 115200
Word Length 8 bits
Parity None
Stop Bits 1
Data Direction Receive and Transmit
Over Sampling 16 Samples
Single Sample Disable

USART2 is connected to the Bluetooth HCI interface of the Wilink 8 module.

TODO: insert Table 15.4: Platform Controller USART2

USB Device

The USB device peripheral is normally configured as a communications device class (CDC) interface to provide access to the Zynq console by bridging to USART1 which is connected to UART0 on the Zynq.

During certain boot modes, the USB device is configured for device firmware upgrade (DFU) and can be used to program the platform controller by writing directly to the embedded flash memory.

Basic Parameters

TODO: insert Table 15.5: USB Parameters


Table 15.6: GPIO Pin Configuration
STM32 Port Pin Zynq Pin I/O Description
PA9 D10 Output ANT_SELECT_1
PA10 C12 Output ANT_SELECT_2
PD2 C8 Output WDI
PD7 A5 Output WL_32KHZ_CLK_EN
PF10 G2 Output WL18xx_BT_EN
PD15 H10 Output SMB_NRESET


Table 15.7: GPIO External Interrupt Pin Configuration
STM32 Port Pin Zynq Pin I/O Description
PD10 J12 EXTI10 JA1_P2
PD11 J11 EXTI11 JA2_P2
PD12 J10 EXTI12 JB1_P2
PD13 H12 EXTI13 JB2_P2
PD14 H11 EXTI14 JC1_P2

16. Firmware

The platform controller firmware provides the logic for handling the tasks of the...

Development Environment

The integrated development environment used to target the platform controller is the ARM® Keil microcontroller development kit (MDK). The MDK can be downloaded from mdk. After registering and activating the MDK, custom platform controller firmware can be developed and compiled

17. Device Firmware Upgrade (DFU)

For full customization of the Snickerdoodle system the firmware on the platform controller can be modified and upgraded.

For more details see Firmware section of the krtkl download page.

Booting into DFU

The device firmware upgrade interface can be accessed by pressing and holding down both the SELECT and RESET buttons when powering the board. After holding both buttons for 4 seconds, the device will boot into DFU mode and allow access to program the platform controller with upgrade or even custom firmware. See the DFU wiki page for more info.

Bootloader Pin Activation Pattern
Figure 17.1: Unloaded R55 Pads

The device system memory bootloader (which includes USBDFU firmware) can be entered when powering up the board by pulling the BOOT0 pin high (+1.8V). This pin is normally pulled to ground through a 100k­ resistor (R56) but can be connected to +1.8V by carefully shorting the pads for the normally unloaded R55 resistor shown in Figure 17.1 .

WarningBox: WARNING Extreme care should be taken when attempting to connect the pads on R55. Irreparable damage to the board may occur if an error is made while shorting the pads. DO NOT use this method for normal firmware upgrades unless and should only be used if the firmware DFU mechanism has been disabled.

Generate Loadable Images

HEX File Build Output
Figure 17.2: Create Firmware HEX File Build Output

To produce a loadable DFU image, a .hex file is used and must be produced by the firmware build process. To enable .hex file production in the Keil ¹Vision development environment, navigate to Project » Options for Target under the Output tab and check the box marked Create HEX File as shown in Figure 17.2 .

The generated .hex file can be used to create a firmware upgrade image.



Generate DFU Image
Figure 17.3: DFU File Manager Action Selection

The DFU FileManager (DFUFM) allows users to generate DFU images from firmware build outputs (i. e., S19, HEX or BIN files) and can also be used to extract firmware build outputs from DFU images. For a typical DFU, the DFUFM will be used to produce DFU images by selecting I want to GENERATE a DFU file... after opening the DFUFM. With a .hex file produced from a firmware build, a usable DFU image can be produced. From the DFU File Manager, select S19 or Hex... from the Injection section of the interface and navigate to the .hex file you wish to use for the firmware upgrade and select Generate...

Figure 17.4: Generate DFU Image File

Perform Firmware Upgrade

Figure 17.5: SfuSe Demo Interface

The DfuSe interface will detect any microcontrollers that are connected to the host USB in DFU mode as shown in Figure 17.5.



Figure 17.6: DFU Image File Loaded Into DfuSe Software

Select the "Choose..." button to select the image file you will be using. The most recent recommended one can be found on the on the "Firmware" section of the download page.



Figure 17.7: DFU Upgrade Download Process

Select the "Verify after download" and the "Upgrade" button to transfer the image on to the microcontroller.




Figure 17.8: DFU Upgrade Success

When this completes, the window should indicate the process was successful.





18. USB Interface (Virtual COM Port)

The USB interface is most commonly specified as a communications class device and used to bridge the UART (RS-232) connection between the platform controller and the application processor.

For more details see Chapter 18 here.