日常笔记

LPC MCUs and ELF manipulation

Sun, 15 May 2022 13:10:38 +0000

01. LPCs and vector checksum

After playing with NXP LPC series MCUs for some while, something has bothered me: Verification of program flash against ELF files always fail.

Hmmm.. That’s strange. Tried a few different LPC models, and the failure position is always 0x1C. After digging into the user manual, I found out these MCUs uses the reserved 0x1C vector as a checksum for the first 8 vectors. The bootloader sums up the first 8 words, and if the result is zero, the flash content is considered as valid and bootloader will jump to the application reset vector.

Different IDEs and tools reacts differently to this hardware feature, for example, IAR will compute this checksum by the linker during link stage, and the final image or hex files will contain correct contents. J-Link and OpenOCD process this checksum beforee flashing the image to target MCUs, regardless what the original image has.

However, this checksum machnism causes a problem when verifying the flash content against original ELF files, since the original file still contains invalid value for the checksum field, which will incremential download the first flash sector even if the application has no changes.

02. ELF Patching

Since I already know how the checksum is computed, the next thing is to find a way patching the ELF image, writing the correct checksum into the specified offset in interrupt vector table. Instead of grepping and using some regex magic, I decided using libelf from elfutils to manipulating the section data.

The documentation for libelf is too brief to give me the instructions on how to modify the content of a specific section. After several hours of searching between mailing lists and with the help of an old book, I finally get the library working:

((uint32_t *)ivt_data->d_buf)[7] = checksum;

It is important to use MMAP commands, which will modify the data in-place without touching other section information (Since we only modify one word).

Elf *e_handle = elf_begin(elf_fd, ELF_C_RDWR_MMAP, NULL);

The ELF will be modified in-place, which can be successfully verified by J-Flash.

The code is published at GitHub.

03. References

[1]: libelf example

[2]: IAR

[3]: User Manual (Sign in required)

FreeRTOS on CH32V307

Tue, 03 May 2022 13:56:23 +0000

01 - Preface

During my recent quarantine days, I began working on something I ordered a while ago: WCH CH32V307 RISC-V microcontroller board. The board arrived in April, at first I made a few modifications to the SDK, composed a hello world template project and literally forgot it.

CH32V307 Dev Kit

After being quarantined and transferred to a hotel, I finally got some time playing with it, and the first thing came across my mind is porting some RTOSes to it (since I don’t have other gadgets with me).

02 - RISC-V and WCH

Summary

The CH32V307 is one of a series of Gerenal-Purpose MCUs produced by Nanjing Qinheng Microelectronics (a.k.a. WCH). WCH also produces CH32F20x series, which has nearly exact the same peripherals, but replaces the RISC-V core with a Cortex-M3 core. This may be another option for customers who are already familiar with Cortex-M processors.

The only difference between CH32F2xx and CH32V3xx

Running at 144MHz and implemented RV32IMAFC ISA, with Gigabit Ethernet, High-Speed USB and tons of low speed periperals, making this MCU fairly powerful among the budget market.

ARM or RISC-V?

Instead of building and maintaining two seperate SDKs for different CPU architectures, WCH decided to make things easier, by making an RISC-V core that much alike an ARM core, so here we are, the RISC-V4 series cores.

These cores have the following unique features which make them more ARM-ish:

A vectored interrupt controller designed by WCH, called PFIC
Hardware exception context preservation and restoration (a.k.a. hardware stack push/pop)
A memory-mapped SysTick timer backward compatible with the same peripheral in ARM cores (counters and match registers are extended to 64bits), but not wired to mtime and mtimecmp CSRs.
Some non-standard features by utilizing CSRs’ reserved bits
Private peripherals located at the same PPB region(0xE000_0000)

Interrupts or Exceptions?

The vectored interrupt controller WCH has implemented in their cores replaced both CLINT and PLIC, which means it handles both internal exceptions and external interrupts. Here are some highlighted features I found from the processor’s manual:

Absolute vector table addresses utilizing a reserved MODE 0b11 in mtvec CSR. In this mode, instead of setting PC to BASE + mcause * 4, the absolute address of the exception handler will be looked up from the vector table defined in BASE and loaded to the PC, just like NVIC does.
Vector table free(VTF) interrupts, which speeds up interrupt handling by writing up to 4 handler addresses to PFIC memory mapped registers.
Hardware accelerated ISR context saving and restoring, pushes 16 caller-saved register to a hidden dedicated hardware stack in one cycle (up to 3 level nested interrupts), and pops them out automatically when mret is executed. This requires proprietary toolchain from WCH, which has a special attribute for hardware-accelerated ISR generation.

One of the unique (and non-standard) things this PFIC does is, some processor exceptions are treated the same way as platform interrupts:

RISC-V Spec

It means some selected synchronous exceptions (like ecall exceptions) will be vectored to BASE + mcause * 4 as other asynchronous interrupts does, with pre-defined priorities listed below.

RISC-V4 Vector Table

03 - FreeRTOS on RISC-V

FreeRTOS has basic support for RISC-V since v10.3.0, with default configuration for NXP RV32M1 Vega along with some other processors. This default port also supports custom chips with additional registers needes to be saved on stack during exception handling.

The porting process is fairly simple, the official guide requires the following functions as exception entries, depends on the current mtvec mode:

freertos_risc_v_trap_handler(): For non-vectored mode
freertos_risc_v_exception_handler(): For vectored mode (ecall)
freertos_risc_v_mtimer_interrupt_handler(): For timer interrupts

I personally prefer not touching the startup file(although I have my re-written version available), so here are the approaches I made:

#define __IRQ_NAKED__ attribute__((naked))

__IRQ_NAKED void Ecall_M_Handler(void) {
    /* Use naked function to generate a short call */
    asm("j freertos_risc_v_exception_handler");
}

__IRQ_NAKED void SysTick_Handler(void) {
    /* Careful: Avoid stack unbalance. */
    asm volatile(
        "addi sp, sp, -4\n" /* Push */
        "sw t0, 4(sp)\n" /* Save t0 on stack */
        "li t0, 0xE000F004\n" /* SysTick-&gt;SR */
        "sw zero, 0(t0)\n" /* Write 0 to clear */
        "lw t0, 4(sp)\n" /* Restore t0 from stack */
        "addi sp, sp, 4\n" /* Pop */
        "j freertos_risc_v_mtimer_interrupt_handler"
    );
}

By using naked functions, no additional instructions are generated by the compiler.

FreeRTOS also needs to know where the exception stack top is located, this is typically defined in linker script at the end of RAM region:

/* Place initial SP to the end of SRAM */
__stack_top = ORIGIN(RAM) + LENGTH(RAM);
PROVIDE(_eusrstack = __stack_top);
PROVIDE( __freertos_irq_stack_top =__ stack_top);

Also, as we have additional float-point registers needs to be saved during context switches, we need to add our own chip-specific header:

.macro portasmSAVE_ADDITIONAL_REGISTERS
	/* Push 32 FP registers to stack. */
	addi sp, sp, -(portasmADDITIONAL_CONTEXT_SIZE * portWORD_SIZE)
	fsw f0, 1 * portWORD_SIZE( sp )
	/* ...Add More FP registers here... */
	fsw f31, 32 * portWORD_SIZE( sp )
	.endm

.macro portasmRESTORE_ADDITIONAL_REGISTERS
	/* Pop 32 FP registers from stack. */
	flw f0, 1 * portWORD_SIZE( sp )
	/* ...Add More FP registers here... */
	flw f31, 32 * portWORD_SIZE( sp )
	addi sp, sp, (portasmADDITIONAL_CONTEXT_SIZE * portWORD_SIZE)
	.endm

Only show the first and last FP register here.

04 - Compile and Run

Compile

The FreeRTOS Demo is based on my template project, which using CMake as build system and can be compiled with RISC-V baremetal toolchain. FreeRTOS has supported CMake for a while, so adding kernel to the project is fairly simple:

# Shared libraries linked with application
set(TARGET_LIBS
    "freertos_kernel"
)

#...

# Include sub directories here
set(FREERTOS_PORT "GCC_RISC_V_WCH_RISC_V4A_FPU" CACHE STRING "")
set(FREERTOS_CONFIG_FILE_DIRECTORY "${CMAKE_SOURCE_DIR}/include" CACHE STRING "")
set(FREERTOS_HEAP "4" CACHE STRING "")
add_subdirectory(lib/FreeRTOS-Kernel)

Flash Download

WCH provides their toolchain and OpenOCD along with their MounRiver IDE, but standalone toolchain archives for Linux can be downloaded seperately at MounRiver.com.

The on-board WCH-Link may requires firmware update, however I did’t find a way to do it without the full Eclipse-based IDE and a working Windows OS.

cd MRS_Toolchain_Linux_x64_V1.40/OpenOCD/bin # Extracted toolchain
./openocd -f wch-riscv.cfg # The only config needed</code></pre>

load the ELF file with GDB, the demo should work as intended.

” Demo download and running

05 - Fun Facts

FreeRTOS only supports M mode only at this time, however WCH’s stock startup file jump to main() using mret, causing the processor switch to U mode. Modifications are required if stock startup files are used.
Somehow WCH decides to use a special way running their own FreeRTOS port, by replacing YIELD with an NVIC function, which pends a software interrupt instead of a ecall instruction…
The official Dev kit has some LEDs and buttons, however they are not actually connected to the MCU, the only way is using some…jumpers.
This MCU has full SRAM backed program flash, and some part of it can be used as additional SRAM by setting the corresponding bits in option bytes.
The flash is read as 0xe339e339 after sucessfully erased, I have no idea why they implemented it this way..
The debug interface is SWD only, even for RISC-V MCUs. WCH-Link is definitely filled with some evil black magic…
The custom CSR corecfgr (0xBC0) is described as “Mainly used for configuring processor pipelining and branch prediction features, and should not be operated by the user”, the default value set by startup file is 0x1F.

06 - References:

MIPI-DSI LCD with Zynq

Tue, 19 Oct 2021 12:20:02 +0000

01 - Introduction

MIPI-DSI is the ‘latest’ standard of mobile display, with highest bandwidth and low power consumption, it was quickly adopted by nearly every hardware vendors. Recently I discovered some really cheap DSI display modules, and decided to drive them the hard way by using a Zynq-7000 SoC.

02 - Protocol Specifications

The MIPI Alliance has kept their little secrets for years, exclusive to their organization members. The documentation provided by Xilinx and LCD manufacturers, however, gave me some basic clue of the specification of these mysterious standards.

D-PHY

MIPI D-PHY is the standard way which link layer protocols such as CSI-2 or DSI communicate with peripherals. A typical D-PHY transmitter or receiver has the following parts:

PPI interface
High Speed (HS) mode transmitter or receiver
Low Power (LP) mode transmitter or receiver

The PPI interface is used to communicate with controllers, which provides control and data interface for the phy layer, known as the protocol side. The D-PHY also has one clock lane and one or more data lanes, each lane has a pair of HS and LP transmitters and/or receivers, which provide data and clock signals. Data lane 0 also has the capability of bus turn-around for bi-directional communication.

D-PHY overview

The figure above describes the structure of the functionality of D-PHY, note the difference between HS and LP electric characteristics. HS transceivers use an differential IO standard called SLVS400, standardized by JEDEC many years ago, while LP transceivers use single-ended 1.2V LVCMOS drivers.

During initialization, all lanes are in LP stop mode, to make life easier, they provided a state-code system to describe the different lane states, listed below:

Lane state descriptions

To enter High-Speed Data Transmission (HSDT) mode, the following steps are required:

Enter High-Speed Clock Mode (HSCM)
Follow the HS request sequence to enter HSDT mode.

MIPI-DSI

The MIPI-DSI works on top of the D-PHY, provides the command and video interfaces to the host processor. There are two modes defined by the DSI specification, and panel manufacturers can select either or both modes to support.

Command Mode
Video Mode

DSI host communicate with panel with a packet based format, transmitted either on HS or LP mode, some packet types only support one mode. DSI packet has two formats, either the short packet (SPa) or the long packet (LPa), depending the length of the DS I command and parameters. Short packets can contain fixed two bytes of payload, and long packets can have maximum of 65536 bytes of payload. When multiple lanes are used, data is distributed as bytes to all data lanes. An example of a HSDT transfer are shown below, captured by DSLogic, with the lowest 40MHz clock…

LANE 0: | 11101 10100000 00000000 00010000 11110000 111...
LANE 1: | 11101 10000000 00001000 11110000 10000000 111...

          SYNC |
                1st/2nd |
                         3rd/4th |
                                  

0x05 0x01 0x00 0x10 | 0x08 0x0F 0x0F 0x01 HS-1t...
DI   PD0  PD1  ECC  | DI   PD0  PD1  ECC
DCS short write     | EoTp

In HSDT mode, the data samples on each change of the clock lane(DDR clock), with LSBit shifting out first. The type of the packet is determined by the first byte of the packet, called Data Identification (DI). DI also has a Virtual Channel (VC) field, making lane sharing possible with maximum of 4 devices. However, display modules are only support VC 0. The last byte is a ECC byte calculated from the first 3 bytes. For example, the above packet has DI value 0x05, as a DCS short write command. The second packet is a special packet called End of Transmission Packet (EoTp), indicates the end of current transmission.

DCS

In DSI command mode, the host communicates with the peripheral by using different commands, including Display Command Set (DCS). If you have experience playing with some LCD or OLED display modules, you will find out that no matter which interface are used, some initialization sequence must be written to the module before it can function normally. These sequence contain the necessary drive voltage and clock settings, the type of the panel, the internal memory layout and many other parameters. For 4-line SPI or DBI(8080/6800 MCU interface) interfaces, commands are written by using a special signal called D/CX, which indicates the data currently being transmitted is a command or data. On MIPI-DSI, this is replaced with a command called DCS. Vendor specific command can be wrapped inside DCS packets, so the panel initialization process can be carried out by host.

Video Mode

Apart from traditional command based operations, DSI specification also has a Video Mode. In video mode, the host manage the display timing by sending out a stream of packets containing synchronization information and image data, then the display can retrive HSync/VSync/Blanking signal from these packets just like DPI(RGB panel interface) does. Video mode is capable of high bandwidth and smooth video, while some controllers without internal graphics RAM only supports this mode.

03 - The Hardware

As mentioned above, MIPI D-PHY needs two IO standards working on the same lane, in order to achieve the AC characteristics by FPGA only, we needs some sort of emulation. Luckily, Xilinx provided with an AppNote describing a low-cost way of emulating D-PHY by using FPGA IO and resistors (XAPP894).

D-PHY Equivalent Solution

This design utilizing four IOs, two for LP mode and one diff pair for HS mode. the resistor network is designed to shift LVCMOS18 to 1.2V standard for LP mode and shift HSTL_1_18 to SLVS400 for HS mode.

Implemented PCB

The board I planned to use is a Zynq-7020 board produced by QMTech, with the shunt resistors removed, external VCCO power can be provided by 2.54mm headers (Not every Zynq board has that) . I implemented the transmitter on a PCB, with power supplies for IOBANK and LCD, as well as the most common RaspberryPi compatible FPC socket. The impedance requirement for D-PHY is 100Ω differential and 50Ω single ended.

04 - Block Design

I planned to use the MIPI-DSI subsystem provided by Xilinx for free in Vivado 2020.2, So the standard video pipeline looks like the following.

Vivado Block Design

The key components of the design are:

AXI Video Framebuffer Read
MIPI-DSI Tx Subsystem

As this LCD controller (NovaTek NT35516) does not support command in HSDT mode, since Xilinx IP does not support Low Power Data Transmission (LPDT) either, I had to add an AXI GPIO and some glue logic to take over the bus for my bit-bang LPDT implementation.

05 - Software

The software part is quite routine, initialize a framebuffer in DDR, configure AXI framebuffer read IP to read from it and send the pixels through AXI Stream to MIPI DSI subsystem. Also, I implemented a bit-bang LPDT driver for the initialization process.

After everything wired up and initialization code ran, I could see some garbage data on the screen, which proven the setup works. I also wrote some bitmap by using xsct command line tool to the framebuffer, the results are as follows.

mwr -bin -file ${BITMAP_FILE}.bin 0x${FRAMEBUFFER_ADDR} ${WORDCOUNT}

This LCD I used is a AUO panel with NT35516 controller, with resolution of 960x540@8bpp. The timing for video mode requires more elaborated calculation, as described by the MIPI DSI Tx subsystem documentation (PG238).

Example Timing Calculation

The timing information I used:

Lane rate: 500Mb/s x2
HActive: 540 * 3(24bits), VActive: 960, frame rate 60Hz

After calculation described by the documentation, the final timing looks like:

XDsi_VideoTiming timing = {
    .HActive     = 540 * 3,
    .HFrontPorch = 83,
    .HBackPorch  = 360,
    .HSyncWidth  = 7,
    .VActive     = 960,
    .VFrontPorch = 15,
    .VBackPorch  = 15,
    .VSyncWidth  = 10,
    .BLLPBurst   = 0,
};

06 - Misc

Signal integrity is heavily influenced by my probe.
I might update a future version to address mis-calculated trace widths.
LP mode requires 50-75ns period, however 200ns bit-bang IO seems work just fine.
Not all commands listed in NovaTek’s command set is capable of HSDT.
RaspberryPi DSI display uses DPI panel with DSI-DPI bridge, no initialization required.

Adapter board

07 - References

Software code repository: Embedded_Projects/QM_Zynq_DSI_SW

STM32H7-QUADSPI XIP及优化

Sun, 20 Dec 2020 12:03:05 +0000

0. 简介

新款STM32的QUADSPI外设具有多种功能，配置也相当灵活，同时支持XIP功能。本文以STM32H750为例介绍STM32中的QUADSPI外设以及通过内置Flash执行位于QSPI Flash中的程序，并实现一个简易的USB DFU bootloader。

1. QSPI及QSPI Flash

QSPI（Quad SPI）是在原有SPI的总线结构上增加了两条数据线（IO2，IO3），在数据传输时四条数据线按需切换数据方向，理论可实现4倍于SPI的传输速率，通常用于存储器件的连接。

Quad SPI连接示例

QSPI Flash是NOR Flash的一种，通信接口兼容SPI，Dual SPI及Quad SPI。在3.3V下可以实现133MHz的最大时钟频率。

QSPI Flash系统框图

QSPI存储器件访问会经过以下五个阶段：

指令阶段（Instruction Phase）
地址阶段（Address Phase）
Alternate-byte Phase
等待周期阶段（Dummy cycle Phase）
数据阶段（Data Phase）

1.1. 指令阶段

该阶段主机发送8位的操作指令到Flash，用于指定将要进行的操作。根据Flash模式的不同，指令可以通过单线（IO0）发送（SPI/QSPI模式）或四线发送（QPI模式）。

1.2. 地址阶段

该阶段主机发送24或32位的地址，根据命令和模式的不同，地址可能不需要发送，或通过单线、双线、四线模式发送。

1.3. Alternate-byte 阶段

QSPI Flash可通过Alternate byte设置额外参数，如连续读命令。该Alternate byte根据命令也可通过1/2/4线发送。在Quad模式下，Alternate-byte 也计入 dummy cycle。

1.4. 等待周期阶段

该阶段用于等待Flash内部同步状态，根据Flash读写时钟的不同设置。通常来讲，在高频率下需要更多dummy cycles，同时也取决于Flash配置（命令C0H）。

1.5. 数据阶段

在数据阶段中，数据从主机传输到Flash或者从Flash传输到主机，在该模式下所有IO的状态被确定，输入侧为High-Z，输出侧写入数据。IO方向的切换发生在dummy phase结束的下降沿。

一个完整的操作时序如下图所示：

QSPI操作时序

2. TM32 QUADSPI外设

STM32H7中的QUADSPI外设位于D1域中，其位置如下

STM32H7 QUADSPI外设

QUADSPI外设有三种工作模式，分别为

间接（Indirect）模式
状态轮询（Status-flag polling）模式
XIP（Memory-Mapped）模式

2.1. 间接模式

间接模式下QUADSPI外设操作类似于SPI外设，通过设置传输模式和寄存器收发数据，通过这种方式写入或擦除Flash后需要轮询状态寄存器判断操作完成。

2.2. 状态轮询模式

该模式下，QUADSPI外设通过设置轮询命令和超时，在操作结束后由硬件自动轮询状态寄存器，通过中断指示CPU传输完成。

XIP模式

在XIP模式下，Flash的内容会被Map进地址空间，可以通过直接访问地址的方式读取Flash内容，XIP模式下Flash不可被写入。

2.3. HAL配置QSPI XIP模式

CubeMX不直接支持配置为XIP模式，需要在用户代码中配置。本文中使用的Flash型号为华邦的W25Q128FVSIG，其配置示例如下：

QSPI_CommandTypeDef sCommand;
QSPI_MemoryMappedTypeDef sMemMappedCfg;

sCommand.InstructionMode        = QSPI_INSTRUCTION_1_LINE;
sCommand.AddressMode            = QSPI_ADDRESS_4_LINES;
sCommand.AddressSize            = QSPI_ADDRESS_24_BITS;
sCommand.DataMode               = QSPI_DATA_4_LINES;
sCommand.AlternateByteMode      = QSPI_ALTERNATE_BYTES_4_LINES;
sCommand.AlternateBytesSize     = QSPI_ALTERNATE_BYTES_8_BITS;
sCommand.AlternateBytes         = 0xFF;
sCommand.DdrMode                = QSPI_DDR_MODE_DISABLE;
sCommand.DdrHoldHalfCycle       = QSPI_DDR_HHC_ANALOG_DELAY;
sCommand.SIOOMode               = QSPI_SIOO_INST_EVERY_CMD;
sCommand.Instruction            = 0xEB;
sCommand.DummyCycles            = 4;
sMemMappedCfg.TimeOutActivation = QSPI_TIMEOUT_COUNTER_DISABLE;
sMemMappedCfg.TimeOutPeriod     = 0;

该参数配置QUADSPI外设为四线快速读模式，会产生如下图所示的操作时序：

四线快速读（0xEB）命令

关键参数解释：

InstructionMode ：命令的发送方式，这里选择单线模式发送
AddressMode ：地址的发送方式，该命令需要通过四线发送24bit地址
AddressSize ：地址长度，24bit
AlternateByteMode ：Alternate-byte的发送方式，四线方式发送
Instruction ：指令字，1个字节。这里为四线快速读（0xEB）指令
其余参数暂时保持默认即可

设置参数后，执行

HAL_QSPI_MemoryMapped(&hqspi, &sCommand, &sMemMappedCfg);

操作返回成功后，即可在总线 0x90000000 访问到QSPI Flash中的内容。

Open On-Chip Debugger
> mdw 0x90000000 128                                                                       
0x90000000: 20020000 90004ccd 900006f1 900006f9 900006fb 900006fd 900006ff 00000000 
0x90000020: 00000000 00000000 00000000 90004a01 90000701 00000000 90004aa1 90004b05 
0x90000040: 90004d1d 90000703 90004d1d 90004d1d 9000070b 90000713 90004d1d 90004d1d 
0x90000060: 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 
0x90000080: 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 
0x900000a0: 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 
0x900000c0: 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 
0x900000e0: 90004d1d 90004d1d 00000000 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 
0x90000100: 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 90000715 
0x90000120: 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 
0x90000140: 00000000 00000000 00000000 00000000 90004d1d 90004d1d 90004d1d 90004d1d 
0x90000160: 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 
0x90000180: 90004d1d 90000725 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 
0x900001a0: 90004d1d 90004d1d 90004d1d 90004d1d 90000729 90004d1d 90004d1d 90004d1d 
0x900001c0: 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 
0x900001e0: 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 90004d1d 

> 

USB DFU Bootloader（WIP）

修改HAL工程以XIP方式执行（WIP）

性能优化（WIP）

需注意的问题（WIP）

参考文献

[1] AXI Quad SPI v3.2 LogiCORE IP Product Guide (PG153)

[2] W25Q128FV Datasheet

STM32H7中的DMA

Thu, 07 May 2020 13:19:08 +0000

1. 概述

STM32H7相比其他系列性能有着不小的提升，同时结构也有了较大的变化。这些变化如果不加注意则会影响DMA等功能的使用。本文通过对STM32H7的Bus Matrix及Cache/MPU两方面尝试分析不同点及对应的解决方案。

2.硬件平台

本文中使用的硬件是STM32H750开发板，属于STM32H7 Value Line产品线，代码位于QSPI Flash中，通过XIP方式执行。

3. STM32H7的总线结构和访问规则

STM32H7拥有三个不同的Bus Matrix，分别为D1，D2与D3。

D1区域为AXI Interconnect Matrix，与CPU通过AXI总线相连，高速外设如Flash，QSPI，FMC等通过此AXI Bus连接到CPU，速度最快。
D2区域为AHB Multi-layer Bus Matrix，连接了大部分低速外设及另一部分SRAM，通过CPU的AHBP接口连接到CPU，速度其次。
D3区域为另一个AHB Bus Matrix，与前两个区域不同的是，它不与CPU直接连接，而是通过D2区域的一个AHB Master连接到D3区域。D3区域速度最慢，同时也连接了一部分低功耗外设，速度最慢。

三个区域的时钟及门控可独立控制，以实现低功耗与高性能间的平衡。

在H7的架构中，部分高速外设通过AXI总线连接到Master，相比只有Flash存储器连接到AXI接口的F7系列，外设访问速度也有了提升。

STM32H7的总线互联架构

从上图我们可以发现以下访问规律：

D1区域的Bus Master可以通过D1-to-D2 AHB Bus访问D2域的地址范围，也可以通过D2-to-D3 AHB Bus访问D3的地址范围。
D2区域的Bus Master可以通过D2-to-D3 AHB Bus访问D3域的地址范围，也可以通过D2-to-D1 AHB Bus反向访问D1域的地址范围。
D3区域没有连接到其他区域的Bus Master，因此只能访问D3区域的地址范围。

总结一下就是：

D1与D2中的Bus Master可以互访对方Slave， D3中的Master不能访问D1与D2 Slave 。

4. STM32H7中的DMA与存储器

STM32H7中有三种不同的DMA，分别为MDMA，DMA（DMA1/DMA2）以及BDMA，其特点如下所示：

MDMA可以通过AXI Interconnect的接口访问D1域，同时 能通过专用的AHBS接口访问CPU中的I/DTCM存储器 ，速度最高。
DMA1/2位于D2域中，通过AHB接口访问D2域。由于D2域存在着连接到D1域的通路，因此DMA1/2依然可以访问D1域中的存储器及外设。
BDMA则位于D3域中，仅可以访问D3SRAM及对应的D3域外设，同时功能上也相对有限。

相似的，STM32H7中的存储器也分为了以下几种：

AXI SRAM（D1_RAM)，QUADSPI，FMC，Flash：这些存储器连接到AXI Interconnect，可被能访问D1域的Bus Master访问。
AHB SRAM1/2 ：这些存储器连接到D2域 AHB Bus Matrix，可被能访问D2域的Bus Master访问。
AHB SRAM3：这些存储器连接到D3域 AHB Bus Matrix，可被能访问D3域的Bus Master访问。
特殊的，位于CPU内部的I/DTCM（指令/数据紧耦合存储器）在可被CPU访问的同时也可通过专用接口被 MDMA 访问。

由此，我们可以得出以下几点规则：

MDMA能访问 包含TCM在内 的所有存储器（几乎和CPU范围类似），DMA1/2不能访问TCM，BDMA仅可访问AHB SRAM3以及D3域外设。

特别需要注意的是，这些规则不仅应用于DMA控制器， 同时也适用于其他Bus Master ，如DMA2D，LTDC，Ethernet，SDMMC，USB等等拥有内部DMA的外设，使用时同样要保证用户buffer位于可访问区域内。

关于L1 Cache及MPU

Cortex-M7相比于其他核心，增加了单独的L1 I/D Cache，为了保证DMA访问的内存不出现一致性问题，需要通过配置MPU的方式控制指定区域的缓存策略。

Cortex-M7的MPU通过Region的形式定义访问规则，这里通过STM32CubeMX的配置工具提供简单的缓存配置示例。

CubeMX的MPU配置界面

MPU的配置最好按照粒度从粗到细的顺序配置，示例中的默认配置是禁用缓存，允许全部访问，在QSPI Flash区域启用读缓存，并允许指令访问及共享。

6. 代码实现

在默认的Linker Script中，数据代码被放置在了DTCM中，如果想要通过DMA访问这部分数据，我们就只能通过MDMA访问，或者修改LDS使得数据放置在AXI SRAM或者AHB SRAM中。以下的修改可以将用户的buffer放置在D2域SRAM中：

_SI_D2SRAM = LOADADDR(.d2_sram);
.d2_sram :
{
  . = ALIGN(4);
  _DMA_Buffer_Start = .;
  *(.d2_sram_buffer)
  . = ALIGN(4);
  _DMA_Buffer_End = .;
} >RAM_D2 AT> FLASH /* Note: Not actually init, we need to copy manually before use */

然后我们即可初始化这部分数据：

uint32_t bytes_to_copy = &_DMA_Buffer_End - &_DMA_Buffer_Start;
if(bytes_to_copy != 0) {
    memcpy((void *)&_DMA_Buffer_Start, (void *)&_SI_D2SRAM, bytes_to_copy);
}

之后通过DMA1或DMA2即可正确实现DMA传输。

使用SystemView分析FreeRTOS应用

Tue, 05 May 2020 09:48:59 +0000

1.前言

在使用FreeRTOS进行应用开发时经常会遇到普通的方式难以调试的问题，如栈内存不足等等，同时也希望对运行的多个Task进行实时的性能及资源占用的分析，通常的调试手段在这里就变的心有余而力不足了。以FreeRTOS为例，如何在长时间的运行过程中收集调试数据进行分析，以及如何调试不同的组件（如Queue，Notification，Semaphore等等）？这个时候就需要Trace工具帮忙了。针对RTOS的Trace需求，有多种商业工具可供选择，但其中可供免费使用的产品则寥寥无几。本文将针对SEGGER开发的SystemView Trace工具进行介绍。

2. SystemView

SystemView是SEGGER开发的针对嵌入式系统的trace工具，支持多种RTOS，也支持自定义OS的移植（需实现trace API，参见User Manual）。其核心基于SEGGER RTT，一个Host-Target间的通信框架，可通过多种方式连接，除J-LINK之外还可以使用串口及TCP-IP协议，对非商业用途免费且无功能限制。

3. 环境准备

我们使用的测试环境是STM32H750VB开发板，CPU为Cortex-M7，最高主频480MHz，程序位于QSPI Flash中，通过XIP方式运行。FreeRTOS为STM32CubeMX配置的未修改版本。运行一个自定义Task，Toggle开发板上的一个LED灯。

//测试Task
TaskHandle_t xTaskHelloHandle = NULL;
void vTaskHello(void *pvParameters) {
    for(;;) {
        HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_1);
        SEGGER_SYSVIEW_PrintfTarget("Hello world @%lu\n", HAL_GetTick());
        //这里使用了SystemView系统库提供的输出函数，向主机输出Message
        vTaskDelay(1000);
    }
    vTaskDelete(NULL);
}

在启动时自动创建该Task：

xTaskCreate(vTaskHello, "hello_task", 1024, NULL, 7, NULL);

栈深度为1024字，优先级为7

4. SystemView trace库移植

首先下载目标板源码，将其中的 SEGGER 目录下代码以及 Sample 中的FreeRTOS代码添加到项目。

SystemView
├── Config
│   ├── Global.h
│   ├── SEGGER_RTT_Conf.h
│   ├── SEGGER_SYSVIEW_Conf.h
│   └── SEGGER_SYSVIEW_Config_FreeRTOS.c
└── SEGGER
    ├── SEGGER.h
    ├── SEGGER_RTT.c
    ├── SEGGER_RTT.h
    ├── SEGGER_RTT_ASM_ARMv7M.s
    ├── SEGGER_RTT_printf.c
    ├── SEGGER_SYSVIEW.c
    ├── SEGGER_SYSVIEW.h
    ├── SEGGER_SYSVIEW_ConfDefaults.h
    ├── SEGGER_SYSVIEW_FreeRTOS.c
    ├── SEGGER_SYSVIEW_FreeRTOS.h
    ├── SEGGER_SYSVIEW_Int.h
    └── Syscalls
        └── SEGGER_RTT_Syscalls_GCC.c
    
    3 directories, 16 files

接下来我们需要实现通过串口的RTT数据收发，这里使用一个额外的Task实现这个操作。

#define SYSVIEW_COMM_APP_HELLO_SIZE 32
#define SYSVIEW_COMM_TARGET_HELLO_SIZE 32

#define SYSVIEW_SINGLE_TX 256

U8 hello_message[SYSVIEW_COMM_TARGET_HELLO_SIZE] = {
    'S', 'E', 'G', 'G', 'E', 'R', ' ',
    'S', 'y', 's', 't', 'e', 'm', 'V', 'i', 'e', 'w',
    ' ', 'V', '0' + SEGGER_SYSVIEW_MAJOR,
    '.', '0' + (SEGGER_SYSVIEW_MINOR / 10),
    '0' + (SEGGER_SYSVIEW_MINOR % 10),
    '.', '0' + (SEGGER_SYSVIEW_REV / 10),
    '0' + (SEGGER_SYSVIEW_REV % 10),
    '\0', 0, 0, 0, 0, 0 
};

TaskHandle_t xTaskTraceCommHandle = NULL;
void vTaskTraceComm(void *pvParameters) {
    //获取Channel ID
    int channel_id = SEGGER_SYSVIEW_GetChannelID();

    //发送HELLO包
    HAL_UART_Transmit(&huart1, hello_message, SYSVIEW_COMM_TARGET_HELLO_SIZE, 1000);

    uint8_t rx_buf;
    uint8_t tx_buf[SYSVIEW_SINGLE_TX];

    //启动记录
    SEGGER_SYSVIEW_Start();

    //等待通过串口中断接收数据
    HAL_UART_Receive_IT(&huart1, &rx_buf, 0x01);

    for(;;) {
        if(xTaskNotifyWait(0x00, 0x01, NULL, pdMS_TO_TICKS(400)) == pdTRUE) {
            //接收到数据，写入到RTT缓存
            SEGGER_RTT_WriteDownBufferNoLock(channel_id, &rx_buf, 0x01);
            HAL_UART_Receive_IT(&huart1, &rx_buf, 0x01);
        }
        //获取上行缓存数据长度
        unsigned int tx_length = SEGGER_RTT_GetBytesInBuffer(channel_id);
        if(tx_length >= SYSVIEW_SINGLE_TX) { 
            //STM32 HAL代码有最大长度限制，这里默认设置为256字节，可调整
            //从RTT缓存中读出数据
            uint32_t num = SEGGER_RTT_ReadUpBufferNoLock(channel_id, tx_buf, SYSVIEW_SINGLE_TX);
            //通过串口发送，此处可使用中断方式发送，尚未实现。
            HAL_UART_Transmit(&huart1, tx_buf, num, 100);
        } else if (tx_length != 0){
            // 同上
            uint32_t num = SEGGER_RTT_ReadUpBufferNoLock(channel_id, tx_buf, tx_length);
            HAL_UART_Transmit(&huart1, tx_buf, num, 100);
        }
    }
    vTaskDelete(NULL);
}

//串口ISR
void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) {
    if(huart->Instance == USART1) {
        //向Task发送通知，收到数据
        BaseType_t higher_woken = pdFALSE;
        xTaskNotifyFromISR(xTaskTraceCommHandle, 0x01, eSetBits, &higher_woken);
        portYIELD_FROM_ISR(higher_woken);
    }
}

创建Task：

xTaskCreate(vTaskTraceComm, "trace_task", 1024, NULL, 6, &xTaskTraceCommHandle);

在RTOS调度器启动之前执行 SEGGER_SYSVIEW_Conf() 。

默认情况下SystemView会从DWT的Cycle counter获取系统当前周期数用于生成时间戳：

/*********************************************************************
*
* SystemView timestamp configuration
*/
#if !defined(SEGGER_SYSVIEW_GET_TIMESTAMP) && !defined(SEGGER_SYSVIEW_TIMESTAMP_BITS)
  #if SEGGER_SYSVIEW_CORE == SEGGER_SYSVIEW_CORE_CM3
    #define SEGGER_SYSVIEW_GET_TIMESTAMP() (*(U32 *)(0xE0001004)) // Retrieve a system timestamp. Cortex-M cycle counter.
    #define SEGGER_SYSVIEW_TIMESTAMP_BITS 32 // Define number of valid bits low-order delivered by clock source
  #else
    #define SEGGER_SYSVIEW_GET_TIMESTAMP() SEGGER_SYSVIEW_X_GetTimestamp() // Retrieve a system timestamp via user-defined function
    #define SEGGER_SYSVIEW_TIMESTAMP_BITS 32 // Define number of valid bits low-order delivered by SEGGER_SYSVIEW_X_GetTimestamp()
  #endif
#endif

在STM32CubeMX的初始化代码中该计数器默认未启用，在这里手工启用。

CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk;
DWT->CYCCNT = 0;
DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk;

修改 FreeRTOSConfig.h 引入SystemView的trace宏：

/* USER CODE BEGIN Defines */   	      
/* Section where parameter definitions can be added (for instance, to override default ones in FreeRTOS.h) */
    
#define INCLUDE_xTaskGetIdleTaskHandle 1
    
#include "SEGGER_SYSVIEW_FreeRTOS.h"
    
/* USER CODE END Defines */ 

至此，我们的移植过程基本结束。

注：在SEGGER代码中， _write 部分的实现存在签名不兼容的问题，此函数是用于将stdout通过RTT输出到SystemView，可直接删除 SEGGER/Syscalls/SEGGER_RTT_Syscalls_GCC.c ，也可修改函数签名使其与系统库一致。

注2：在初始化时使用了 strcpy() 函数，在测试环境中出现Hardfault问题，可在 SEGGER/SEGGER_RTT.c 中将

#ifndef STRCPY
  #define STRCPY(pDest, pSrc, NumBytes) strcpy((pDest), (pSrc))
#endif

替换为

#ifndef STRCPY
  #define STRCPY(pDest, pSrc, NumBytes) strncpy((pDest), (pSrc), (NumBytes))
#endif

初步推测为Null-Terminated的问题，有头绪欢迎联系指正。

2020-05-07更新：使用DMA传输以减少CPU开销

更新部分代码如下

for(;;) {
    if(xTaskNotifyWait(0x00, 0x03, &amp;notify_flag, pdMS_TO_TICKS(400)) == pdTRUE) {
        if(notify_flag &amp; 0x01) {
            SEGGER_RTT_WriteDownBufferNoLock(channel_id, &amp;rx_buf, 0x01);
            HAL_UART_Receive_IT(&amp;huart1, &amp;rx_buf, 0x01);
        }
        if(notify_flag &amp; 0x02) {
            if(dma_in_progress) {
                dma_in_progress = 0;
                prev_send = xTaskGetTickCount();
            }
        }
    }
    if(dma_in_progress == 0 &amp;&amp; xTaskGetTickCount() - prev_send &gt;= pdMS_TO_TICKS(400)) {
        unsigned int tx_length = SEGGER_RTT_GetBytesInBuffer(channel_id);
        if(tx_length &gt;= SYSVIEW_SINGLE_TX) {
            uint32_t num = SEGGER_RTT_ReadUpBufferNoLock(channel_id, tx_buf, SYSVIEW_SINGLE_TX);
            HAL_UART_Transmit_DMA(&amp;huart1, tx_buf, num);
        } else if (tx_length != 0){
            uint32_t num = SEGGER_RTT_ReadUpBufferNoLock(channel_id, tx_buf, tx_length);
            HAL_UART_Transmit_DMA(&amp;huart1, tx_buf, num);
        }
        dma_in_progress = 1;
    }
}

同时添加DMA传输完成中断

void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart) {
    if(huart->Instance == USART1) {
        BaseType_t higher_woken = pdFALSE;
        xTaskNotifyFromISR(xTaskTraceCommHandle, 0x02, eSetBits, &higher_woken);
        portYIELD_FROM_ISR(higher_woken);
    }
}

即可实现DMA传输

5. 软件使用

启动SystemView，在Target->Recorder Configuration中指定串口及波特率，连接后RESET目标板即可接收事件。如下图。

SystemView主界面

6. Patch

默认的FreeRTOS trace宏不足以收集足够的参数，因此需要Patch FreeRTOS。提供参考Patch如下，来自SEGGER的Sample目录

diff -ur Middlewares/Third_Party/FreeRTOS/Source/include/FreeRTOS.h ../FreeRTOS/Source/include/FreeRTOS.h
--- Middlewares/Third_Party/FreeRTOS/Source/include/FreeRTOS.h	2020-05-07 22:43:33.533067758 +0800
+++ ../FreeRTOS/Source/include/FreeRTOS.h	2020-05-07 22:41:30.520012215 +0800
@@ -156,6 +156,10 @@
 	#define INCLUDE_uxTaskGetStackHighWaterMark 0
 #endif
 
+#ifndef INCLUDE_pxTaskGetStackStart
+	#define INCLUDE_pxTaskGetStackStart 0
+#endif
+
 #ifndef INCLUDE_uxTaskGetStackHighWaterMark2
 	#define INCLUDE_uxTaskGetStackHighWaterMark2 0
 #endif
@@ -400,6 +404,25 @@
 	#define tracePOST_MOVED_TASK_TO_READY_STATE( pxTCB )
 #endif
 
+#ifndef traceREADDED_TASK_TO_READY_STATE
+ #define traceREADDED_TASK_TO_READY_STATE( pxTCB ) traceMOVED_TASK_TO_READY_STATE( pxTCB )
+#endif
+
+#ifndef traceMOVED_TASK_TO_DELAYED_LIST
+ #define traceMOVED_TASK_TO_DELAYED_LIST()
+#endif
+
+#ifndef traceMOVED_TASK_TO_OVERFLOW_DELAYED_LIST
+ #define traceMOVED_TASK_TO_OVERFLOW_DELAYED_LIST()
+#endif
+
+#ifndef traceMOVED_TASK_TO_SUSPENDED_LIST
+ #define traceMOVED_TASK_TO_SUSPENDED_LIST( pxTCB )
+#endif
+
+
+
+
 #ifndef traceQUEUE_CREATE
 	#define traceQUEUE_CREATE( pxNewQueue )
 #endif
@@ -644,6 +667,18 @@
 	#define traceTASK_NOTIFY_GIVE_FROM_ISR()
 #endif
 
+#ifndef traceISR_EXIT_TO_SCHEDULER
+	#define traceISR_EXIT_TO_SCHEDULER()
+#endif
+
+#ifndef traceISR_EXIT
+	#define traceISR_EXIT()
+#endif
+
+#ifndef traceISR_ENTER
+	#define traceISR_ENTER()
+#endif
+
 #ifndef traceSTREAM_BUFFER_CREATE_FAILED
 	#define traceSTREAM_BUFFER_CREATE_FAILED( xIsMessageBuffer )
 #endif
diff -ur Middlewares/Third_Party/FreeRTOS/Source/include/task.h ../FreeRTOS/Source/include/task.h
--- Middlewares/Third_Party/FreeRTOS/Source/include/task.h	2020-05-07 22:43:33.529734437 +0800
+++ ../FreeRTOS/Source/include/task.h	2020-05-07 22:41:30.516678886 +0800
@@ -1438,6 +1438,25 @@
 
 /**
  * task.h
+ * <PRE>uint8_t* pxTaskGetStackStart( TaskHandle_t xTask);</PRE>
+ *
+ * INCLUDE_pxTaskGetStackStart must be set to 1 in FreeRTOSConfig.h for
+ * this function to be available.
+ *
+ * Returns the start of the stack associated with xTask. That is,
+ * the highest stack memory address on architectures where the stack grows down
+ * from high memory, and the lowest memory address on architectures where the
+ * stack grows up from low memory.
+ *
+ * @param xTask Handle of the task associated with the stack returned.
+ * Set xTask to NULL to return the stack of the calling task.
+ *
+ * @return A pointer to the start of the stack.
+ */
+uint8_t* pxTaskGetStackStart( TaskHandle_t xTask) PRIVILEGED_FUNCTION;
+
+/**
+ * task.h
  * <PRE>configSTACK_DEPTH_TYPE uxTaskGetStackHighWaterMark2( TaskHandle_t xTask );</PRE>
  *
  * INCLUDE_uxTaskGetStackHighWaterMark2 must be set to 1 in FreeRTOSConfig.h for
diff -ur Middlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM4F/port.c ../FreeRTOS/Source/portable/GCC/ARM_CM4F/port.c
--- Middlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM4F/port.c	2020-05-07 22:43:33.533067758 +0800
+++ ../FreeRTOS/Source/portable/GCC/ARM_CM4F/port.c	2020-05-07 22:41:30.536678867 +0800
@@ -492,14 +492,20 @@
 	save and then restore the interrupt mask value as its value is already
 	known. */
 	portDISABLE_INTERRUPTS();
+	traceISR_ENTER();
 	{
 		/* Increment the RTOS tick. */
 		if( xTaskIncrementTick() != pdFALSE )
 		{
+ traceISR_EXIT_TO_SCHEDULER();
 			/* A context switch is required. Context switching is performed in
 			the PendSV interrupt. Pend the PendSV interrupt. */
 			portNVIC_INT_CTRL_REG = portNVIC_PENDSVSET_BIT;
 		}
+ else
+ {
+ traceISR_EXIT();
+ }
 	}
 	portENABLE_INTERRUPTS();
 }
diff -ur Middlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM4F/portmacro.h ../FreeRTOS/Source/portable/GCC/ARM_CM4F/portmacro.h
--- Middlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM4F/portmacro.h	2020-05-07 22:43:33.533067758 +0800
+++ ../FreeRTOS/Source/portable/GCC/ARM_CM4F/portmacro.h	2020-05-07 22:41:30.536678867 +0800
@@ -89,7 +89,7 @@
 
 #define portNVIC_INT_CTRL_REG ( * ( ( volatile uint32_t * ) 0xe000ed04 ) )
 #define portNVIC_PENDSVSET_BIT ( 1UL << 28UL )
-#define portEND_SWITCHING_ISR( xSwitchRequired ) if( xSwitchRequired != pdFALSE ) portYIELD()
+#define portEND_SWITCHING_ISR( xSwitchRequired ) { if( xSwitchRequired ) { traceISR_EXIT_TO_SCHEDULER(); portNVIC_INT_CTRL_REG = portNVIC_PENDSVSET_BIT; } else { traceISR_EXIT(); } }
 #define portYIELD_FROM_ISR( x ) portEND_SWITCHING_ISR( x )
 /*-----------------------------------------------------------*/
 
diff -ur Middlewares/Third_Party/FreeRTOS/Source/tasks.c ../FreeRTOS/Source/tasks.c
--- Middlewares/Third_Party/FreeRTOS/Source/tasks.c	2020-05-07 22:43:33.549734367 +0800
+++ ../FreeRTOS/Source/tasks.c	2020-05-07 22:41:30.546678856 +0800
@@ -220,6 +220,17 @@
 	taskRECORD_READY_PRIORITY( ( pxTCB )->uxPriority ); \
 	vListInsertEnd( &( pxReadyTasksLists[( pxTCB )->uxPriority] ), &( ( pxTCB )->xStateListItem ) ); \
 	tracePOST_MOVED_TASK_TO_READY_STATE( pxTCB )
+
+/*
+ * Place the task represented by pxTCB which has been in a ready list before
+ * into the appropriate ready list for the task.
+ * It is inserted at the end of the list.
+ */
+#define prvReaddTaskToReadyList( pxTCB ) \
+ traceREADDED_TASK_TO_READY_STATE( pxTCB ); \
+ taskRECORD_READY_PRIORITY( ( pxTCB )->uxPriority ); \
+ vListInsertEnd( &( pxReadyTasksLists[( pxTCB )->uxPriority] ), &( ( pxTCB )->xStateListItem ) ); \
+ tracePOST_MOVED_TASK_TO_READY_STATE( pxTCB )
 /*-----------------------------------------------------------*/
 
 /*
@@ -1126,7 +1137,7 @@
 		#endif /* configUSE_TRACE_FACILITY */
 		traceTASK_CREATE( pxNewTCB );
 
- prvAddTaskToReadyList( pxNewTCB );
+ prvReaddTaskToReadyList( pxNewTCB );
 
 		portSETUP_TCB( pxNewTCB );
 	}
@@ -1726,6 +1737,8 @@
 				mtCOVERAGE_TEST_MARKER();
 			}
 
+ traceMOVED_TASK_TO_SUSPENDED_LIST(pxTCB);
+
 			vListInsertEnd( &xSuspendedTaskList, &( pxTCB->xStateListItem ) );
 
 			#if( configUSE_TASK_NOTIFICATIONS == 1 )
@@ -3821,6 +3834,20 @@
 #endif /* INCLUDE_uxTaskGetStackHighWaterMark */
 /*-----------------------------------------------------------*/
 
+#if (INCLUDE_pxTaskGetStackStart == 1)
+ uint8_t* pxTaskGetStackStart( TaskHandle_t xTask)
+ {
+ TCB_t *pxTCB;
+ UBaseType_t uxReturn;
+ (void)uxReturn;
+
+ pxTCB = prvGetTCBFromHandle( xTask );
+ return ( uint8_t * ) pxTCB->pxStack;
+ }
+
+#endif /* INCLUDE_pxTaskGetStackStart */
+/*-----------------------------------------------------------*/
+
 #if ( INCLUDE_vTaskDelete == 1 )
 
 	static void prvDeleteTCB( TCB_t *pxTCB )
@@ -3990,7 +4017,7 @@
 
 					/* Inherit the priority before being moved into the new list. */
 					pxMutexHolderTCB->uxPriority = pxCurrentTCB->uxPriority;
- prvAddTaskToReadyList( pxMutexHolderTCB );
+ prvReaddTaskToReadyList( pxMutexHolderTCB );
 				}
 				else
 				{
@@ -4080,7 +4107,7 @@
 					any other purpose if this task is running, and it must be
 					running to give back the mutex. */
 					listSET_LIST_ITEM_VALUE( &( pxTCB->xEventListItem ), ( TickType_t ) configMAX_PRIORITIES - ( TickType_t ) pxTCB->uxPriority ); /*lint !e961 MISRA exception as the casts are only redundant for some ports. */
- prvAddTaskToReadyList( pxTCB );
+ prvReaddTaskToReadyList( pxTCB );
 
 					/* Return true to indicate that a context switch is required.
 					This is only actually required in the corner case whereby
@@ -5112,6 +5139,7 @@
 			/* Add the task to the suspended task list instead of a delayed task
 			list to ensure it is not woken by a timing event. It will block
 			indefinitely. */
+ traceMOVED_TASK_TO_SUSPENDED_LIST(pxCurrentTCB);
 			vListInsertEnd( &xSuspendedTaskList, &( pxCurrentTCB->xStateListItem ) );
 		}
 		else
@@ -5128,12 +5156,14 @@
 			{
 				/* Wake time has overflowed. Place this item in the overflow
 				list. */
+ traceMOVED_TASK_TO_OVERFLOW_DELAYED_LIST();
 				vListInsert( pxOverflowDelayedTaskList, &( pxCurrentTCB->xStateListItem ) );
 			}
 			else
 			{
 				/* The wake time has not overflowed, so the current block list
 				is used. */
+ traceMOVED_TASK_TO_OVERFLOW_DELAYED_LIST();
 				vListInsert( pxDelayedTaskList, &( pxCurrentTCB->xStateListItem ) );
 
 				/* If the task entering the blocked state was placed at the
@@ -5163,11 +5193,13 @@
 		if( xTimeToWake < xConstTickCount )
 		{
 			/* Wake time has overflowed. Place this item in the overflow list. */
+ traceMOVED_TASK_TO_OVERFLOW_DELAYED_LIST();
 			vListInsert( pxOverflowDelayedTaskList, &( pxCurrentTCB->xStateListItem ) );
 		}
 		else
 		{
 			/* The wake time has not overflowed, so the current block list is used. */
+ traceMOVED_TASK_TO_DELAYED_LIST();
 			vListInsert( pxDelayedTaskList, &( pxCurrentTCB->xStateListItem ) );
 
 			/* If the task entering the blocked state was placed at the head of the

7. 参考

User Manual

Archlinux上Buildroot的基础使用

Wed, 26 Feb 2020 13:10:36 +0000

什么是Buildroot？好吃么？

Buildroot是一套用于构建定制化rootfs环境的工具集，可以通过简单步骤在嵌入式系统上快速构建rootfs环境用于应用部署。

为什么选择Buildroot？和发行版rootfs的区别是？

1. 架构支持广泛

大多数发行版rootfs只支持常见主流架构，不仅如此，发行版在架构支持方面本着兼容性原则，即便是支持的架构，最终依然会牺牲一部分性能（Hard Float，Architecture Specific的SIMD指令集支持等），Buildroot则可以自由选择工具链及编译参数，并且指定所需要的优化选项进行构建。

2. 体积小，工作稳定

发行版为了保证易用性，通常加入了大量功能与程序便于用户使用，同时为了开箱即用的特征，在网络配置等关键环节也会使用NetworkManager等高级工具进行管理，Init系统也大多使用Systemd，增大了系统的复杂程度，同时不可避免的要产生文件写入等操作，加速Flash等存储设备寿命损耗，降低设备使用年限。Buildroot则避免了上述种种问题，单一稳定的网络配置，可选的DHCP等组件，Busybox轻量级的初始化系统及CoreUtils，可以只读的文件系统支持都使得它对于小体积Flash，低写入寿命，长时间工作的嵌入式系统极其友好。

3. 定制程度高，配置简单

不需要使用包管理器，基于Kconfig的编译配置系统，软件支持也很齐全，只需要选择所需工具就可以构建上机即用的rootfs。

获取Buildroot及工具链

0. 了解硬件平台

为了构建出我们需要的可用的rootfs，我们首先需要了解我们的硬件平台。

本文来自之前为 LoRaWAN 网关设计平台的过程中，我们选用了全志V3s这款SoC，LQFP封装，内嵌512Mbit DDR2 SDRAM，单核Cortex-A7 w/ NEON+FPv4，很适合我们需要的场景使用。

1. 获取Buildroot

Buildroot的最新版本可以从 https://buildroot.org/download.html 下载tarball。

2. 获取工具链

Archlinux默认工具链及AUR提供的交叉工具链都是无法复制使用的，Buildroot在构建时会将工具链复制到工作目录执行，因此我们需要选择Portable的工具链二进制或者像我一样选择 The Hard Way - crosstool-NG编译工具链。

2.1 crosstool-NG的使用及工具链构建

crosstool-NG（以下简称 ct-ng ）是一个快速简易构建工具链的工具（没错够绕嘴的），可以用于完成以下几个主要步骤

构建 buildutils
构建 3-Stage Cross GCC 及对应的C Library
构建 Cross-GDB

2.1.1 ct-ng 获取及编译

部分发行版可能打包了crosstool-NG，Archlinux并没有打包，而且为了使用新版本工具链及配置，推荐跟随文档使用如下的编译安装方式。

首先我们需要从 https://crosstool-ng.github.io 获取最新版本的ct-ng（Git/Tarball），解压后进入项目目录，跟随 https://crosstool-ng.github.io/docs/install/ 的步骤，执行 bootstrap ，选择合适prefix，编译并安装（ make 与 make install 想必你们用得比我熟）。

现在我们可以使用 ct-ng 命令了，不过不要急着试试，因为这东西会在当前目录创建一些配置文件，所以我们要新建一个工作目录用于 ct-ng 保存配置及文件。

本次目录名叫 arm-linux-glibc ，字面意思：target 是 32-bit 的 ARM 处理器，操作系统 Linux ，C标准库使用GNU LibC实现，因为 AUR 中的工具链一样使用了 GlibC，方便日后交叉编译使用（但是其实可以完全一套工具链跑到黑）。

在工作目录中，运行 ct-ng list-samples 可以查看当前的所有sample列表，这里我们选用 arm-cortex_a15-linux-gnueabihf 作为我们的预设target，之后的步骤基于这个配置修改。选择这个配置的原因是，Cortex-A7与Cortex-A15都基于ARMv7-A，同时都使用FPv4浮点处理器和NEON SIMD指令。

运行 ct-ng arm-cortex_a15-linux-gnueabihf 配置当前工程， ct-ng nconfig 使用酷炫的 nurses 配置界面修改配置。

多数配置不需要更改，可以添加tarball cache以节约下载时间。

                                    .config - crosstool-NG  Configuration
 ┌── Paths and misc options ───────────────────────────────────────────────────────────────────────────────┐
 │                                                                                                         │
 │        *** crosstool-NG behavior ***                                                                    │
 │    [ ] Use obsolete features                                                                            │
 │    [ ] Try features marked as EXPERIMENTAL                                                              │
 │    [ ] Debug crosstool-NG                                                                               │
 │        *** Paths ***                                                                                    │
 │        (${HOME}/Softwares/Crosstool-NG/tarballs) Local tarballs directory                               │
 │    [*]   Save new tarballs                                                                              │
 │    [ ] Prefer buildroot-style layout of the downloads                                                   │
 │        (${CT_TOP_DIR}/.build) Working directory                                                         │
 │        (${CT_PREFIX:-${HOME}/x-tools}/${CT_HOST:+HOST-${CT_HOST}/}${CT_TARGET}) Prefix directory        │
 │    [*]   Remove the prefix dir prior to building                                                        │
 │    [*] Remove documentation                                                                             │
 │    [*] Install licenses                                                                                 │
 │    [*] Render the toolchain read-only                                                                   │
 │    [*] Strip host toolchain executables                                                                 │
 │    [ ] Strip target toolchain executables                                                               │
 │        *** Downloading ***                                                                              │
 │        Download agent (wget)  --->                                                                      │
 │    [ ] Forbid downloads                                                                                 │
 │    [ ]   Force downloads                                                                                │
 │        (10)  Connection timeout                                                                         │
 │        (--passive-ftp --tries=3 -nc --progress=dot:binary) Extra options to wget                        │
 │    [ ]   Stop after downloading tarballs                                                                │
 │    [ ]   Use a mirror                                                                                   │
 │    [*]   Verify download digests (checksums)                                                            │
 │            Digest algorithm (SHA-512)  --->                                                             │
 │    [ ]   Verify detached signatures                                                                     │
 │                                                                                                         │
 │                                                                                                         │
 └F1Help─F2SymInfo─F3Help 2─F4ShowAll─F5Back─F6Save─F7Load─F8SymSearch─F9Exit──────────────────────────────┘

一切准备就绪就可以运行ct-ng build，在x-tools就可以拿到我们的工具链了。

配置编译Buildroot

Buildroot的配置与Crosstool-NG类似，也使用了Kconfig及Kbuild。解压下载得到的tar包，进入目录运行make nconfig即可看到相似的配置界面。

 ┌── Target options ───────────────────────────────────────────────────────────────────────────────────────┐
 │                                                                                                         │
 │                             Target Architecture (ARM (little endian))  --->                             │
 │                             Target Binary Format (ELF)  --->                                            │
 │                             Target Architecture Variant (cortex-A7)  --->                               │
 │                             Target ABI (EABIhf)  --->                                                   │
 │                             Floating point strategy (NEON/VFPv4)  --->                                  │
 │                             ARM instruction set (ARM)  --->                                             │
 │                                                                                                         │
 │                                                                                                         │
 │                                                                                                         │
 │                                                                                                         │
 │                                                                                                         │
 │                                                                                                         │
 │                                                                                                         │
 │                                                                                                         │
 │                                                                                                         │
 │                                                                                                         │
 │                                                                                                         │
 │                                                                                                         │
 │                                                                                                         │
 │                                                                                                         │
 │                                                                                                         │
 │                                                                                                         │
 │                                                                                                         │
 │                                                                                                         │
 │                                                                                                         │
 │                                                                                                         │
 │                                                                                                         │
 │                                                                                                         │
 │                                                                                                         │
 └F1Help─F2SymInfo─F3Help 2─F4ShowAll─F5Back─F6Save─F7Load─F8SymSearch─F9Exit──────────────────────────────┘

我们在Target Options中选择我们CPU的类型，Cortex-A7，硬浮点，NEON/VFPv4。

 ┌── Toolchain ────────────────────────────────────────────────────────────────────────────────────────────┐
 │                                                                                                         │
 │     Toolchain type (External toolchain)  --->                                                           │
 │     *** Toolchain External Options ***                                                                  │
 │     Toolchain (Custom toolchain)  --->                                                                  │
 │     Toolchain origin (Pre-installed toolchain)  --->                                                    │
 │     (/home/imi415/Softwares/Crosstool-NG/arm-cortex_a15-linux-gnueabihf/arm-cortex_a15-linux-gnueabi    │
 │     (arm-cortex_a15-linux-gnueabihf) Toolchain prefix                                                   │
 │     External toolchain gcc version (9.x)  --->                                                          │
 │     External toolchain kernel headers series (5.4.x or later)  --->                                     │
 │     External toolchain C library (glibc/eglibc)  --->                                                   │
 │ [*] Toolchain has SSP support?                                                                          │
 │ [*] Toolchain has RPC support?                                                                          │
 │ [*] Toolchain has C++ support?                                                                          │
 │ [ ] Toolchain has D support?                                                                            │
 │ [ ] Toolchain has Fortran support?                                                                      │
 │ [ ] Toolchain has OpenMP support?                                                                       │
 │ [ ] Copy gdb server to the Target                                                                       │
 │     *** Host GDB Options ***                                                                            │
 │ [ ] Build cross gdb for the host                                                                        │
 │     *** Toolchain Generic Options ***                                                                   │
 │ [ ] Copy gconv libraries                                                                                │
 │     ()  Extra toolchain libraries to be copied to target                                                │
 │ [*] Enable MMU support                                                                                  │
 │     ()  Target Optimizations                                                                            │
 │     ()  Target linker options                                                                           │
 │ [ ] Register toolchain within Eclipse Buildroot plug-in                                                 │
 │                                                                                                         │
 │                                                                                                         │
 │                                                                                                         │
 │                                                                                                         │
 └F1Help─F2SymInfo─F3Help 2─F4ShowAll─F5Back─F6Save─F7Load─F8SymSearch─F9Exit──────────────────────────────┘

在工具链配置中指定我们之前编译的工具链路径，下面相关的参数如果和实际不符的话Buildroot会提示我们修改。

默认配置使用Busybox作为初始化系统及核心组件，其余配置可自行摸索。

配置结束后可以执行 make 启动编译，Buildroot会自动下载所需组件，最后生成的rootfs则位于 output/images/rootfs.tar 中。

上电运行

使用生成的rootfs及另外编译的内核，系统即可启动。

[    1.255069] VFS: Mounted root (ext4 filesystem) on device 179:2.
[    1.263416] devtmpfs: mounted
[    1.267895] Freeing unused kernel memory: 1024K
[    1.272748] Run /sbin/init as init process
[    1.415171] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
Starting syslogd: OK
Starting klogd: OK
Running sysctl: OK
Initializing random number generator: OK
Saving random seed: [    1.654797] random: dd: uninitialized urandom read (512 bytes read)
OK
Starting network: OK

Welcome to Buildroot
buildroot login: 

灵车IPQ4019——R619AC

Sun, 24 Nov 2019 12:49:19 +0000

OpenWrt主线已支持这个型号 (P&W R619AC)，不再需要本文内容。

1. 简介

不多说，灵车，IPQ4019，OpenWrt没支持，国产X-Wrt不想用，拿ImageBuilder打Patch吧。

2. 系统

打Patch的话参见X-Wrt的commit，这个就差不多了。

但是PCIe并不能开箱即用。

要想PCIe能用的话还存在三个问题

没设备树
没电
没REFCLK

miniPCIe接口3.3V AUX没电的问题可以看下图

miniPCIe的供电部分，缺焊元件为bypass电阻

恩山的方案是短路这个电阻，但是这需要一定的焊接，而且也不便使用，根据观察可以发现左侧SOP-8封装的器件为 IRF7416PbF 功率MOSFET，封装如下：

IRF7416PbF Datasheet

这个MOSFET的源极和漏极接在整板3.3V与miniPCIe的供电3.3V中间，我们可以推断该MOSFET的用途是miniPCIe的供电控制，那么栅极推断应为SoC GPIO控制。

问题来了，这货有100个GPIO，我们如何找到正确的控制这个MOSFET的GPIO呢？

根据实际插入PCIe模块的情况及万用表测试的结果，该IO的状态只存在是两种可能：

输出模式，高电平
输入模式，内部上拉

那么范围缩小到了状态为输出高或者输入上拉，且没被其他外设占用的GPIO，可以通过/sys/kernel/debug/gpio查看符合条件的Pin，如下：

root@OpenWrt:~# cat /sys/kernel/debug/gpio  | grep "pull up"
 gpio0   : in  high func0 2mA pull up
 gpio1   : in  high func0 2mA pull up
 gpio6   : in  high func1 2mA pull up
 gpio7   : in  high func1 2mA pull up
 gpio10  : in  high func0 2mA pull up
 gpio11  : in  high func0 2mA pull up
 gpio12  : in  high func1 2mA pull up
 gpio13  : in  high func1 2mA pull up
 gpio14  : in  low  func1 2mA pull up
 gpio15  : in  low  func1 2mA pull up
 gpio20  : in  high func0 2mA pull up
 gpio21  : in  high func0 2mA pull up
 gpio22  : in  low  func0 2mA pull up
 gpio23  : in  high func1 10mA pull up
 gpio24  : in  high func1 10mA pull up
 gpio25  : in  high func1 10mA pull up
 gpio26  : in  high func1 10mA pull up
 gpio27  : in  high func1 16mA pull up
 gpio28  : in  high func1 10mA pull up
 gpio29  : in  high func0 2mA pull up
 gpio30  : in  high func0 2mA pull up
 gpio31  : in  high func0 2mA pull up
 gpio32  : out low  func0 2mA pull up
 gpio34  : in  high func0 2mA pull up
 gpio35  : in  high func0 2mA pull up
 gpio39  : out high func0 2mA pull up
 gpio40  : in  high func0 2mA pull up
 gpio50  : out high func0 2mA pull up
 gpio52  : out high func0 2mA pull up
 gpio53  : in  high func1 2mA pull up
 gpio58  : in  low  func1 2mA pull up
 gpio59  : in  low  func1 2mA pull up
root@OpenWrt:~# cat /sys/kernel/debug/gpio  | grep "out high"
 gpio4   : out high func0 2mA pull down
 gpio39  : out high func0 2mA pull up
 gpio50  : out high func0 2mA pull up
 gpio52  : out high func0 2mA pull up
 gpio61  : out high func0 2mA pull down
root@OpenWrt:~# 

其中可以筛选出func0的IO即为GPIO function。

根据依次尝试，GPIO2 即为我们要找的GPIO。

之后我们需要在设备树里让kernel在配置PCIe的时候初始化好这个GPIO，如下所示

+&pcie0 {
+        status = "okay";
+
+        perst-gpio = <&tlmm 4 GPIO_ACTIVE_LOW>;
+        wake-gpio = <&tlmm 40 GPIO_ACTIVE_HIGH>;
+
+       pinctrl-0 = <&pcie_pins>;
+       pinctrl-names = "default";
+
+        bridge@0,0 {
+                reg = <0x00000000 0 0 0 0>;
+                #address-cells = <3>;
+                #size-cells = <2>;
+                ranges;
+
+                wifi2: wifi@1,0 {
+                        compatible = "qcom,ath10k";
+                        reg = <0x00010000 0 0 0 0>;
+                };
+        };
+};

我在miniPCIe插槽里插入的是QCA9880 3x3模块，如果是其他模块可以修改或者干脆删除 wifi2 节点。

其中要注意的是pinctrl字段，我们并不需要使用pinctrl初始化已经有了的perst和wake，但是由于这个电源控制并不在我们的pcie能配置的GPIO里，我们需要单独配置他。

在 &tlmm 设备节点中添加我们的GPIO2配置，配置为输出低电平，2mA（默认）和下拉。之所以在配置下拉的同时还要设置输出是为了防止下拉强度不够导致MOS工作在线性区无法正常供电。

+       pcie_pins: pcie_pinmux {
+               mux {
+                       pins = "gpio2";
+                       function = "gpio";
+                       bias-pull-down;
+                       output-low;
+               };
+       };

按照这种方式修改编译得到的OpenWrt就可以在加载驱动时自动配置给卡供电了。

回到REFCLK的问题

REFCLK的焊盘出厂时默认留空，补焊上即可，如下图：

手头没有0402的0欧电阻了，用跳线短上

一般大多数的miniPCIe卡只需要3.3V供电，不过板子还预留了RESERVED pin的5V供电电路，据恩山说法是为内置PA的大功率无线网卡准备的。有需求可以短掉R443和R447 。如果不清楚所用模块型号则不需要，这里不做赘述。

附PCIe正常初始化日志如下：

[    0.051140] qcom-pcie 40000000.pci: host bridge /soc/pci@40000000 ranges:
[    0.051183] qcom-pcie 40000000.pci:    IO 0x40200000..0x402fffff -> 0x40200000
[    0.051210] qcom-pcie 40000000.pci:   MEM 0x40300000..0x40ffffff -> 0x40300000
[    0.326667] qcom-pcie 40000000.pci: Link up
[    0.326822] qcom-pcie 40000000.pci: PCI host bridge to bus 0000:00
[    0.326844] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.326860] pci_bus 0000:00: root bus resource [io  0x0000-0xfffff] (bus address [0x40200000-0x402fffff])
[    0.326874] pci_bus 0000:00: root bus resource [mem 0x40300000-0x40ffffff]
[    0.326916] pci 0000:00:00.0: [17cb:1001] type 01 class 0x060400
[    0.326953] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x00000fff 64bit]
[    0.327013] pci 0000:00:00.0: PME# supported from D0 D3hot
[    0.328977] pci 0000:01:00.0: [168c:003c] type 00 class 0x028000
[    0.329176] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x001fffff 64bit]
[    0.329404] pci 0000:01:00.0: reg 0x30: [mem 0x00000000-0x0000ffff pref]
[    0.329837] pci 0000:01:00.0: supports D1 D2
[    0.329845] pci 0000:01:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[    0.331776] pci 0000:00:00.0: BAR 8: assigned [mem 0x40300000-0x405fffff]
[    0.331793] pci 0000:00:00.0: BAR 0: assigned [mem 0x40600000-0x40600fff 64bit]
[    0.331821] pci 0000:01:00.0: BAR 0: assigned [mem 0x40400000-0x405fffff 64bit]
[    0.331899] pci 0000:01:00.0: BAR 6: assigned [mem 0x40300000-0x4030ffff pref]
[    0.331915] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
[    0.331930] pci 0000:00:00.0:   bridge window [mem 0x40300000-0x405fffff]
[    0.334340] pcieport 0000:00:00.0: AER enabled with IRQ 97

关于LTE模块

市面99.9%的LTE模块是USB通讯的，如果使用LTE模块则不需要短接REFCLK，不过上述操作依然可以实现免焊接。

3. 已知问题（WIP）

SDHCI在USB插入的时候会出错，估计是pinmux的问题，尚未解决
USB不可用

Mbed OS 5的自定义开发板移植 - NRF51

Sat, 27 Oct 2018 08:12:12 +0000

前言

最开始看到Mbed OS5的时候没太在意，然而最近Nucleo买多了就变成了……

真香！

步骤

正好手头的BLE开发板就又开始痒痒，那就上咯

手头的NRF51开发板是微雪的NRF51822开发板，芯片型号为_AC，意即32KB SRAM+256KB Flash的型号。我们首先用Mbed CLI新建一个项目，起名叫nrf51_hello就好了。

mbed new nrf51_hello

会在当前目录创建工程目录，随便写一个main.cpp，包含main函数用来对付链接问题

#include <mbed.h>

DigitalOut led(LED1);

int main() {
    while(true) {
        led = !led;
        wait(0.5);
    }
}

嗯，点灯工程师。

于是我们来处理板子的问题。Mbed OS 5的大致结构如下

.
├── [3.5K]  CONTRIBUTING.md
├── [ 254]  DOXYGEN_FRONTPAGE.md
├── [  73]  Jenkinsfile
├── [8.9K]  LICENSE
├── [2.5K]  README.md
├── [4.0K]  TESTS
├── [4.0K]  TEST_APPS
├── [4.0K]  UNITTESTS
├── [   0]  astyle-branch.out
├── [4.0K]  cmsis
├── [4.0K]  components
├── [4.0K]  docs
├── [107K]  doxyfile_options
├── [2.3K]  doxygen_options.json
├── [4.0K]  drivers
├── [4.0K]  events
├── [4.0K]  features
├── [4.0K]  hal
├── [ 36K]  logo.png
├── [2.9K]  mbed.h
├── [4.0K]  platform
├── [ 381]  requirements.txt
├── [4.0K]  rtos
├── [4.0K]  targets
└── [4.0K]  tools

14 directories, 11 files

添加板子定义的时候，我们需要在如下几个部分添加相应的文件

targets/targets.json

targets.json记录了所有板子的型号和特性，也是Mbed CLI寻找编译对象的入口

我们在其中添加自己的板子信息（照着SoC差不多的板子抄过来即可）

diff --git a/targets/targets.json b/targets/targets.json
index 3d0c2bdf5..1dc765096 100755
--- a/targets/targets.json
+++ b/targets/targets.json
@@ -2709,6 +2709,24 @@
         "extra_labels_add": ["DELTA_DFCM_NNN50"],
         "macros_add": ["TARGET_DELTA_DFCM_NNN50"]
     },
+    "WAVESHARE_NRF51822": {
+        "supported_form_factors": ["ARDUINO"],
+        "inherits": ["MCU_NRF51_32K_UNIFIED"],
+        "device_has": ["USTICKER", "LPTICKER", "ANALOGIN", "I2C", "I2C_ASYNCH", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "SLEEP", "SPI", "SPI_ASYNCH", "SPISLAVE"],
+        "device_name": "nRF51822_xxAC"
+    },
+    "WAVESHARE_NRF51822_BOOT": {
+        "supported_form_factors": ["ARDUINO"],
+        "inherits": ["MCU_NRF51_32K_BOOT"],
+        "extra_labels_add": ["WAVESHARE_NRF51822"],
+        "macros_add": ["TARGET_WAVESHARE_NRF51822"]
+    },
+    "WAVESHARE_NRF51822_OTA": {
+        "supported_form_factors": ["ARDUINO"],
+        "inherits": ["MCU_NRF51_32K_OTA"],
+        "extra_labels_add": ["WAVESHARE_NRF51822"],
+        "macros_add": ["TARGET_WAVESHARE_NRF51822"]
+    },
     "NRF51_DK_LEGACY": {
         "supported_form_factors": ["ARDUINO"],
         "inherits": ["MCU_NRF51_32K"],

可以看出我们的板子叫做 WAVESHARE_NRF51822 。

Target定义文件，上述的 inherits 已经给定了这个板子所属的厂商和型号，在对应目录里添加相应定义文件，包含引脚定义 PinNames.h 和设备定义 device.h 。根据板子的外设和引脚信息修改对应文件即可。我们正在添加的板子应位于

targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_NRF51/TARGET_MCU_NRF51822_UNIFIED/TARGET_WAVESHARE_NRF51822 中。

+++ ../TARGET_NRF51_DK/PinNames.h	2018-10-27 12:42:18.034690786 +0800
--- PinNames.h	2018-10-27 13:43:22.036980344 +0800
***************
*** 120,134 ****
      P0_29 = p29,
      P0_30 = p30,
  
!     LED1    = p21,
!     LED2    = p22,
!     LED3    = p23,
!     LED4    = p24,
  
!     BUTTON1 = p17,
!     BUTTON2 = p18,
!     BUTTON3 = p19,
!     BUTTON4 = p20,
  
      RX_PIN_NUMBER  = p11,
      TX_PIN_NUMBER  = p9,
--- 120,132 ----
      P0_29 = p29,
      P0_30 = p30,
  
!     LED1    = p18,
!     LED2    = p19,
!     LED3    = p20,
!     LED4    = p21,
  
!     BUTTON1 = p16,
!     BUTTON2 = p17,
  
      RX_PIN_NUMBER  = p11,
      TX_PIN_NUMBER  = p9,

本例中 device.h 无需修改。

添加完板子定义我们来简单测试一下

mbed compile -m WAVESHARE_NRF51822 -t GCC_ARM -j8

...
Link: nrf51_hello
Elf2Bin: nrf51_hello
| Module             |      .text |    .data |     .bss |
|--------------------|------------|----------|----------|
| [fill]             |    171(+4) |   19(+0) |   55(+0) |
| [lib]/c.a          |  22739(+0) | 2472(+0) |   56(+0) |
| [lib]/gcc.a        |   7142(+0) |    0(+0) |    0(+0) |
| [lib]/misc         |    208(+0) |   12(+0) |   25(+0) |
| [lib]/stdc++.a     |      1(+0) |    0(+0) |    0(+0) |
| main.o             |   2229(+7) |    5(+0) |   97(+0) |
| mbed-os/components |     54(+0) |    0(+0) |    0(+0) |
| mbed-os/drivers    |   787(+16) |    0(+0) |    0(+0) |
| mbed-os/events     |   1240(+0) |    0(+0) |    0(+0) |
| mbed-os/features   |  40015(+6) |    4(+0) | 1334(+0) |
| mbed-os/hal        |   1758(-2) |    8(+0) |  130(+0) |
| mbed-os/platform   |   3898(-4) |  260(+0) |  221(+0) |
| mbed-os/rtos       |  10287(-2) |  168(+0) | 6113(+0) |
| mbed-os/targets    |   9281(-3) |   20(+0) |  865(+0) |
| Subtotals          | 99810(+22) | 2968(+0) | 8896(+0) |
Total Static RAM memory (data + bss): 11864(+0) bytes
Total Flash memory (text + data): 102778(+22) bytes

Image: ./BUILD/WAVESHARE_NRF51822/GCC_ARM/nrf51_hello.hex

我们就可以在生成目录 BUILD/ 下找到ELF和IHEX文件了。

NRF51需要一个闭源静态库用来实现驱动和蓝牙，Nordic管他叫SoftDevice。我们首先需要下载SoftDevice到设备。

本例中依然使用OpenOCD，调试器使用LPC11U35开发板运行DAPLink（CMSIS-DAP）固件，制作方法后述。

运行

openocd -f /usr/share/openocd/scripts/interface/cmsis-dap.cfg -f /usr/share/openocd/scripts/target/nrf51.cfg

Open On-Chip Debugger 0.10.0+dev-00523-g2a3b709aa (2018-08-30-22:25)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
cortex_m reset_config sysresetreq
adapter speed: 1000 kHz
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : CMSIS-DAP: SWD  Supported
Info : CMSIS-DAP: FW Version = 1.10
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x0bb11477
Info : nrf51.cpu: hardware has 4 breakpoints, 2 watchpoints
Info : Listening on port 3333 for gdb connections

一如既往，显示连接成功。

运行 telnet localhost 4444 连接到OpenOCD的CLI界面，运行

reset init halt CPU，接着运行

flash write_image erase /path/to/softdevice/s130.hex 下载SoftDevice到设备。

最后运行

flash write_image erase /path/to/nrf51_hello.elf 下载应用程序到设备，执行 reset 即可点灯成功（

！ 点灯工程师

后记

P.S. NRF51822 的串口默认流控，请确认CTS/RTS pin连接正常，否则串口会卡死目标板。

我们来运行一下Mbed OS的心率传感器示例

由于之前已经下载过SoftDevice，本次无需重新下载。直接下载应用程序到设备即可。 nRF Connect 应用程序

通过Nordic的BLE App，就可以看到心率了…… ~~170了，我要挂了.jpg~~

i.MX RT1050 简单上手

Sun, 09 Sep 2018 10:16:17 +0000

1. 前言

i.MX RT1050大概是能买到的比较便宜的Cortex-M7 MCU了，本文介绍从裸Linux环境开始配置完整工作环境。

2. 硬件准备

i.MX RT1050开发板
JTAG/SWD调试器
足够多的USB线和杜邦线

3. 软件准备

ARM GCC（任意版本，>= 7）
CMake
OpenOCD（越新越好）
文本编辑器（任意）

4. OpenOCD调试环境准备

在任意位置保存如下target配置

# NXP i.MX RT1050 family (Arm Cortex-M7 @ 600 MHz)
#

if { [info exists CHIPNAME] } {
        set _CHIPNAME $CHIPNAME
} else {
        set _CHIPNAME imxrt1050
}

source [find target/swj-dp.tcl]

if { [info exists CPU_SWD_TAPID] } {
        set _CPU_SWD_TAPID $CPU_SWD_TAPID
} else {
        set _CPU_SWD_TAPID 0x0bd11477
}

if { [using_jtag] } {
        set _CPU_TAPID 0
} else {
        set _CPU_TAPID $_CPU_SWD_TAPID
}

swj_newdap $_CHIPNAME cpu -irlen 4 -expected-id $_CPU_TAPID

set _TARGETNAME $_CHIPNAME
dap create $_TARGETNAME.dap -chain-position $_TARGETNAME.cpu
target create $_TARGETNAME cortex_m -dap $_TARGETNAME.dap

if { ![using_hla] } {
        cortex_m reset_config sysresetreq
}

gdb_breakpoint_override hard # 调试XIP Flash应用时，见说明

adapter_khz 1000

根据你的JTAG Adapter，选择合适的配置文件
运行OpenOCD，直到看到类似的消息代表识别成功
OpenOCD会自动选择断点模式，Flash区域应使用硬件断点，否则无法命中。由于i.MX RT1050 无片上Flash，Config中并未加入Flash bank的定义，而是强制全局使用硬件断点以避免这种情况。RT1050的Cortex-M7拥有8个硬件断点，这对于大多数调试情况都足够了。个人使用时也可以加入自己板子定义的Flash区域，但目前（2018.12现在）OpenOCD并不支持RT1050的Flash读写，所以仅能用来自动配置断点类型。

openocd -f ~/Documents/Conf/OpenOCD/interface/ft232-swd.cfg -f ~/Documents/Conf/OpenOCD/target/imxrt1050.cfg

Open On-Chip Debugger 0.10.0+dev-00523-g2a3b709aa (2018-08-30-22:25)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : FTDI SWD mode enabled
adapter speed: 2000 kHz
cortex_m reset_config sysresetreq
adapter speed: 1000 kHz
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x0bd11477
Info : imxrt1050: hardware has 8 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections

5. 示例工程准备

从 https://mcuxpresso.nxp.com/en/dashboard 添加并下载i.MX RT1050的SDK，根据芯片型号选择对应的SDK。（测试中Rev.1 和Rev.2可以互换但不建议使用）
从NXP网站下载 Config Tool。
解压deb，选择合适的位置放置Config Tool，运行/path/to/config_tool/bin/tool并选择解压到SDK的位置，从示例创建新工程，类型选择ARM GCC。

6. 编译示例工程

在工程目录中运行ARMGCC_DIR=/path/to/arm_gcc ./build_debug.sh即可编译出ELF
在工程目录中运行ARMGCC_DIR=/path/to/arm_gcc ./build_flexspi_nor_debug.sh
由于第二步中我们选择了flexspi_nor配置，该程序将被链接进FlexSPI NOR Flash区域（0x60000000）；第一步中的ELF则被链接进SRAM区域。

7. 调试

运行GDB连接OpenOCD并加载elf，载入ELF到设备SRAM并跳转入口点即可开始调试（注：事先需要halt CPU）
以下步骤中continue位置不建议使用，应使用 jump *entry_point 跳转程序入口点开始执行。
本例中程序入口点位于 0x468，即 jump *0x468 。

130 imi415@imi415 ..dwares/Kinetis_Projects/freertos_hello % arm-none-eabi-gdb -ex "target remote localhost:3333" debug/freertos_hello.elf                                                                                                  :(
GNU gdb (GDB) 8.1.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-pc-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from debug/freertos_hello.elf...done.
Remote debugging using localhost:3333
0x600044d6 in ?? ()
(gdb) load
Loading section .interrupts, size 0x400 lma 0x0
Loading section .text, size 0x5c08 lma 0x400
Loading section .ARM, size 0x8 lma 0x6008
Loading section .init_array, size 0x4 lma 0x6010
Loading section .fini_array, size 0x4 lma 0x6014
Loading section .data, size 0x6c lma 0x6018
Start address 0x468, load size 24708
Transfer rate: 69 KB/sec, 3529 bytes/write.
(gdb) b main
Breakpoint 1 at 0x4afa: file /home/imi415/Documents/Hardwares/Kinetis_Projects/freertos_hello/source/freertos_hello.c, line 68.
(gdb) c
Continuing.

Breakpoint 1, main () at /home/imi415/Documents/Hardwares/Kinetis_Projects/freertos_hello/source/freertos_hello.c:68
68	    BOARD_ConfigMPU();
(gdb) 

8. 下载程序到FlexSPI NOR Flash 并启用XIP

根据开发板制造商的参数修改xip目录下文件，配置XIP Header。
NOR Flash XIP Header类似下方

#include "fire_imxrt1050_flexspi_nor_config.h"

/*******************************************************************************
 * Code
 ******************************************************************************/
#if defined(XIP_BOOT_HEADER_ENABLE) && (XIP_BOOT_HEADER_ENABLE == 1)
#if defined(__CC_ARM) || defined(__GNUC__)
__attribute__((section(".boot_hdr.conf")))
#elif defined(__ICCARM__)
#pragma location = ".boot_hdr.conf"
#endif

const flexspi_nor_config_t spiflash_config = {
    .memConfig =
        {
            .tag = FLEXSPI_CFG_BLK_TAG,                                   /*标志：FCFB*/
            .version = FLEXSPI_CFG_BLK_VERSION,                           /*版本：V1.4.0*/
            .readSampleClkSrc = kFlexSPIReadSampleClk_LoopbackInternally, /*内部环回*/
            .csHoldTime = 3u,                                             /*保持时间*/
            .csSetupTime = 3u,                                            /*建立时间*/
            .columnAddressWidth = 0u,                                     /*列地址宽度*/
            .deviceModeCfgEnable = 1u,                                    /*设备模式配置使能*/
            .deviceModeType = 1u,                                         /*Quad 使能命令*/
            .deviceModeSeq.seqNum = 1u,                                   /*LUT序列号*/
            .deviceModeSeq.seqId = 4u,                                    /*LUT序列索引*/
            .deviceModeArg = 0x000200,                                    /*设置 QE=1（S9）*/
            .deviceType = kFlexSpiDeviceType_SerialNOR,                   /*设备类型为nor flash*/
            .sflashPadType = kSerialFlash_4Pads,                          /*设备数据总线为4*/
            .serialClkFreq = kFlexSpiSerialClk_133MHz,                    /*flash 时钟*/
            .sflashA1Size = 32u * 1024u * 1024u,                          /*flash 大小32MBytes*/
            //.dataValidTime = {16u, 16u},
            .lookupTable =
                {
                    /*快速读命令（四线）*/
                    [0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xEB, RADDR_SDR, FLEXSPI_4PAD, 0x18),
                    [1] = FLEXSPI_LUT_SEQ(DUMMY_SDR, FLEXSPI_4PAD, 0x06, READ_SDR, FLEXSPI_4PAD, 0x04),

                    /*读状态命令*/
                    [1 * 4] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x05, READ_SDR, FLEXSPI_1PAD, 0x04),
                    /*写使能命令*/
                    [3 * 4] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x06, STOP, FLEXSPI_1PAD, 0),
                    /*擦除扇区命令*/
                    [5 * 4] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x20, RADDR_SDR, FLEXSPI_1PAD, 0x04),
                    /*页编程命令（四线）*/
                    [9 * 4] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x32, RADDR_SDR, FLEXSPI_1PAD, 0x18),
                    [9 * 4 + 1] = FLEXSPI_LUT_SEQ(WRITE_SDR, FLEXSPI_4PAD, 0x04, STOP, FLEXSPI_1PAD, 0),
                    /*整片擦除*/
                    [11 * 4] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xc7, STOP, FLEXSPI_1PAD, 0),
                },
        },
    .pageSize = 256u,         /*页大小为256字节*/
    .sectorSize = 4u * 1024u, /*扇区大小为4k字节*/
};
#endif /* XIP_BOOT_HEADER_ENABLE */

从NXP下载Flashloader并解压
通过GDB将 Flashloader/flashloader.elf 下载到内存并执行（步骤同RAM调试步骤，需要跳转程序入口点开始执行。）
将ELF转换为 srec 或 ihx

arm-none-eabi-objcopy -O srec freertos_hello.elf freertos_hello.srec
连接USB OTG1，会有一个新USB HID设备连接到主机
运行下列命令初始化NOR Flash并写入程序

sudo ./blhost -u -V fill-memory 0x2000 0x04 0xc0000006
sudo ./blhost -u -V -t 30000 configure-memory 0x09 0x2000
sudo ./blhost -u -V -t 30000 flash-image ~/freertos_hello.srec erase

根据Flash类型调整第一条命令的值。

Flash 识别状态可以通过如下命令查看。

sudo ./blhost -u -V list-memory

9. 总结

环境是第一步，代码尚未成功，同志仍需努力：）