ねむいさんのぶろぐ

STM32H7を使ってみる7 -ティアリングを何とかしたい-

←前回

なんと4年ぶりのSTM32H7の記事です！
ちなみに最新のSTM32H7R/SシリーズについてはOpenOCDが正式対応して
いないため、当面の間はSTM32H747I-Discoveryを使用した記事となります…
~~お前アリアハンから全然脱出できてないじゃないか！１！！~~

さて、ねむいさんが公開しているFatFs移植サンプル通称"いつもの"に
ついてはChaN師のFatFsのほかに簡易ファイラーやtxt(S-JISのみ)ファイル、
さらに独自フォーマットの動画ファイルも対応しております。

それでSTM32H747I-DISCOはDSIインターフェースでLTDCを動作させて
映像を出力しているのですが、素早く画面切り替えた際や動画再生時などに
画面のティアリングが発生してしまっておりました。

例としてゼERO動画を再生しているところ

赤色で線引いて強調してみましたが横方向のティアリングの上に斜め方向
にもティアリングが発生してしまっている状態です。

横方向のティアリングはLTDCのVSYNCを待つようにしたら解消しました。
具体的なコードは下記のようなコードをDMA2Dでぶん投げる前に挿入すれば
解決です。

/**************************************************************************/

/*! 

   Wait VSYNC signal.

*/

/**************************************************************************/

void Display_WaitVSYNC(void)

{

	/* reload shadow registers on vertical blanking period */

	LTDC->SRCR = LTDC_SRCR_VBR;

	/* wait for next frame */

	while ((LTDC->CDSR & LTDC_CDSR_VSYNCS) == 0);

}

コード詳細は./lib/display/mcu_depend/src/lcdc_if_basis.cと
./lib/display/abstract/src/ts_fileloads.cを参考にしてください。

しかし、斜め方向のティアリングはこれでだけは解消しませんでした…
画面切り替えたときとかの斜め方向のティアリングがどうしても
気になってしまう…

不思議なことに斜めティアリングはDSI接続のLCDモジュールを横方向
(LANDSCAPE)で使用した時だけ発生し、縦方向(PORTRAIT)なら一切発生
しないことに気づきました…いないさんかわいい…

STのフォーラムも調べてみましたが同じ現象に悩んでる方が結構いることが
わかりました
①STM32F769-DISCOを使ってる人
②STM32F469I-DISCOを使ってる人
③ねむいさんとおなじSTM32H747I-DISCOを使ってる人
④STM32F469I-DISCOを使ってる人その２
共通するのはDSIインターフェースのLCDモジュールを横方向で使った際に
斜めティアリングが出ちゃっているようです。
ちなみにねむいさんが所持しているSTM32F769N-Discoveryでも同じ現象が
発生しておりました。

①のところでST社員の人が斜めティアリングが起こる仕組みと対策を示して
おりました。
ねむいさん所持のSTM32H747I-DISCOのTFT-LCDモジュールのコントローラは
OTM8009Aという480x800(MAX864)のWVGAの縦方向表示に特化したやつでした。
横方向にして使用すると原理通りスキャン方向の相違が起こって斜め方向に
ティアリングが発生してしまうということなのでしょうか…

で、原理は納得しましたが具体的な対策(フレームバッファを2分割せよ)
とやらを文字で示していますがソースは提示されておらずねむいさんは
肝心のソースコードを知りたかったので再び泥沼にはまってしまいました。

しかし…

最後の④のところでVerticalBackPorch(VBP)を増やしたら斜めティアリングを
画面の外に蹴りだせたとコメントを見つけ、ねむいさんも真似してやってみた
所確かに斜めティアリングが垂直方向に移動しました。

いろいろ試した結果、VBPの値を480追加すると丁度画面から消えるのが判明し
横方向表示の際の時だけVBPにVBP_OFSとして480を追加するようにしました。

	/* Timing parameters for all Video modes

	* Set Timing parameters of LTDC depending on its chosen orientation

	*/

	/* The following values are same for portrait and landscape orientations */

	if(Orientation == LCD_ORIENTATION_PORTRAIT)

	{

		VSA  = OTM8009A_480X800_VSYNC;		/* 1  */

		VBP  = OTM8009A_480X800_VBP;		/* 15 */

		VFP  = OTM8009A_480X800_VFP;		/* 16 */

		HSA  = OTM8009A_480X800_HSYNC;		/* 2  */

		HBP  = OTM8009A_480X800_HBP;		/* 34 */

		HFP  = OTM8009A_480X800_HFP;		/* 34 */

	}

	else

	{

		/* lcd_orientation == LCD_ORIENTATION_LANDSCAPE */

		VSA  = OTM8009A_800X480_VSYNC;		/* 1  */

		VBP  = VBP_OFS + OTM8009A_800X480_VBP;		/* 15(+480) */

		VFP  = OTM8009A_800X480_VFP;		/* 16 */

		HSA  = OTM8009A_800X480_HSYNC;		/* 2  */

		HBP  = OTM8009A_800X480_HBP;		/* 34 */

		HFP  = OTM8009A_800X480_HFP;		/* 34 */

	}

…コメント先ではNT35510のLCDモジュールではうまくいかなかったという
結果でしたがねむいさんがもってるOTM8009Aの奴は対策できたっぽいので
まぁワークアラウンドとしてはいいのかな…と思いまし、た！

DSI接続のLCDモジュールがあるDiscovery系ボードをお持ちで同じような
問題抱えてる方は追試していただけたら幸いです…！！

おきぱのSTM32H7,STM32F7のサンプルはワークアラウンド済です。

STM32U0はぢめました

買ってから3か月以上たってしまいましたがまだ私が国内一番乗りかな！？
STM32L0の省電力性をさらに高めてなおかつパフォーマンスも妥協しない
新シリーズとしてSTM32U0が登場しました。

MCUの拡大写真です。
パッケージに二次元バーコードがついていて時代の流れを感じさせますね。

STM32U0シリーズは現在STM32U031x,STM32U73x,STM32U83xの3種がライン
ナップされておりますがねむいさんはフラッシュ容量最大のSTM32U083RCT6を
搭載したNUCLEO-U083RCを購入しました。

STLink部分はSTLinkV2-1相当ですがコネクタがUSB-TypeCとなってますね。

また、STLinkを電気的に切り離し外部からデバッガ接続できる構造になって
いますが2mmピッチの独自14ピンコネクタなのはちょっと扱いづらいです…
これは完全にSTLinkV3-MINIEを接続することを意識したものでしょうか？

まぁNUCLEO基板搭載のSTLinkV2で十分事足りるので外部デバッガの登場は
ないと思います。

●ところで肝心のOpenOCDの対応状況は？
御多忙にもれず未だ誰も触れてない理由としてはOpenOCDがまだSTM32U0
のフラッシュ書き込みに正式対応してないことにあると思います。

ちなみにgerritにパッチは上がっておりますが現在パッチ自身に不備が
あって普通にあてただけだとビルドエラーになります…F**K!!!!
そしてそのままずっと放置されております…おいおい

というわけでねむいさんサイドでちょっと手直ししてU0シリーズにも
対応させてみました。ドライバの分類としてはSTM32G0,STM32C0と同じく
STM32L4のグループに属するようですね。
STM32U0対応のOpenOCDダウンロードはこちらからどうぞ！

上記OpenOCDのバイナリには収録しておりますが、フラッシュ書き込みや
デバッグの基底となるstm32u0.cfgも存在してなかったので今回作って
収録しております。

# SPDX-License-Identifier: GPL-2.0-or-later



# script for stm32u0x family

#

# stm32u0 devices support SWD transports only.

#



source [find target/swj-dp.tcl]

source [find mem_helper.tcl]



if { [info exists CHIPNAME] } {

	set _CHIPNAME $CHIPNAME

} else {

	set _CHIPNAME stm32u0x

}



set _ENDIAN little



# Work-area is a space in RAM used for flash programming

# By default use 6kB

if { [info exists WORKAREASIZE] } {

   set _WORKAREASIZE $WORKAREASIZE

} else {

   set _WORKAREASIZE 0x1800

}



#jtag scan chain

if { [info exists CPUTAPID] } {

   set _CPUTAPID $CPUTAPID

} else {

   # SWD IDCODE (single drop, arm)

   set _CPUTAPID 0x0bc11477

}



swj_newdap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID

dap create $_CHIPNAME.dap -chain-position $_CHIPNAME.cpu



set _TARGETNAME $_CHIPNAME.cpu

target create $_TARGETNAME cortex_m -endian $_ENDIAN -dap $_CHIPNAME.dap



$_TARGETNAME configure -work-area-phys 0x20000000 -work-area-size $_WORKAREASIZE -work-area-backup 0



flash bank $_CHIPNAME.flash stm32l4x 0x08000000 0 0 0 $_TARGETNAME

flash bank $_CHIPNAME.otp   stm32l4x 0x1fff6800 0 0 0 $_TARGETNAME



# reasonable default

adapter speed 2000



adapter srst delay 100

if {[using_jtag]} {

	jtag_ntrst_delay 100

}



reset_config srst_nogate



if {![using_hla]} {

	# if srst is not fitted use SYSRESETREQ to

	# perform a soft reset

	cortex_m reset_config sysresetreq

}



$_TARGETNAME configure -event examine-end {

	# Enable DBGMCU clock

	# RCC_DBGCFGR |= DBGEN

	mmw 0x40021050 0x00000001 0



	# Enable debug during low power modes (uses more power)

	# DBGMCU_CR |= DBG_STANDBY | DBG_STOP

	mmw 0x40015804 0x0000000C 0



	# Stop watchdog counters during halt

	# DBGMCU_APB1_FZR |= DBG_IWDG_STOP | DBG_WWDG_STOP

	mmw 0x40015808 0x00001800 0

}

へルパーcfgのstm32u0_swd_flash.cfgはこんな感じです。

# script for stm32u0x with flash programming

# Nemuisan's Special





source [find target/stm32u0x.cfg]

$_TARGETNAME configure -work-area-phys 0x20000000 -work-area-size $_WORKAREASIZE -work-area-backup 0 



proc mt_flash {IMGFILE} {

	flash write_image erase $IMGFILE

	verify_image $IMGFILE

	reset run

	shutdown

}



proc mt_flash_bin {IMGFILE OFFSET}  {

	flash write_image erase $IMGFILE $OFFSET bin

	verify_image $IMGFILE $OFFSET

	reset run

	shutdown

}



proc mt_flash_hex {IMGFILE}  {

	flash write_image erase $IMGFILE 0 ihex

	verify_image $IMGFILE 0

	reset run

	shutdown

}



proc eraser {}  {

	stm32g0x mass_erase 0

	flash erase_check 0

	shutdown

}



#debug_level 3

#reset_config srst_only srst_nogate connect_assert_srst

reset_config none

adapter speed 500

gdb_target_description enable

init

reset init

それらを使って書き込んでみたところのログはこんな感じです。

> "C:¥Devz¥Coreutils¥bin¥make.exe" program

openocd  -s C:/Devz/ARM/OCD/tcl -f interface/stlink-dap.cfg -c "transport select dapdirect_swd" -f target/stm32u0x_swd_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.12.0+dev-00658-g6554d176e (2024-07-21-10:18)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.org/doc/doxygen/bugs.html

dapdirect_swd

DEPRECATED! use 'gdb target_description', not 'gdb_target_description'

Info : STLINK V2J45M30 (API v2) VID:PID 0483:3752

Info : Target voltage: 3.236554

Info : Unable to match requested speed 500 kHz, using 480 kHz

Info : Unable to match requested speed 500 kHz, using 480 kHz

Info : clock speed 480 kHz

Info : stlink_dap_op_connect(connect)

Info : SWD DPIDR 0x6ba02477

Info : [stm32u0x.cpu] Cortex-M0+ r0p1 processor detected

Info : [stm32u0x.cpu] target has 4 breakpoints, 2 watchpoints

Info : [stm32u0x.cpu] Examination succeed

Info : [stm32u0x.cpu] starting gdb server on 3333

Info : Listening on port 3333 for gdb connections

[stm32u0x.cpu] halted due to breakpoint, current mode: Thread 

xPSR: 0xf1000000 pc: 0x08002b30 msp: 0x2000a000

Info : device idcode = 0x10006489 (STM32U07/U08xx - Rev A : 0x1000)

Info : RDP level 0 (0xAA)

Info : flash size = 256 KiB

Info : flash mode : single-bank

Info : Padding image section 1 at 0x08008004 with 4 bytes (bank write end alignment)

Warn : Adding extra erase range, 0x08008008 .. 0x080087ff

Info : wrote 32776 bytes from file main.elf in 1.595168s (20.065 KiB/s)

Info : verified 32772 bytes in 0.780823s (40.987 KiB/s)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:03

もちろんデバッグも自由自在です。U0シリーズの要であるスリープ時
等からの接続デバッグにも対応したつもりですが人柱お願いします…

●実際に動くものを作ってみよう
使い勝手としましてはSTM32G0,STM32C0とほぼ同じなので移植もあっさり
できちゃいました。

NUCLEO基板で定番となったI2Cを使用したセンサとOLEDの表示ルーチンを
サクッとこしらえてみました。なお、STM32U0は最大動作周波数56MHzで
動作しますが48MHz動作のほうが潰しがきくのでお勧めです。
私の作例では48MHz動作としております。

●ちょっとした注意
STM32U0は徹底した低電力性を唱えておりますので初期状態でほとんどの
モジュールにクロックが供給されておりません。

ねむいさんもうっかり嵌ってしまいましたがU0ではDBGMCUのクロックが
初期状態で供給されておりませんのでMCUのリビジョンをやIDを取りたい
場合は下記の要領でクロックを有効にしてやりましょう。

#if defined(USE_STM32U083RC_NUCLEO)

	/* STM32U0 DeviceID & Revision Detection */

	char mcurev;

	__HAL_RCC_DBGMCU_CLK_ENABLE(); // <- これ

	uint16_t revid = HAL_GetREVID();

	uint16_t devid = 0x0FFF & HAL_GetDEVID();

    if     (revid == 0x1001) mcurev = 'Z';

	else		/* 0x1000 */ mcurev = 'A';

	printf("STM32U0xx DevID 0x%04x Rev.%c¥n",devid,mcurev);

	printf("STM32U0xx UID 0x%08lx%08lx%08lx¥n",HAL_GetUIDw2(),HAL_GetUIDw1(),HAL_GetUIDw0());

	printf("¥n");

#endif

OpenOCDでは上でも述べましたがcfgファイル内で接続した瞬間にDBGMCUの
クロックを有効にするように仕込んでますので安心です(人柱求む)。

というわけでSTM32U0という新しいラインナップが加わったわけですが、
U0はL0シリーズの後継という位置づけのようなので市場もL0からU0へと
次第に置き換わっていくこととなるでしょう。
STM32も世代を重ねて着実に進化していくので楽しみです。

STM32H5を使ってみる6 -秋月販売記念!SDMMCとFatFsでSDカードを使う-

秋月さんからついにNUCLEO-H563ZIが販売となりました！！！
これで皆様も気軽にSTM32H5をいじることができるでしょう～！

ちなみにSTM32H5に対応したOpenOCDはねむいさんのぶろぐで公開
しておりますのでどしどしご利用ください！！！！
そうだね宣伝だね！！

あ、それと買った人チップリビジョンちゃんと確認してくださいね…
Zならはずれです…

●STM32H5のSDMMC
そんなわけで今回はSTM32H5のSDMMC機能を利用してFatFsを移植し
SDカードやMMC/eMMCからデータの読み書きを行うところまでを
紹介します。

STM32H5のSDMMCにはSTM32H7と同じくIDMAというGPDMAから独立した
DMAが存在しており、GPDMAと干渉することなく運用が可能です。

また、STM32H5は外部メモリ(FSMC/OCTO-SPI)にしかDキャッシュが
かかわってこないためキャッシュコントロールの面倒さもありません。

●STM32H5では公式にFatFsの移植例がないが…
STM32H5以降はMicrosoft Azure RTOSに入れ込んでおりFatFsではなく
FILEXなるソフトウエアライブラリに置き変わっておりました。

ねむいさんは慣れ親しんだFatFs以外の選択肢はないのでFILEXはガン
無視のザ・シカトで移植に挑みました。

移植についてですがSTM32F7のころから慣れ親しんだいわば"枯れた"
ペリフェラルなのでHALの構造も酷似しているためSTM32H7やSTM32L5の
移植例からI/Oとクロック設定以外はほぼスライド移植で簡単にできて
しまいました！

f_readの結合関数SD_read()はこんな感じです。

DRESULT SD_read(BYTE lun, BYTE *buff, DWORD sector, UINT count)

{

	DRESULT res = RES_OK;

    uint32_t timer = SysTick->VAL + SD_DATATIMEOUT;



    /* first ensure the SDCard is ready for a new operation */

    while((SD_GetCardState() == SD_TRANSFER_BUSY))

    {

		if(timer < SysTick->VAL)

		return RES_NOTRDY;

    }



#if defined(SD_DMA_MODE) && !defined(SD_POLLING_MODE)



	if((uintptr_t)buff & 0x3)	/* Check 4Byte Alignment */

	{	/* Unaligned Buffer Address Case (Slower) */

		for (unsigned int secNum = 0; secNum < count ; secNum++){



			if(SD_ReadBlocks_DMA((uint32_t*)dmabuf, (uint32_t)(sector+secNum), 1)!= MSD_OK)

			{

				MSG_PRINTF("Read error on unaligned buffer¥n");

				res = RES_ERROR;

			}



			memcpy(buff+secNum*SECTOR_SIZE, dmabuf, SECTOR_SIZE);

		}

	} else {

		/* Aligned Buffer Address Case (Faster) */

		if(SD_ReadBlocks_DMA((uint32_t*)buff, (uint32_t)sector, count) != MSD_OK)

		{

			MSG_PRINTF("Read error on DMA¥n");

			res = RES_ERROR;

		}

	}

#else

	if(SD_ReadBlocks((uint32_t*)buff, (uint32_t)sector, count) != MSD_OK)

	{

		MSG_PRINTF("Read error on polling¥n");

		res = RES_ERROR;

	}

#endif

	return res;

}

f_writeの結合関数SD_write()はこんな感じです。

DRESULT SD_write(BYTE lun, const BYTE *buff, DWORD sector, UINT count)

{

	DRESULT res = RES_ERROR;

    uint32_t timer;





#if defined(SD_DMA_MODE) && !defined(SD_POLLING_MODE)

	if((uintptr_t)buff & 0x3)	/* Check 4Byte Alignment */

	{	/* Unaligned Buffer Address Case (Slower) */

		for (unsigned int secNum = 0; secNum < count; secNum++){



			memcpy(dmabuf, buff+(SECTOR_SIZE*secNum), SECTOR_SIZE);



			if(SD_WriteBlocks_DMA((uint32_t*)dmabuf, (uint32_t)(sector+secNum), 1) != MSD_OK)

			{

				MSG_PRINTF("Write error on unaligned buffer¥n");

				res = RES_ERROR;

			}

		}

	} else {

		if(SD_WriteBlocks_DMA((uint32_t*)buff, (uint32_t)sector, count) != MSD_OK)

		{

			MSG_PRINTF("Write error on DMA¥n");

			res = RES_ERROR;

		}

	}

#else

	if(SD_WriteBlocks((uint32_t*)buff, (uint32_t)sector, count) != MSD_OK)

	{

		MSG_PRINTF("Write error on polling¥n");

		res = RES_ERROR;

	}



#endif



	/* ensure the SDCard is ready for a next operation */

	timer = SysTick->VAL + SD_DATATIMEOUT;

	res = RES_ERROR; /* Timeout */

	/* block until SDIO IP is ready or a timeout occur */

	while(timer > SysTick->VAL)

	{

		if(SD_GetCardState() == SD_TRANSFER_OK)

		{

			res = RES_OK;

			break;

		}

	}



	return res;

}

キャッシュコントロールがないのですっきりですね。
全体的なソースの詳細についてはねむいさんのSTM32H5プロジェクト内の
下記ディレクトリのファイルを参照してください。
./lib/ff/sdmmc_stm32h5.c
./lib/ff/sdmmc_stm32h5.h

●直線リードのパフォーマンスはどんな感じか
STM32H5の最大クロックは250MHz取れるのでSDMMCのクロック周波数も
250/5=50MHzとハイスピードの規格いっぱいの50MHzでぶん回すことが
可能です。

直線の読み出しスピードは19MBytes/Sec出てますね。
こんだけあれば十分でしょう。

ちなみにeMMCでは3.3VでDDRモードに対応しており、STM32H5のSDMMCも
DDRに対応しているのでSDカードを超えた早い読み出しが可能です！！

●SMART取得機能も搭載

ねむいさんはSMARTが取れる産業用/工業用SDカードが大好きですが
STM32H5でももちろんSMARTの取得を可能としてます！
試される際は上記のコードをコメントアウトしてくださいね～

SMART対応のSDカードについては下記記事もご参照ください！
・DELKIN製SDカード
・TRANSCEND製microSDカード

そんなわけでかなりやっけつ気味にSTM32H5へのSDMMCを使ったFatFs
の移植を紹介しましたがそれらを組み込んだ総合的な成果物は昨年
からすでにおきぱで公開しておりますのでどしどし参考にしてください！

STM32H5を使ってみる5 -普通のSPIをDMAと交えて使う-

20240516追:
秋月さんよりNUCLEO-H563ZI販売開始です！！
20240516追:

初めてSTM32H5を触った時も述べましたが、L5と比べてSPIやDMAの扱いが
ちょっと癖があって違います。今回はその使い方の一例を紹介します。
なお、ねむいさんのSTM32H5のプロジェクトではSPIをシリアル接続の
TFT-LCD(ST7789V2コントローラIC)で使用しております。

●コード解説(基本設定編)
以下はねむいさんのSTM32H563ZI-NUCLEO向けのプロジェクト中の
./lib/display/mcu_depend/src/display_if_basis.cを解説していきます。
./lib/display/mcu_depend/inc/display_if_basis.hも参照のこと。

Display_IoInit_If()内でハードウエアSPIからDMAの設定までやっちゃって
ますが少しずつ分解していきます。

まずはI/Oの設定です。

	GPIO_InitTypeDef GPIO_InitStructure = {0};

	RCC_PeriphCLKInitTypeDef PeriphClkInitStruct = {0};

	

	/* Enable CTRL line GPIO settings */

	DISPLAY_GPIOCLK_EN(DISPLAY_CLK_RES);

	DISPLAY_GPIOCLK_EN(DISPLAY_CLK_CS);

	DISPLAY_GPIOCLK_EN(DISPLAY_CLK_DC);

	DISPLAY_GPIOCLK_EN(DISPLAY_CLK_SCK);

	DISPLAY_GPIOCLK_EN(DISPLAY_CLK_SDI);

	DISPLAY_GPIOCLK_EN(DISPLAY_CLK_SDO);



	GPIO_InitStructure.Pin 			= CTRL_RES;

	GPIO_InitStructure.Mode 		= GPIO_MODE_OUTPUT_PP;

	GPIO_InitStructure.Pull 		= GPIO_NOPULL;

	GPIO_InitStructure.Speed 		= GPIO_SPEED_FREQ_VERY_HIGH;

	GPIO_InitStructure.Alternate 	= 0;

	HAL_GPIO_Init(DISPLAY_PORT_RES, &GPIO_InitStructure);



	GPIO_InitStructure.Pin 			 = CTRL_CS;

	HAL_GPIO_Init(DISPLAY_PORT_CS, &GPIO_InitStructure);

	GPIO_InitStructure.Pin 			 = CTRL_DC;

	HAL_GPIO_Init(DISPLAY_PORT_DC, &GPIO_InitStructure);



	/* Set peripheral clock */

    PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_SPI1;

    PeriphClkInitStruct.Spi1ClockSelection   = RCC_SPI1CLKSOURCE_PLL1Q;

    if (HAL_RCCEx_PeriphCLKConfig(&PeriphClkInitStruct) != HAL_OK)

    {

		for(;;){

			__NOP();

		}

    }

	DISPLAY_PERIF_CLK(ENABLE);



	/* Connect SPI pins to aletenate function */  

	GPIO_InitStructure.Mode 		= GPIO_MODE_AF_PP;

	GPIO_InitStructure.Pull 		= GPIO_NOPULL;

	GPIO_InitStructure.Speed 		= GPIO_SPEED_FREQ_VERY_HIGH;



	/* SPI SCK pin configuration */

	GPIO_InitStructure.Pin 			= CTRL_SCK;

	GPIO_InitStructure.Alternate 	= SRC_SCK;

	HAL_GPIO_Init(DISPLAY_PORT_SCK, &GPIO_InitStructure);



	/* SPI MOSI pin configuration */

	GPIO_InitStructure.Pin 			= CTRL_SDI;

	GPIO_InitStructure.Alternate 	= SRC_SDI;

	HAL_GPIO_Init(DISPLAY_PORT_SDI, &GPIO_InitStructure);



	/* SPI MISO pin configuration */

	GPIO_InitStructure.Pin 			= CTRL_SDO;

	GPIO_InitStructure.Alternate 	= SRC_SDO;

	HAL_GPIO_Init(DISPLAY_PORT_SDO, &GPIO_InitStructure);

SCK,MOSI,MISOはAlternateFunctionとして、RESET・CS・DCはGPIOとして
設定します。

お次はSPIモジュールの設定です。

	/* SPI configuration */

	SpiHandle.Instance               		= LCD_SPI;

	SpiHandle.Init.Mode 			 		= SPI_MODE_MASTER;

	SpiHandle.Init.Direction 				= SPI_DIRECTION_2LINES;

	SpiHandle.Init.DataSize 		 		= SPI_DATASIZE_8BIT;

	SpiHandle.Init.CLKPolarity 				= SPI_POLARITY_HIGH;

	SpiHandle.Init.CLKPhase 		 		= SPI_PHASE_2EDGE;

	SpiHandle.Init.NSS 				 		= SPI_NSS_SOFT;

	SpiHandle.Init.BaudRatePrescaler 		= SPI_BaudPrescale;

	SpiHandle.Init.FirstBit 		 		= SPI_FIRSTBIT_MSB;

	SpiHandle.Init.TIMode 					= SPI_TIMODE_DISABLE;

	SpiHandle.Init.CRCCalculation 			= SPI_CRCCALCULATION_DISABLE;

	SpiHandle.Init.CRCPolynomial 			= 0x7;

	SpiHandle.Init.CRCLength            	= SPI_CRC_LENGTH_8BIT;

	SpiHandle.Init.NSSPMode 				= SPI_NSS_PULSE_DISABLE;

	SpiHandle.Init.NSSPolarity 				= SPI_NSS_POLARITY_LOW;

	SpiHandle.Init.FifoThreshold 			= SPI_FIFO_THRESHOLD_01DATA;

	SpiHandle.Init.MasterSSIdleness 		= SPI_MASTER_SS_IDLENESS_00CYCLE;

	SpiHandle.Init.MasterInterDataIdleness 	= SPI_MASTER_INTERDATA_IDLENESS_00CYCLE;

	SpiHandle.Init.MasterReceiverAutoSusp  	= SPI_MASTER_RX_AUTOSUSP_DISABLE;

	SpiHandle.Init.MasterKeepIOState 	   	= SPI_MASTER_KEEP_IO_STATE_ENABLE; /* avoid glitch */

	SpiHandle.Init.IOSwap 				   	= SPI_IO_SWAP_DISABLE;

	SpiHandle.Init.ReadyMasterManagement   	= SPI_RDY_MASTER_MANAGEMENT_INTERNALLY;

	SpiHandle.Init.ReadyPolarity 			= SPI_RDY_POLARITY_HIGH;

	if(HAL_SPI_Init(&SpiHandle) != HAL_OK)

	{

		/* Capture error */ 

		while (1);

	}



	/* Enable SPI module */

	LCD_SPI->CR1 |= SPI_CR1_SPE;

	LCD_SPI->CR1 |= SPI_CR1_CSTART;

HAL_SPI_Init()が完了したらCR1レジスタのSPEとCSTARTビットを1にして
SPIモジュールをスタート状態にさせるのがミソです。

設定中で

SpiHandle.Init.BaudRatePrescaler 		= SPI_BaudPrescale;

ですが

#define SPI_BaudPrescale	SPI_BAUDRATEPRESCALER_4 /* PLL1Q CLK 100MHz/4 = 25MHz */

とdefineしております。SPIのクロックは25MHzとしてます。
~~ST7789V2の許容クロックを大幅に逸脱してる気がしますが気のせいです！~~
20240502追:
ST7789V2のSCLのクロック最大値ちゃんと調べたらなんと60MHzでした！！！
全然余裕でしたすみません！！！！！
20240502追:

そしてDMAの設定です…これが一番苦労しました。

	/* DMA controller clock enable */

	__HAL_RCC_GPDMA1_CLK_ENABLE();

	

	/* DMA interrupt init */

	/* SPILCD_DMA_IRQn interrupt configuration */

	HAL_NVIC_SetPriority(SPILCD_DMA_IRQn, 3, 0);

	HAL_NVIC_EnableIRQ(SPILCD_DMA_IRQn);

	

	/* Configure DMA request LcdDmaHandle */

	LcdDmaHandle.Instance 					= SPILCD_DMA_CHANNEL;

    LcdDmaHandle.Init.Request 				= SPILCD_DMA_REQEST;

    LcdDmaHandle.Init.BlkHWRequest 			= DMA_BREQ_SINGLE_BURST;

    LcdDmaHandle.Init.Direction 			= DMA_MEMORY_TO_PERIPH;

    LcdDmaHandle.Init.SrcInc 				= DMA_SINC_INCREMENTED;

    LcdDmaHandle.Init.DestInc 				= DMA_DINC_FIXED;

    LcdDmaHandle.Init.SrcDataWidth 			= DMA_SRC_DATAWIDTH_BYTE;

    LcdDmaHandle.Init.DestDataWidth 		= DMA_DEST_DATAWIDTH_BYTE;

    LcdDmaHandle.Init.Priority 				= DMA_LOW_PRIORITY_HIGH_WEIGHT;

    LcdDmaHandle.Init.SrcBurstLength 		= 1;

    LcdDmaHandle.Init.DestBurstLength 		= 1;

    LcdDmaHandle.Init.TransferAllocatedPort = DMA_SRC_ALLOCATED_PORT0|DMA_DEST_ALLOCATED_PORT0;

    LcdDmaHandle.Init.TransferEventMode 	= DMA_TCEM_BLOCK_TRANSFER;

    LcdDmaHandle.Init.Mode 					= DMA_NORMAL;

    if (HAL_DMA_Init(&LcdDmaHandle) != HAL_OK)

    {

		for(;;){

			__NOP();

		}

    }

	__HAL_LINKDMA(&SpiHandle,hdmatx,LcdDmaHandle);



    if (HAL_DMA_ConfigChannelAttributes(&LcdDmaHandle, DMA_CHANNEL_NPRIV) != HAL_OK)

    {

		for(;;){

			__NOP();

		}

    }



	/* SPI interrupt init */

	/* SPILCD_IRQn interrupt configuration */

	HAL_NVIC_SetPriority(SPILCD_IRQn, 3, 1);

	HAL_NVIC_EnableIRQ(SPILCD_IRQn);

今回はTFT-LCDに向けてひたすらデータをバイト単位でぶん投げるので

    LcdDmaHandle.Init.Direction 			= DMA_MEMORY_TO_PERIPH;

    LcdDmaHandle.Init.SrcInc 				= DMA_SINC_INCREMENTED;

    LcdDmaHandle.Init.DestInc 				= DMA_DINC_FIXED;

    LcdDmaHandle.Init.SrcDataWidth 			= DMA_SRC_DATAWIDTH_BYTE;

    LcdDmaHandle.Init.DestDataWidth 		= DMA_DEST_DATAWIDTH_BYTE;

の部分が重要です。

そしてなんでかDMAのほかにSPIの割り込みも要求してくるので
DMAの設定の最後にSPIの割り込みも必ず有効にします。

●コード解説(基本データのやり取り編)
SPI接続のTFT-LCDの基本は8bitのデータをやり取りします。
で、STM32H5では8bitデータのやり取りするのに素直にTDRにデータを
放り込んでもまともに送出されないのでちょっと細工する必要があります。

まずは8bit単位でデータをやり取りするためのdefine

#define SPIx_TDR8			*(__IO uint8_t *) ((uint32_t)LCD_SPI+0x20)

#define SPIx_RDR8			*(__IO uint8_t *) ((uint32_t)LCD_SPI+0x30)

☝を利用した送信関数はこちら

inline void SendSPI(uint8_t dat)

{

	/* Send byte through the SPI peripheral */		

	SPIx_TDR8 = dat;

	

	/* Wait to receive a byte */

	while (!(LCD_SPI->SR & (SPI_FLAG_RXP)));



	/* Drain Rx FIFO */

	SPIx_RDR8;

}



inline void SendSPI16(uint16_t dat)

{

	SendSPI((uint8_t)(dat>>8));



	SendSPI((uint8_t)dat);

}

STM32CubeH5のHALドライバの送信関数は異常なまでにオーバーヘッドが大きい
ですが中身を分解して簡略化すると送信はここまでシンプルになります。

さらにST7789V2向けには上記関数を利用してCMD,DATA,GRAM書き込み用に拵えます。

/**************************************************************************/

/*! 

    Write LCD Command.

*/

/**************************************************************************/

inline void ST7789V2_wr_cmd(uint8_t cmd)

{

	ST7789V2_DC_CLR();							/* DC=L		     */

	DISPLAY_ASSART_CS();						/* CS=L		     */

	

	SendSPI(cmd);



	DISPLAY_NEGATE_CS();						/* CS=H		     */

	ST7789V2_DC_SET();							/* DC=H		     */

}	



/**************************************************************************/

/*! 

    Write LCD Data and GRAM.

*/

/**************************************************************************/

inline void ST7789V2_wr_dat(uint8_t dat)

{

	DISPLAY_ASSART_CS();						/* CS=L		     */

	

	SendSPI(dat);



	DISPLAY_NEGATE_CS();						/* CS=H		     */

}



/**************************************************************************/

/*! 

    Write LCD GRAM.

*/

/**************************************************************************/

inline void ST7789V2_wr_gram(uint16_t gram)

{

	DISPLAY_ASSART_CS();						/* CS=L		     */

	

	SendSPI16(gram);



	DISPLAY_NEGATE_CS();						/* CS=H		     */

}

一応Readも実装しておりますが以前も解説しておりますので今回は割愛します。

●コード解説(DMAでぶん投げる編)
これが一番難しいです…HALドライバの作例はLinkListを使用した複雑な
DMA転送しかコード例がなくてシンプルなDMAのコード例がなく作りこみに
非常に苦労しました…が、何とかなりました。

まずはHALライブラリのDMA,SPIのIRQハンドラを定義します。

/* DMA IRQ Handler */

void SPILCD_DMA_HANDLER(void)

{

	HAL_DMA_IRQHandler(&LcdDmaHandle);

}

/* SPI IRQ Handler */

void SPILCD_IRQHandler(void)

{

	HAL_SPI_IRQHandler(&SpiHandle);

}

そんでもって今回はSend専用なのでSPIの割り込みでTx完了のコールバック
関数を定義します。

/* SPI-DMA IRQ Callback */

void HAL_SPI_TxCpltCallback(SPI_HandleTypeDef *hspi)

{

	if(hspi->Instance == LCD_SPI){

		wTransferState = TRANSFER_COMPLETE;

	}

}

STM32L5の場合はSPIの割り込みが必要なかったのですが、H5では割り込み
必須になっていやがります…！なお、STM32H7も同じくDMA転送にSPIの
割り込み設定が必須です(使ってなかったから今まで知らんかった…)。

実際のDMA転送関数はこちらになります。

/* DMA transaction */

void lcd_dma_transfer(const uint8_t *buff,unsigned int count)

{

	/* Disable SPI to change register */

	LCD_SPI->CR1 &= ~(SPI_CR1_SPE);

	

	/* Start DMA */

	if (HAL_SPI_Transmit_DMA(&SpiHandle, buff, count) != HAL_OK)

	{

		for(;;){

			__NOP();

		}

	}

	

	/* Wait transfer complete */

	while (wTransferState == TRANSFER_WAIT) {};

	

	/* Restore transfer state */

	wTransferState = TRANSFER_WAIT;

	

	/* Restore nomal transfer settings */

	LCD_SPI->CR2  = 0;						/* Restore TSIZE */

	LCD_SPI->CFG2 &= ~(SPI_CFG2_COMM_Msk);	/* Restore FULL duplex mode */

	LCD_SPI->CR1 |= SPI_CR1_SPE;			/* Re-enable SPI module */

	LCD_SPI->CR1 |= SPI_CR1_CSTART;			/* Re-start SPI Trasfer ready */

}

転送の手順は
①SPIモジュールをDisable
②HAL_SPI_Transmit_DMAを実行
③SPIのコールバック関数が転送完了を捕まえるまで待つ
④次の転送の準備を設定
となります。

特に④の下記コードに相当する後処理は超重要です！！

/* Restore nomal transfer settings */

	LCD_SPI->CR2  = 0;						/* Restore TSIZE */

	LCD_SPI->CFG2 &= ~(SPI_CFG2_COMM_Msk);	/* Restore FULL duplex mode */

	LCD_SPI->CR1 |= SPI_CR1_SPE;			/* Re-enable SPI module */

	LCD_SPI->CR1 |= SPI_CR1_CSTART;			/* Re-start SPI Trasfer ready */

これをやっておかないと通常転送ができなくなるので必ず
後処理はは忘れずに！！どれが欠けても動かなくなります。

こんなわけでかなり癖があるSTM32H5のSPIをDMAと交えて使用してみました。
今回は8bitSPI接続のTFT-LCD接続に特化したコードの紹介となりましたが、
繋がるSPIデバイスの特性よって設定はかなり変わりますのでそれぞれで
試行錯誤が必要となるでしょう…
…正直OCTO-SPIやSDMMCとかより動かすのしんどかった…。

STM32H5を使ってみる4 -STM32L5の時みたいにOCTO-SPIを使ってみる-

20240516追:
秋月さんよりNUCLEO-H563ZI販売開始です！！
20240516追:

つい最近、STM32H7シリーズにSTM32H7R/Sというかなり尖った品種が
追加されましたが思い出したようにSTM32H5を触っていこうと思います。

20240321追:
STM32U0シリーズなんてのも出現してました…！！
20240321追:

今回もSTM32H563ZI-NUCLEOを使用したFatFsの移植デモのソースコードを
使用して解説していきます。

●STM32L5から進化したSTM32H5のOCTO-SPI
STM32H5のOCTO-SPIはポピュラーなQUADSPI-ROMだけではなく、最大
16bitなクロックドシリアルROM/PSRAMなんかも接続可能で、もちろん
メモリマップドなアクセスが可能となっております。
シリアルなのに16bitもパラレルってなんなんだよと常に感じてますが
時代は常に進化していっているなと同じく感じております(混乱)。
sirius506さんはそんなOCTO-SPIを完全に使いこなしDOOMというゲームを
移植されており、ほんとに感心してしまいました…

ねむいさんは組み込み系界隈の中では雑魚キャラに過ぎないのでそんな
高度なことはできず、基本中の基本のQSPI-ROMを接続してメモリ
マップドモードで読み出し専用で動かすことからやってきます。

OCTO-SPIについてはST公式のAN5050もしっかり熟読してください。

●STM32H5のOCTO-SPIをメモリマップドモードで動かすコード
移植に当たってはSTM32L5のやつをそのままスライド移植…というわけには
簡単にいかず、L5のOCTO-SPIのコードから少し改変が必要でした。

その前に、STM32H563ZI-NUCLEOでOCTO-SPIを使う際はSB70をジャンパして
PE2(COTO-SPI IO2)を外部に引き出せられるようにするのを忘れないで
くださいね。

それではSTM32H5のOCTO-SPIのメモリマップドモードで使うためのコードを
紹介します。まずはI/O

/**************************************************************************/

/*! 

    @brief	OCTO-SPI GPIO Configuration.

	@param	None.

    @retval	None.

*/

/**************************************************************************/

void OSPI_IoInit_If(void)

{

	GPIO_InitTypeDef GPIO_InitStruct = {0};

	RCC_PeriphCLKInitTypeDef PeriphClkInit = {0};



	/* Initializes the peripherals clock */

	PeriphClkInit.PeriphClockSelection 	= RCC_PERIPHCLK_OSPI;

	PeriphClkInit.OspiClockSelection 	= RCC_OSPICLKSOURCE_HCLK;

	if (HAL_RCCEx_PeriphCLKConfig(&PeriphClkInit) != HAL_OK)

	{

		for(;;);

	}

	

	/* Peripheral clock enable */

	__HAL_RCC_OSPI1_CLK_ENABLE();

	

	/* Alternate GPIO enable */

	__HAL_RCC_GPIOB_CLK_ENABLE();

	__HAL_RCC_GPIOD_CLK_ENABLE();

	__HAL_RCC_GPIOE_CLK_ENABLE();

	__HAL_RCC_GPIOG_CLK_ENABLE();



	/* PD11 as OSPI_IO0 */

	GPIO_InitStruct.Pin 		= GPIO_PIN_11;

	GPIO_InitStruct.Mode 		= GPIO_MODE_AF_PP;

	GPIO_InitStruct.Pull 		= GPIO_NOPULL;

	GPIO_InitStruct.Speed 		= GPIO_SPEED_FREQ_VERY_HIGH;

	GPIO_InitStruct.Alternate   = GPIO_AF9_OCTOSPI1;

	HAL_GPIO_Init(GPIOD, &GPIO_InitStruct);



	/* PD12 as OSPI_IO1 */

	GPIO_InitStruct.Pin 		= GPIO_PIN_12;

	GPIO_InitStruct.Alternate   = GPIO_AF9_OCTOSPI1;

	HAL_GPIO_Init(GPIOD, &GPIO_InitStruct);



	/* PE2 as OSPI_IO2(Need SB70 SolderBridge) */

	GPIO_InitStruct.Pin 		= GPIO_PIN_2;

	GPIO_InitStruct.Alternate   = GPIO_AF9_OCTOSPI1;

	HAL_GPIO_Init(GPIOE, &GPIO_InitStruct);



	/* PD13 as OSPI_IO3 */

	GPIO_InitStruct.Pin 		= GPIO_PIN_13;

	GPIO_InitStruct.Alternate   = GPIO_AF9_OCTOSPI1;

	HAL_GPIO_Init(GPIOD, &GPIO_InitStruct);

	

	/* PB2 as OSPI_CLK */

	GPIO_InitStruct.Pin		 	= GPIO_PIN_2;

	GPIO_InitStruct.Alternate   = GPIO_AF9_OCTOSPI1;

	HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);

	

	/* PG6 as OSPI_NCS */

	GPIO_InitStruct.Pin 		= GPIO_PIN_6;

	GPIO_InitStruct.Alternate   = GPIO_AF10_OCTOSPI1;

	HAL_GPIO_Init(GPIOG, &GPIO_InitStruct);

}

お次はOCTO-SPIのメモリマップドモードの初期化です。

/**************************************************************************/

/*! 

    @brief	Configure OCTO-SPI as Memory Mapped Mode.

			Winbond W25Q128JVSIQ specific setting.

			* Address size is 24bit(16MBytes).

			* Initially sets QUAD-MODE(not need quadmode command).

			* MAX 133MHz CLK.

			* Support "XIP",thus suitable for MemoryMappedMode.

	@param	None.

    @retval	None.

*/

/**************************************************************************/

void Set_OSPI_MemoryMappedMode(void)

{

	XSPI_RegularCmdTypeDef sCommand = {0};

	XSPI_MemoryMappedTypeDef sMemMappedCfg = {0};

	uint8_t reg_data =0;

	

	/* Initialize OCTO-SPI I/O */

	OSPI_IoInit_If();

	

	/* Initialize OCTO-SPI */

	hxspi.Instance 						= OCTOSPI1;

	hxspi.Init.FifoThresholdByte 		= 1;

	hxspi.Init.MemoryMode 				= HAL_XSPI_SINGLE_MEM;

	hxspi.Init.MemoryType 				= HAL_XSPI_MEMTYPE_MICRON;

	hxspi.Init.MemorySize 				= 23;	/* 128Mbit=16MByte=2^(23+1) W25Q128JVSIQ */

	hxspi.Init.ChipSelectHighTimeCycle 	= 4;	/* 4ClockCycle(16nSec@250MHzMAX) Need for W25Q128JVSIQ >10nSec@read */

	hxspi.Init.FreeRunningClock 		= HAL_XSPI_FREERUNCLK_DISABLE;

	hxspi.Init.ClockMode 				= HAL_XSPI_CLOCK_MODE_0;

	hxspi.Init.WrapSize 				= HAL_XSPI_WRAP_NOT_SUPPORTED;

	hxspi.Init.ClockPrescaler 			= 1;	/* 250MHzMAX/(1+1) = 125MHz (Allowed SDR Clock is 150MHz@3.3V) */

	hxspi.Init.SampleShifting 			= HAL_XSPI_SAMPLE_SHIFT_HALFCYCLE;

	hxspi.Init.DelayHoldQuarterCycle 	= HAL_XSPI_DHQC_DISABLE;

	hxspi.Init.ChipSelectBoundary 		= 0;

	hxspi.Init.DelayBlockBypass 		= HAL_XSPI_DELAY_BLOCK_BYPASS;

	hxspi.Init.Refresh 					= 0;

	if (HAL_XSPI_Init(&hxspi) != HAL_OK)

	{

		for(;;);

	}

	

	/* Enable Reset --------------------------- */

	/* Common Commands */

	sCommand.OperationType      		= HAL_XSPI_OPTYPE_COMMON_CFG;

	sCommand.IOSelect           		= HAL_XSPI_SELECT_IO_3_0;

	sCommand.InstructionDTRMode 		= HAL_XSPI_INSTRUCTION_DTR_DISABLE;

	sCommand.AddressDTRMode     		= HAL_XSPI_ADDRESS_DTR_DISABLE;

	sCommand.DataDTRMode				= HAL_XSPI_DATA_DTR_DISABLE;

	sCommand.DQSMode            		= HAL_XSPI_DQS_DISABLE;

	sCommand.SIOOMode          			= HAL_XSPI_SIOO_INST_EVERY_CMD;

	sCommand.AlternateBytesMode 		= HAL_XSPI_ALT_BYTES_NONE;

	sCommand.AlternateBytes				= HAL_XSPI_ALT_BYTES_NONE;

	sCommand.AlternateBytesWidth		= HAL_XSPI_ALT_BYTES_NONE;

	sCommand.AlternateBytesDTRMode		= HAL_XSPI_ALT_BYTES_DTR_DISABLE;

	sCommand.InstructionMode   			= HAL_XSPI_INSTRUCTION_1_LINE;

	sCommand.InstructionWidth    		= HAL_XSPI_INSTRUCTION_8_BITS;

	sCommand.AddressWidth 				= HAL_XSPI_ADDRESS_24_BITS;

	/* Instruction */

	sCommand.Instruction 				= 0x66;	/* Reset Enable W25Q128JVSIQ */

	/* Address */

	sCommand.AddressMode       			= HAL_XSPI_ADDRESS_NONE;

	sCommand.Address					= 0;						

	/* Data */

	sCommand.DataMode          			= HAL_XSPI_DATA_NONE;

	sCommand.DataLength       			= 0;

	sCommand.DummyCycles       			= 0;				

	

	if (HAL_XSPI_Command(&hxspi, &sCommand, HAL_XSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)

	{

		for(;;);

	}

	

	/* Reset Device --------------------------- */

	/* Common Commands */

	sCommand.OperationType      		= HAL_XSPI_OPTYPE_COMMON_CFG;

	sCommand.IOSelect           		= HAL_XSPI_SELECT_IO_3_0;

	sCommand.InstructionDTRMode 		= HAL_XSPI_INSTRUCTION_DTR_DISABLE;

	sCommand.AddressDTRMode     		= HAL_XSPI_ADDRESS_DTR_DISABLE;

	sCommand.DataDTRMode				= HAL_XSPI_DATA_DTR_DISABLE;

	sCommand.DQSMode            		= HAL_XSPI_DQS_DISABLE;

	sCommand.SIOOMode          			= HAL_XSPI_SIOO_INST_EVERY_CMD;

	sCommand.AlternateBytesMode 		= HAL_XSPI_ALT_BYTES_NONE;

	sCommand.AlternateBytes				= HAL_XSPI_ALT_BYTES_NONE;

	sCommand.AlternateBytesWidth		= HAL_XSPI_ALT_BYTES_NONE;

	sCommand.AlternateBytesDTRMode		= HAL_XSPI_ALT_BYTES_DTR_DISABLE;

	sCommand.InstructionMode   			= HAL_XSPI_INSTRUCTION_1_LINE;

	sCommand.InstructionWidth    		= HAL_XSPI_INSTRUCTION_8_BITS;

	sCommand.AddressWidth 				= HAL_XSPI_ADDRESS_24_BITS;

	/* Instruction */

	sCommand.Instruction 				= 0x99;	/* Reset W25Q128JVSIQ */

	/* Address */

	sCommand.AddressMode       			= HAL_XSPI_ADDRESS_NONE;

	sCommand.Address					= 0;

	/* Data */

	sCommand.DataMode          			= HAL_XSPI_DATA_NONE;

	sCommand.DataLength       			= 0;

	sCommand.DummyCycles       			= 0;

	

	if (HAL_XSPI_Command(&hxspi, &sCommand, HAL_XSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)

	{

		for(;;);

	}



	/* Enter Quad-SPI Mode --------------------------- */

	/* Common Commands */

	sCommand.OperationType      		= HAL_XSPI_OPTYPE_COMMON_CFG;

	sCommand.IOSelect           		= HAL_XSPI_SELECT_IO_3_0;

	sCommand.InstructionDTRMode 		= HAL_XSPI_INSTRUCTION_DTR_DISABLE;

	sCommand.AddressDTRMode     		= HAL_XSPI_ADDRESS_DTR_DISABLE;

	sCommand.DataDTRMode				= HAL_XSPI_DATA_DTR_DISABLE;

	sCommand.DQSMode            		= HAL_XSPI_DQS_DISABLE;

	sCommand.SIOOMode          			= HAL_XSPI_SIOO_INST_EVERY_CMD;

	sCommand.AlternateBytesMode 		= HAL_XSPI_ALT_BYTES_NONE;

	sCommand.AlternateBytes				= HAL_XSPI_ALT_BYTES_NONE;

	sCommand.AlternateBytesWidth		= HAL_XSPI_ALT_BYTES_NONE;

	sCommand.AlternateBytesDTRMode		= HAL_XSPI_ALT_BYTES_DTR_DISABLE;

	sCommand.InstructionMode   			= HAL_XSPI_INSTRUCTION_1_LINE;

	sCommand.InstructionWidth    		= HAL_XSPI_INSTRUCTION_8_BITS;

	sCommand.AddressWidth 				= HAL_XSPI_ADDRESS_24_BITS;

	/* Instruction */

	sCommand.Instruction 				= 0x31;	/* Set Status2 W25Q128JVSIQ */

	/* Address */

	sCommand.AddressMode       			= HAL_XSPI_ADDRESS_NONE;

	sCommand.Address					= 0;

	/* Data */

	sCommand.DataMode          			= HAL_XSPI_INSTRUCTION_1_LINE;

	sCommand.DataLength       			= 1;

	sCommand.DummyCycles       			= 0;

	reg_data 							= 0x02;	/* Enable QuadI/O Mode */

	

	if (HAL_XSPI_Command(&hxspi, &sCommand, HAL_XSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)

	{

		for(;;);

	}

	

	if (HAL_XSPI_Transmit(&hxspi, ®_data, HAL_XSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)

	{

		for(;;);

	}



	/* Enter MemoryMappedMode --------------------------- */

	/* Read Commands */

	sCommand.OperationType      		= HAL_XSPI_OPTYPE_READ_CFG;

	sCommand.IOSelect           		= HAL_XSPI_SELECT_IO_3_0;

	sCommand.InstructionDTRMode 		= HAL_XSPI_INSTRUCTION_DTR_DISABLE;

	sCommand.AddressDTRMode     		= HAL_XSPI_ADDRESS_DTR_DISABLE;

	sCommand.DataDTRMode				= HAL_XSPI_DATA_DTR_DISABLE;

	sCommand.DQSMode            		= HAL_XSPI_DQS_DISABLE;

	sCommand.SIOOMode          			= HAL_XSPI_SIOO_INST_EVERY_CMD;

	sCommand.AlternateBytesMode 		= HAL_XSPI_ALT_BYTES_4_LINES;

	sCommand.AlternateBytes				= 0xFF;	/* Need for Fast Read QUAD W25Q128JVSIQ */

	sCommand.AlternateBytesWidth		= HAL_XSPI_ALT_BYTES_8_BITS;

	sCommand.AlternateBytesDTRMode		= HAL_XSPI_ALT_BYTES_DTR_DISABLE;

	sCommand.InstructionMode   			= HAL_XSPI_INSTRUCTION_1_LINE;

	sCommand.InstructionWidth    		= HAL_XSPI_INSTRUCTION_8_BITS;

	sCommand.AddressWidth				= HAL_XSPI_ADDRESS_24_BITS;

	/* Instruction */

	sCommand.Instruction 				= 0xEB;	/* Fast Read QUAD W25Q128JVSIQ */

	/* Address */

	sCommand.AddressMode       			= HAL_XSPI_ADDRESS_4_LINES;

	sCommand.Address					= 0;								

	/* Data */	

	sCommand.DataMode          			= HAL_XSPI_DATA_4_LINES;

	sCommand.DataLength       			= 0;

	sCommand.DummyCycles       			= 4;	/* DUMMY 4Cycle for Fast Read QUAD W25Q128JVSIQ */



	if(HAL_XSPI_Command(&hxspi, &sCommand, HAL_XSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)

	{

		for(;;);

	}

	

	/* Write Commands */

	sCommand.OperationType      		= HAL_XSPI_OPTYPE_WRITE_CFG;

	sCommand.IOSelect           		= HAL_XSPI_SELECT_IO_3_0;

	sCommand.InstructionDTRMode 		= HAL_XSPI_INSTRUCTION_DTR_DISABLE;

	sCommand.AddressDTRMode     		= HAL_XSPI_ADDRESS_DTR_DISABLE;

	sCommand.DataDTRMode				= HAL_XSPI_DATA_DTR_DISABLE;

	sCommand.DQSMode            		= HAL_XSPI_DQS_DISABLE;

	sCommand.SIOOMode          			= HAL_XSPI_SIOO_INST_EVERY_CMD;

	sCommand.AlternateBytesMode 		= HAL_XSPI_ALT_BYTES_NONE;

	sCommand.AlternateBytes				= HAL_XSPI_ALT_BYTES_NONE;

	sCommand.AlternateBytesWidth		= HAL_XSPI_ALT_BYTES_NONE;

	sCommand.AlternateBytesDTRMode		= HAL_XSPI_ALT_BYTES_DTR_DISABLE;

	sCommand.InstructionMode   			= HAL_XSPI_INSTRUCTION_1_LINE;

	sCommand.InstructionWidth    		= HAL_XSPI_INSTRUCTION_8_BITS;

	sCommand.AddressWidth				= HAL_XSPI_ADDRESS_24_BITS;

	/* Instruction */

	sCommand.Instruction 				= 0x32;	/* Page Write QUAD W25Q128JVSIQ */

	/* Address */

	sCommand.AddressMode       			= HAL_XSPI_ADDRESS_1_LINE;

	sCommand.Address					= 0;		

	/* Data */

	sCommand.DataMode          			= HAL_XSPI_DATA_4_LINES;

	sCommand.DataLength       			= 0;

	sCommand.DummyCycles       			= 0;							

	

	if(HAL_XSPI_Command(&hxspi, &sCommand, HAL_XSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)

	{

		for(;;);

	}



	/* Set OCTO-SPI as MemoryMappedMode */

	sMemMappedCfg.TimeOutActivation 	= HAL_XSPI_TIMEOUT_COUNTER_DISABLE;

	sMemMappedCfg.TimeoutPeriodClock 	= 0;

	if(HAL_XSPI_MemoryMapped(&hxspi, &sMemMappedCfg) != HAL_OK)

	{

        for(;;);

    }



}

STM32H5のOCTO-SPIのHALはL5と微妙に違っており"HAL_OSPI"だったのが
"HAL_XSPI"に変わってたりして移植の際めっちゃ鬱陶しかったのですが
基本的な設定の流れはL5の時とそこまで変わっておりません。

特筆すべきはSTM32H5は250MHzで動作するのでW25Q128JVSIQ(最大133MHz)
に対して125MHzという過激なスピードのクロックが供給可能で非常に高速な
動作が可能です！しかもデータキャッシュもついてます！

ちなみにSTM32H5のOCTO-SPIの最大供給クロックは150MHz(3.3V時)まで
可能となっております。

●実際に動かしてみる
ていうかポリウレタン被覆銅線でQSPI-ROMへ配線引き伸ばしてほんとに
125MHzで動いてンのかと自分でも訝しんでいましたので実際にクロックの
波形を測定してみました。
使用したオシロはPicoscope5444D MSOです。そうだね宣伝だね。

Picoscope5444D MSOのアナログ帯域200MHzなのに125MHzの高速信号測るの
どうなのとお思いでしょうが測定限界を大幅に超えていますがETSモードで
測定した限りではきっちり125MHzのクロックが出ていることがわかります。

ねむいさんはQSPI-ROMをFONTX2を格納するのに使っていますがこんな感じで
文字崩れも起こさずきれいに表示できております！

手配線の限界に挑んだ感じですがまぁSCLKは一応33ohmで直列終端は
しているのでそれが効いて安定して動作しているのでしょう～。

●おまけ・STM32L5とのパフォーマンス比較
せっかく下駄基板作ってハード的に同じ条件が揃えてるのでSTM32L5と
STM32H5のパフォーマンス比較とかやってみました。
同一のpngファイルでlibpngを使ったデコード時間を比較してみました。

☝STM32L5の場合(動作クロック:110MHz)

☝STM32H5の場合(動作クロック:250MHz)
う～むやはり圧倒的に違いますね～というかねむいさんがSTM32H5の
パワーを持て余しててまだまだ機能の一握りも使えてないので頑張って
使いこなしていこうと思います！これからも頑張るぞい！

STM32C0を使ってみる4 -8PinのSTM32C0を使いこなせ!-

今回は秋月電子さんから販売された8ピンのSTM32C011J4M7を使いこなします。
STM32G0の時と違ってGPIOの設定が厳密になっているのでそこら辺も掘り込んで
詳しく紹介します。

●ねむいさん的STM32C011やっけつ回路

今回紹介する8ピンSTM32C011の回路図はG0の頃と同じ感じです。
8ピンSTM32G0をそのまま差し替えて使用できるようにしてみました。
もちろん1-Wireも使えます！

ちなみに最低限のやっけつ回路なので真似される方は電源ラインは
適宜強化願います。

●GPIOのリマップとマルチプレクス

さて、8ピンのSTM32C011はひとつのピンに多重にGPIOや周辺機能が
割り当てられています。

ねむいさんは8ピンのSTM32G0と同じ回路でI2Cを動作させたかったの
ですが、STM32C011のI2Cは1つしか存在しないためSTM32G0では可能
だったI2C2が使用できずI2C1のみとなっております。
その結果PA11,PA12をそのまま使用することができないので"リマップ"
を行う必要があります。

SYSCFGのCFGR1レジスタをいじってGPIOのリマップを行うことによりI2C1
(PA9,PA10)がようやく使用可能となります。

実際はHALライブラリのRemap関数が提供されているのでそれを使用しております。

また、STM32G0ではガバガバだったGPIOの設定もC0では厳密になっており、
例えば8Pin版STM32C0でPC14を選択して使用したい場合はSYSCFGのCFGR3
レジスタのPINMUXビットをいじる必要があります(ついでにPA9とPA10も)。

また、20Pin版STM32C011F4P6では他のI/Oポートと重複がなくPINMUXをいじる
必要がないため、上で提示したコードのようにパッケージレジスタを参照し、
PINMUXをいじるか否かを判定しております。

てわけで改めてSTM32C011J4M7を使ってI2Cデバイス(秋月OLEDとSHT40)を
使った温湿度計を稼働させてみました！楽勝ですね☆

秋月から8pinSTM32G0がなくなった今、8ピンのSTM32C011J4M7がSTM32への
入門の定番となっていくでしょう！

今回紹介したプロジェクトはSTM32C0-NUCELOのプロジェクトと合体させて
公開しております！どしどしご活用ください！

●STM32C011J4M7のフラッシュ容量は実際32kByteもある?
STM32C011J4M7のフラッシュ容量は公称では16kByteとなっております。
しかし実際には32kByteもあるようです…マジかよ…
実際に以下の方々が32kByteあることを確認をしております。
しっぽいいんちょ様
 amanoya3様


ねむいさんもSTM32C0-NucleoからSWDを引き出してSTM32C011に接続し、
STM32CubeProgrammerで確認してみました！

…ッッマジだ…32kByteってなってる…

わざと16kByteを超える30kByte超えのバイナリを作って書き込んで
みました…書き込める…ちゃんとベリファイも通る…!!!

もちろんちゃんと動いてるし…!

てわけで秋月で売っているSTM32C011J4M7は16kByteではなく実際は
32kByteもあることがわかりましたがこのおまけ容量に頼った設計を
しないように！ちゃんと16kByteの範疇で遊びましょう！

なお、OpenOCDでは16kByte以上を書き込むことができず、16kByte
以降の領域は書き込まれていないためベリファイが通りません。

なんでかというとOpenOCDのSTM32C0のフラッシュ書き込みドライバは
STM32C0に仕込んであるフラッシュ容量レジスタを参照して厳密に書き込める
容量を決定しているためです。

逆に言うとSTM32CubeProgrammerのほうがガバッガバなドンブリ設計…
STマイクロ公式がそれでいいのか！？

ちなみに超セコい技ですがCubeProgrammerで予め16kByte以降の領域を
書き込んでおくとOpenOCDでもベリファイが通りプログラムも正常に
動作します。全然意味ないですがー！

このおまけ容量の使い方としてはどうしてもプログラムサイズが
増えがちなデバッグ時に一時的な使い方として用いるのがよいです。
まぁロットが変わっておまけの16kByte分が無くなったら出来ない
技なので当たり引けたらラッキー的な感じで遊んでいきましょ～

20240821追:
STM32CubeProgrammer2.17.0で対策されてしまい、正規の16kByte分しか
認識しなくなってしまいました。

てわけでプログラムはちゃんと16kByte以内になるように作りこみましょう！

STM32C0を使ってみる3 -STM32C011秋月発売記念-

少し前の話ですがSTM32C0シリーズが秋月電子よりついに販売されました！！

8pinのSTM32C011J4M7と

 20pinのSTM32C011F4P6です！！

ROM容量はROM16kbyte,RAMが6kbyteとSTM32シリーズの中では
非常に小ぶりな品種となります。

●ピン配置について注意

まず注意点として20Pinの品種は同じく秋月で販売されているSTM32L010F4P6と
ピン互換性がないのでご注意ください。

また、8pinのSTM32C011J4M7はかつて秋月で販売されていたSTM32G031J6M6と
ほぼピン互換となっております…

が！

ねむいさんの使い方ではI/Oのリマップを行わないと一部の機能…I2Cが
使用できないのでご注意ください。こちらについては次回にみっちりと解説
させていただきます！

●実際に使ってみた

そんなわけで秋月OLEDと秋月販売のSHT40と8pinSTM32C011でサクッと温湿度
表示してみました…！

長らくの間ねむいさんのドットマトリクスOLEDドライバが秋月OLEDに対応して
なかったの気づいてませんでしたが誰も気づいてなかったから多分大丈夫です…
…
すみません次回からまじめにやります…！！

今回はさわりだけ紹介しましたが、次回はI/Oのリマップ機能とかも使いこなす
方法も解説していこうと思います！

20240206追:
既存のSTM32C031-NUCLEO向けプロジェクトにSTM32C011J4M7向けの
やつを合体させたの先行公開します！！！！！
20240206追:

STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-

20240516追:
秋月さんよりNUCLEO-H563ZI販売開始です！！
20240516追:

クリスマス直前ですがわずかな時間を見つけて少しでもSTM32H5を使った
記事を書き残していきます…その先に何があるのかわからなくとも…！
すでにFatFsのSTM32H5への移植例はアップロードしておりますので今回も
これをもとに解説を進めていきますよぅ！

今回は基本中の基本、GPIOのほかにCortex-M33というかSTM32H5を使う人の
所見殺しポイントの回避とかを紹介してまいります。

●GPIOのレジスタがちょっと合理化

これはSTM32L5からなのですがGPIO出力のビットセット/リセットのレジスタ
(BSRR/BRR)が別々のアドレスに設定されております。

これは何気に良い改良だと思います。STM32F1とかの古い品種では上位16bit
がBRRで下位16bitがBSRRでひとまとまりになっており、HALに振り回されて
非常に使いづらくオーバーヘッドも多いので実行速度・コードサイズ的に
とても不利な代物でした。

で、ねむいさんは例えばSTM32F4のHALライブラリを使った作例とかではこんな
感じの構造体を作ってキャストしなおしてアクセスする手法でGPIOのビット
セット＆リセットを簡潔にやってきましたが、たまにソースコードちゃんと
読まない方々からBRRなんてないからこのプログラムは動かないのでは？とか
質問もらうのですがほんとにBRRが定義されてないのならそもそもビルド通らん
やろうがぁああああ！！ちゃんとstm32f4xx_hal_conf.hの一番下のところ読めや
あああぁぁあぁあ！！！１１！１

はぁはぁ…失礼…話を戻しますがSTM32H5・STM32L5以降ではそういう
小手先の手間も省けてBRR/BSRRられるようになりましたので安心です♥

●ビルド途中でGCCがセグメンテーションフォルトして死ぬ

なんでやねん
どうしたらよいのだ私は…
具体的に言うとGCC12でstm32h5xx_hal_dma_ex.cを最適化レベル-O2以降で
コンパイルしたらセグフォ死します…何やっても先に進めません

ねむいさんより先にSTM32H5触れた方も所見殺しの罠にかかっておられ
ました…やはり初物はエラッタからライブラリに至るまで罠が満載…

ねむいさんは苦しみ紛れに屁をこいたような対策でセグフォ死の罠を
回避を行うことで対策しております。ちなみに現在リリースされている
GCC13では対策されて-O2にしても落ちなくなったので安心です☆

ねむいさんはSTM32H5のDMA対応ですっっごく時間食われましたがその半分
くらいはセグフォ問題で捕まりました…F**K!

●DACを使用したりUniqueIDを読みだそうとしたらHardFaultって死ぬ
だからなんでやねん
L5だと全く問題なかったのに…！

その理由はUIDレジスタのアドレスの変更に理由があります。
STM32L5ではこれらのレジスタは0x0BFA0590だったのですがSTM32H5では
0x08FFF800以降に変更されており、このアドレス領域はフラッシュメモリが
存在するアドレス(0x08000000)と同じであり命令実行を前提としている
そうなので普通の使い方ではIキャッシュを有効にすると思いますが有効に
してUIDレジスタがある0x08FFF800にアクセスした瞬間に命令領域にデータ
アクセスしようとしたと判断されてHardFaultして死にます！

もっと凶悪なのがHALライブラリのDACライブラリ中でパッケージデータを
判別して使用するチャネルを設定するコードがあり、そのパッケージを判別
するレジスタも0x08FFF800以降に存在するので何も対策してないと上記の例と
同じようにHardFaultして容赦なく死にます！！

STM32のフォーラムでは罠にかかった犠牲者がすでにちらほら出ております…

で、対策なのですがMPUを使用して0x08FFF800あたりのアドレスを読み出し
オンリー&命令実行禁止設定にしてあげればよいです。具体的には下記の
コードになります。

static void MPU_Config(void)

{

	MPU_Region_InitTypeDef	MPU_InitStruct;

	MPU_Attributes_InitTypeDef	MPU_AttributesInit;



	/* Configure region for UID,PACKAGE,FLASHSIZE and other registers */

	/* Disable MPU */

	HAL_MPU_Disable();

	

	/* Define readonly access via MPU */

	MPU_AttributesInit.Number             	= MPU_ATTRIBUTES_NUMBER0;

	MPU_AttributesInit.Attributes         	= MPU_NOT_CACHEABLE;

	HAL_MPU_ConfigMemoryAttributes(&MPU_AttributesInit);



	MPU_InitStruct.Enable 					= MPU_REGION_ENABLE;

	MPU_InitStruct.BaseAddress 				= 0x08FFF800UL; /* UID ADDRESS and others */

	MPU_InitStruct.LimitAddress 			= 0x08FFFFFFUL;

	MPU_InitStruct.AccessPermission 		= MPU_REGION_ALL_RO;

	MPU_InitStruct.AttributesIndex 			= MPU_ATTRIBUTES_NUMBER0;

	MPU_InitStruct.IsShareable 				= MPU_ACCESS_NOT_SHAREABLE;

	MPU_InitStruct.Number 					= MPU_REGION_NUMBER0;

	MPU_InitStruct.DisableExec 				= MPU_INSTRUCTION_ACCESS_DISABLE;



	HAL_MPU_ConfigRegion(&MPU_InitStruct);



	/* Enable MPU (any access not covered by any enabled region will cause a fault) */

	HAL_MPU_Enable(MPU_PRIVILEGED_DEFAULT);

}

なお、マニュアルにもあらかじめMPU使っておけよと匂わせておりますが
こんなん初見で絶対わかりませんよぅ！！！
人にソースコードよく見ろと言っておきながら自分のことは棚に上げて
言うのもアレですがマニュアル相当読み込まないとマジで気づきません。

STM32L5から特に何も考えずスライド移植したら罠にかかって爆死する
パタンがH5では多いので気を付けましょう(経験者バイアス)
それとこうならないようにマニュアルはちゃんと読みましょうorz

20240205追:
STM32H5の地雷踏まないようなMPU設定の仕方が公式で
ようやく公開されています…最初から公表しろ～～～～！！！！！！
20240205追:

そんなわけでいくつもの罠が待ち受けているSTM32H5ですがこれからも
未知の罠が待ち受けているでしょう。しかしアーリーアダプタな戦士たちは
それに臆せず果敢に進んでいくのです…！！

そして先にも紹介しましたがFatFsのSTM32H5への移植例はおきぱですでに
公開しております。ちょっと気が早いですが先行して2024年版に更新
しておりますのでヨロシク！！

STM32H5を使ってみる2 -フラッシュ書き込み＆デバッグ環境作るだけで疲労困憊-

20240516追:
秋月さんよりNUCLEO-H563ZI販売開始です！！
20240516追:

秋の登山ラッシュに入ってしまったのでせっかく買ったのに全く
STM32H5触れてない毎日ですがわずかな時間を見つけてすこしでも
進ませていただきます！！！

さて今回からSTM32L5で行ったように基本となる機能と開発環境の
確認を紹介していきます。

●OpenOCDがSTM32H5に対応してない！？大丈夫だ問題ない
はい、ﾋ改めﾒのタイムライン見てもSTM32H5の話題が全く上がらず盛り上がって
ないのはこれが原因かと思われます。

OpenOCDのメーリングリストではH5試したけどL5みたいに動かないよー
というアーリーアダプタの方のコメントがありますがその後の進展は
全くなし…。

幸いにもSTマイクロ公式でForkしているOpenOCDのgitではひっそりと
STM32H5に対応しておりますがこちらも今年春から進展はなく、OpenOCD
本家の主流から大きく引き離されております。

とりあえずですがSTマイクロのソースコードを分析して最新のOpenOCD
でもビルド・動作できるようにしたものをねむいさんのおきぱに配置
しておりますのでご利用ください…

ところでL5とH5は同じCortex-M33コアなのになぜここまで違うのか？
という疑問ですがコアのrevid,devidを取得する関数が大幅に違います。
・STM32H5

static int stm32h5x_read_idcode(struct flash_bank *bank, uint32_t *id)

{

	struct target *target = bank->target;

	struct cortex_m_common *cortex_m = target_to_cm(bank->target);

	struct adiv5_ap *ap = cortex_m->armv7m.debug_ap;



	/* DBGMCU_IDCODE cannot be read from AP1, read it from ROM Table */

	target_addr_t dbgbase;

	uint32_t apid;

	int retval = dap_get_debugbase(ap, &dbgbase, &apid);

	if (retval != ERROR_OK)

		return retval;



	target_addr_t base_addr = dbgbase & 0xFFFFFFFFFFFFF000ull;



	/* PID Registers 0 to 3 are sufficient to identify the device */

	uint32_t pid_regs[4];



	retval = target_read_memory(target, base_addr + ARM_CS_PIDR0, 4, 4, (uint8_t *)pid_regs);

	if (retval != ERROR_OK)

		return retval;



	uint64_t pid = (pid_regs[3] & 0xff) << 24

					| (pid_regs[2] & 0xff) << 16

					| (pid_regs[1] & 0xff) << 8

					| (pid_regs[0] & 0xff);



	uint16_t dev_id = pid & 0x0FFF;

	uint8_t rev_id_major = pid >> 20 & 0xF;

	uint8_t rev_id_minor = pid >> 28 & 0xF;

	uint16_t rev_id = rev_id_major << 12 | rev_id_minor;



	*id = rev_id << 16 | dev_id;



	return retval;

}

・STM32L5たち

static int stm32l4_read_idcode(struct flash_bank *bank, uint32_t *id)

{

	int retval = ERROR_OK;

	struct target *target = bank->target;



	/* try reading possible IDCODE registers, in the following order */

	uint32_t dbgmcu_idcode[] = {DBGMCU_IDCODE_L4_G4, DBGMCU_IDCODE_L5, DBGMCU_IDCODE_G0};



	for (unsigned int i = 0; i < ARRAY_SIZE(dbgmcu_idcode); i++) {

		retval = target_read_u32(target, dbgmcu_idcode[i], id);

		if ((retval == ERROR_OK) && ((*id & 0xfff) != 0) && ((*id & 0xfff) != 0xfff))

			return ERROR_OK;

	}



	/* Workaround for STM32WL5x devices:

	 * DBGMCU_IDCODE cannot be read using CPU1 (Cortex-M0+) at AP1,

	 * to solve this read the UID64 (IEEE 64-bit unique device ID register) */



	struct armv7m_common *armv7m = target_to_armv7m_safe(target);

	if (!armv7m) {

		LOG_ERROR("Flash requires Cortex-M target");

		return ERROR_TARGET_INVALID;

	}



	/* CPU2 (Cortex-M0+) is supported only with non-hla adapters because it is on AP1.

	 * Using HLA adapters armv7m.debug_ap is null, and checking ap_num triggers a segfault */

	if (cortex_m_get_partno_safe(target) == CORTEX_M0P_PARTNO &&

			armv7m->debug_ap && armv7m->debug_ap->ap_num == 1) {

		uint32_t uid64_ids;



		/* UID64 is contains

		 *  - Bits 63:32 : DEVNUM (unique device number, different for each individual device)

		 *  - Bits 31:08 : STID (company ID) = 0x0080E1

		 *  - Bits 07:00 : DEVID (device ID) = 0x15

		 *

		 *  read only the fixed values {STID,DEVID} from UID64_IDS to identify the device as STM32WLx

		 */

		retval = target_read_u32(target, UID64_IDS, &uid64_ids);

		if (retval == ERROR_OK && uid64_ids == UID64_IDS_STM32WL) {

			/* force the DEV_ID to DEVID_STM32WLE_WL5XX and the REV_ID to unknown */

			*id = DEVID_STM32WLE_WL5XX;

			return ERROR_OK;

		}

	}



	LOG_ERROR("can't get the device id");

	return (retval == ERROR_OK) ? ERROR_FAIL : retval;

}

注:STM32L5のフラッシュ書き込みのコードはstm32l4x.cに取り込まれてます。

本来ならSTM32L5と同じくDBGMCU_IDCODEレジスタ(0xE0044000)から
読んでくれば終わる話なのですがSTM32H5ではそれができません。

DBGMCU_IDCODEがあるAHB-AP(AP1)から読もうとすると0しか返ってきません。
仕方ないのでAP0にあるROMTABLEからPID0~3を読みだしてdevid,revidを
読みだす必要があるわけです。んなことわかるか！！！

さて、何とかSTM32H5対応なおかつ最新のコミットにOpenOCDを対応させ
書き込みしてみたログは以下のようになりました。
書き込みスクリプトはねむいさん謹製のstm32h5x_flash.cfgを使用します。

> "C:¥Devz¥Coreutils¥bin¥make.exe" program

openocd  -s C:/Devz/ARM/OCD/tcl -f interface/stlink-dap.cfg -c "transport select dapdirect_swd" -f target/stm32h5x_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.12.0+dev-00415-gacde409ba (2023-11-23-16:02)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.org/doc/doxygen/bugs.html

dapdirect_swd

Info : STLINK V3J13M4 (API v3) VID:PID 0483:3754

Info : Target voltage: 3.278828

Info : Unable to match requested speed 480 kHz, using 200 kHz

Info : Unable to match requested speed 480 kHz, using 200 kHz

Info : clock speed 200 kHz

Info : stlink_dap_op_connect(connect)

Info : SWD DPIDR 0x6ba02477

Info : [stm32h5x.cpu] Cortex-M33 r0p4 processor detected

Info : [stm32h5x.cpu] target has 8 breakpoints, 4 watchpoints

Info : starting gdb server for stm32h5x.cpu on 3333

Info : Listening on port 3333 for gdb connections

Info : Unable to match requested speed 480 kHz, using 200 kHz

Info : Unable to match requested speed 480 kHz, using 200 kHz

CPU in Non-Secure state

[stm32h5x.cpu] halted due to debug-request, current mode: Thread 

xPSR: 0xf9000000 pc: 0x08030dac msp: 0x20050000

Info : Unable to match requested speed 4000 kHz, using 3300 kHz

Info : Unable to match requested speed 4000 kHz, using 3300 kHz

Info : device idcode = 0x10000484 (STM32H56/H57xx - Rev A : 0x1000)

Info : TZEN = 0xC3 : TrustZone disabled by option bytes

Info : Product State = 0xED : 'Open'

Info : flash size = 2048kbytes

Info : flash mode : dual-bank

Info : Padding image section 1 at 0x0805aa8c with 4 bytes (bank write end alignment)

Warn : Adding extra erase range, 0x0805aa90 .. 0x0805bfff

Info : wrote 371344 bytes from file main.elf in 1.537886s (235.805 KiB/s)

Info : verified 371340 bytes in 0.903676s (401.291 KiB/s)

Info : Unable to match requested speed 480 kHz, using 200 kHz

Info : Unable to match requested speed 480 kHz, using 200 kHz

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:04

ねむいさんが持ってるH5のはrev.Z(0x1001)のはずですが…なんでか
Rev.A(0x1000)になってるんですけぉ…まぁいいかそんあ詳細なこと。
書き込みスピードがメタクソ早くなっているのが救いですね～

なお、STM32H743のようにバグだらけのRev.Yと修正版のRev.V以降では
まったくの別物になっていたりしたケースがあるのでSTM32H5もこれから
先、Revが上がっていったらとんでもない地雷が待ち受けているかもしれ
ませんがまぁその時はその時で…

それとTrastZone無し限定ですがデバッグのほうももちろんすいすいと
できちゃいます。H5NucleoならSTLink-V3相当がビルドインされており
キビキビ反応してストレスレスでデバッグが可能です☆

そんなわけで再度紹介になりますが、STM32H5対応OpenOCDバイナリは
私のぶろぐのおきぱで公開しておりますのでH5の基板を持っている方は
どしどしご利用ください！！！

本当はソースコードの基礎部分と、とんでもない罠があるところを解説
したかったのですがOpenOCDだけで力尽きたので次回以降のエントリに
委ねたいと思います…登山ラッシュに入ってますが今年中には足掛かり
くらいは何とか気力振り絞って記事書きたいな～と思ってます。

H5のプロジェクト自体はすでに公開しておりますので
それまでに皆様予習をお願いいたします…ｚｚｚ

STM32H5はぢめました

20240516追:
秋月さんよりNUCLEO-H563ZI販売開始です！！
20240516追:

↑STM32H56x/57xエラッタシートより
ぇえぇ…エラッタで1000回しかフラッシュ書き換えできないとか
どこのルネ〇サスのマイコンだYO…

被弾するのはrev.AとZね…ふむふむ

…

おいいいいいいいいいいいいいい！！！！！！！！１１！！１１

というわけでいきなり地雷を踏んで幸先の良いスタートを切った私のSTM32H5
ですが、現時点ではSTマイクロがリリースするCortex-M33コアを持つ最新の
マイコンとなっております。

動作周波数は250MHzにまで引き上げられ、インストラクションキャッシュや
データキャッシュ(FMCとQSPIのみ)も増強され、STM32F7に勝るとも劣らない
実力を備えながらも電力は控えめと環境にも優しいものとなっております。

過去にリリースされた同じCortex-M33のマイコン、STM32L5のパフォーマンス
強化型の進化の位置づけとなりなおかつベストセラーだったSTM32F4の後継と
なるでしょう。ちなみに低消費電力特化型はSTM32U5となりこちらも順当に
進化し続けております。

ねむいさんは7月上旬早々に144Pin版H5NUCLEOを購入しておりましたが先に
塩漬けになっていたSTM32L5の攻略に時間がかかっておりましたので10月に
入ってようやく手を付けた次第でございます…。

NUCLEO基板なのでデバッガもコミコミで搭載されております。
当たり前のようにSTM32F723がのっかっている…これはSTlinkV3相当ですね～

USBの端子はすべてType-Cに統一されております。
STM32H5がUSB-PDに対応してるからですね～STM32H5Cube見た限りでは
USB関連はかなりの魔境になっているので当分手出しできそうにないですが…

また、イーサネットも出ております。こちらも魔境なのでかなり先の課題と
なるでしょう…！

144Pin版NUCLEOなのでSTM32L5の時に拵えたゲタ基板ももちろん引き続き
流用可能となっております！

おっと
一点注意ですがQSPI-ROMも使いたい場合はSB70にジャンパをしてください。
PE2(OCTO-SPI IO2)がデフォルトでは電気的に接続されておりませんので
SB70をジャンパして有効にするのを忘れぬようご注意ください。
いずれ紹介するQSPI-ROM使用時の記事に再度アナウンスします。

そんなわけで今回は単に基板の紹介に終わってしまいましたが、実は
すでにねむいさんのいつもの(UART,SDMMC経由FatFs,OCTO-SPI,SPI液晶)
は実装済みとなっております。今回は各モジュール、特にSPIとDMAがL5と
全く違ったものとなっているため一つ一つじっっくりと時間をかけて解説
させていただきます。H5の記事作成これからもがんばるぞい！

とりあえずSTM32H5のFatFs実装例を見たいんだーい!!って人はもうすでに
おきぱに配置しておりますので予習をお願いいたします。
ねむいさんの真似をしてゲタ基板を作られた方ならすぐに再現可能と
なっておりますので是非ご利用ください！

また、私が提供するOpenOCDバイナリはSTM32H5の書き込み&デバッグを
サポートしておりますのでNUCLEOをお持ちの方はこちらもご利用ください！！

STM32L5を使ってみる3 -OCTO-SPIでQUAD-SPIROMを使おう-

●QUAD-SPI接続NORFLASH-ROMを使いこなせ!
FONTX2ファイルなどの大容量のデータはSTM32等の大規模マイコンと
いえどもフラッシュ容量を非常にひっ迫します。
以前からはそういったデータは外付けのQSPI-ROMに格納し、そこから
アクセスするといった手法が定番となっております。

STM32L5では信号線を最大8本持つクロックドシリアルインターフェース
いわゆる"OCTO-SPI"をもちさらに利便性が高まっております！
このOCTO-SPIを使ってQSPI-ROMと接続し内蔵フラッシュメモリのように
使えるMemoryMappedModeで読み出していこうと思います！

●もはや定番☆WinbondのW25Q128JVSIQ

前々回からの紹介の通り、ねむいさんは入手も容易で十分な容量(16MB)、
高速なクロック(133MHz)でデフォルトでQUAD-SPIモードになっていて
コマンドが省略出来て扱いやすいW25Q128JVSIQを使用しました。

W25Qのシリーズにはいろいろありますが末尾"IQ"のものは上でも
書いた通り最初っからQUAD-SPIモードになっており今から紹介する
メモリマップドモードで投げるコマンドがいくつか省略出来て楽です。
digikeyやmouserで購入の際はうっかり違うやつを買わないように
型番には注意してください。

●OCTO-SPIをMemoryMappedModeで使用するためのコード手順
STM32L5に搭載されているOCTO-SPIはSTM32F7などにあったQUAD-SPI
インターフェースからされに拡張され、読み出しのほかに書き込みも
サポートされています。基本的な設定の流れはQUAD-SPIの頃とほぼ
同じですがOCTO-SPIならではの設定もあるので注意しましょう。

↓まずはI/O設定です。

/**************************************************************************/

/*! 

    @brief	OCTO-SPI GPIO Configuration.

	@param	None.

    @retval	None.

*/

/**************************************************************************/

void OSPI_IoInit_If(void)

{

	GPIO_InitTypeDef GPIO_InitStruct = {0};

	RCC_PeriphCLKInitTypeDef PeriphClkInit = {0};



	/* Initializes the peripherals clock */

	PeriphClkInit.PeriphClockSelection 	= RCC_PERIPHCLK_OSPI;

	PeriphClkInit.OspiClockSelection 	= RCC_OSPICLKSOURCE_SYSCLK;

	if (HAL_RCCEx_PeriphCLKConfig(&PeriphClkInit) != HAL_OK)

	{

		for(;;);

	}

	

	/* Peripheral clock enable */

	__HAL_RCC_OSPI1_CLK_ENABLE();

	

	/* Alternate GPIO enable */

	__HAL_RCC_GPIOE_CLK_ENABLE();

	__HAL_RCC_GPIOB_CLK_ENABLE();

	__HAL_RCC_GPIOA_CLK_ENABLE();



	/* PE12 as OSPI_IO0 */

	GPIO_InitStruct.Pin 		= GPIO_PIN_12;

	GPIO_InitStruct.Mode 		= GPIO_MODE_AF_PP;

	GPIO_InitStruct.Pull 		= GPIO_NOPULL;

	GPIO_InitStruct.Speed 		= GPIO_SPEED_FREQ_VERY_HIGH;

	GPIO_InitStruct.Alternate = GPIO_AF10_OCTOSPI1;

	HAL_GPIO_Init(GPIOE, &GPIO_InitStruct);



	/* PB0 as OSPI_IO1 */

	GPIO_InitStruct.Pin 		= GPIO_PIN_0;

	HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);



	/* PE14 as OSPI_IO2 */

	GPIO_InitStruct.Pin 		= GPIO_PIN_14;

	GPIO_InitStruct.Alternate = GPIO_AF10_OCTOSPI1;

	HAL_GPIO_Init(GPIOE, &GPIO_InitStruct);



	/* PE15 as OSPI_IO3 */

	GPIO_InitStruct.Pin 		= GPIO_PIN_15;

	GPIO_InitStruct.Alternate = GPIO_AF10_OCTOSPI1;

	HAL_GPIO_Init(GPIOE, &GPIO_InitStruct);

	

	/* PB10 as OSPI_CLK */

	GPIO_InitStruct.Pin		 	= GPIO_PIN_10;

	GPIO_InitStruct.Alternate = GPIO_AF10_OCTOSPI1;

	HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);

	

	/* PA2 as OSPI_NCS */

	GPIO_InitStruct.Pin 		= GPIO_PIN_2;

	GPIO_InitStruct.Alternate = GPIO_AF10_OCTOSPI1;

	HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

}

これはNUCLEO-L552ZE-Qから出たQUAD-SPIの足に対応したものです。
OCTO-SPIなのに8本全部使わぬぇのかと思いでしょうがこれはNUCLEO
が引き出してる足がそうなってるからそれに従ったわけなのでー

↓お次はOCTO-SPIの設定です。

/**************************************************************************/

/*! 

    @brief	Configure OCTO-SPI as Memory Mapped Mode.

			Winbond W25Q128JVSIQ specific setting.

			* Address size is 24bit(16MBytes).

			* Initially sets QUAD-MODE(not need quadmode command).

			* MAX 133MHz CLK.

			* Support "XIP",thus suitable for MemoryMappedMode.

	@param	None.

    @retval	None.

*/

/**************************************************************************/

void Set_OSPI_MemoryMappedMode(void)

{

	OSPI_RegularCmdTypeDef sCommand = {0};

	OSPI_MemoryMappedTypeDef sMemMappedCfg = {0};

	uint8_t reg_data =0;

	

	/* Initialize OCTO-SPI I/O */

	OSPI_IoInit_If();

	

	/* Initialize OCTO-SPI */

	hospi.Instance 						= OCTOSPI1;

	hospi.Init.FifoThreshold 			= 1;

	hospi.Init.DualQuad 				= HAL_OSPI_DUALQUAD_DISABLE;

	hospi.Init.MemoryType 				= HAL_OSPI_MEMTYPE_MICRON;

	hospi.Init.DeviceSize 				= 24;	/* 128Mbit=16MByte=2^24 W25Q128JVSIQ */

	hospi.Init.ChipSelectHighTime 		= 2;	/* 2ClockCycle(18nSec@110MHz) Need for W25Q128JVSIQ >10nSec@read */

	hospi.Init.FreeRunningClock 		= HAL_OSPI_FREERUNCLK_DISABLE;

	hospi.Init.ClockMode 				= HAL_OSPI_CLOCK_MODE_0;

	hospi.Init.WrapSize 				= HAL_OSPI_WRAP_NOT_SUPPORTED;

	hospi.Init.ClockPrescaler 			= 2;	/* 110MHzMAX/2 = 55MHz(MAX OSPI-CLK:90MHz) */

	hospi.Init.SampleShifting 			= HAL_OSPI_SAMPLE_SHIFTING_HALFCYCLE;

	hospi.Init.DelayHoldQuarterCycle 	= HAL_OSPI_DHQC_DISABLE;

	hospi.Init.ChipSelectBoundary 		= 0;

	hospi.Init.DelayBlockBypass 		= HAL_OSPI_DELAY_BLOCK_BYPASSED;

	hospi.Init.Refresh 					= 0;

	if (HAL_OSPI_Init(&hospi) != HAL_OK)

	{

		for(;;);

	}

	

	/* Enable Reset --------------------------- */

	/* Common Commands */

	sCommand.OperationType      		= HAL_OSPI_OPTYPE_COMMON_CFG;

	sCommand.FlashId            		= HAL_OSPI_FLASH_ID_1;

	sCommand.InstructionDtrMode 		= HAL_OSPI_INSTRUCTION_DTR_DISABLE;

	sCommand.AddressDtrMode     		= HAL_OSPI_ADDRESS_DTR_DISABLE;

	sCommand.DataDtrMode				= HAL_OSPI_DATA_DTR_DISABLE;

	sCommand.DQSMode            		= HAL_OSPI_DQS_DISABLE;

	sCommand.SIOOMode          			= HAL_OSPI_SIOO_INST_EVERY_CMD;

	sCommand.AlternateBytesMode 		= HAL_OSPI_ALTERNATE_BYTES_NONE;

	sCommand.AlternateBytes				= HAL_OSPI_ALTERNATE_BYTES_NONE;

	sCommand.AlternateBytesSize			= HAL_OSPI_ALTERNATE_BYTES_NONE;

	sCommand.AlternateBytesDtrMode		= HAL_OSPI_ALTERNATE_BYTES_DTR_DISABLE;

	sCommand.InstructionMode   			= HAL_OSPI_INSTRUCTION_1_LINE;

	sCommand.InstructionSize    		= HAL_OSPI_INSTRUCTION_8_BITS;

	sCommand.AddressSize 				= HAL_OSPI_ADDRESS_24_BITS;

	/* Instruction */

	sCommand.Instruction 				= 0x66;	/* Reset Enable W25Q128JVSIQ */

	/* Address */

	sCommand.AddressMode       			= HAL_OSPI_ADDRESS_NONE;

	sCommand.Address					= 0;							

	/* Data */

	sCommand.DataMode          			= HAL_OSPI_DATA_NONE;

	sCommand.DummyCycles       			= 0;							

	sCommand.NbData            			= 0;							

	

	if (HAL_OSPI_Command(&hospi, &sCommand, HAL_OSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)

	{

		for(;;);

	}

	

	/* Reset Device --------------------------- */

	/* Common Commands */

	sCommand.OperationType      		= HAL_OSPI_OPTYPE_COMMON_CFG;

	sCommand.FlashId            		= HAL_OSPI_FLASH_ID_1;

	sCommand.InstructionDtrMode 		= HAL_OSPI_INSTRUCTION_DTR_DISABLE;

	sCommand.AddressDtrMode     		= HAL_OSPI_ADDRESS_DTR_DISABLE;

	sCommand.DataDtrMode				= HAL_OSPI_DATA_DTR_DISABLE;

	sCommand.DQSMode            		= HAL_OSPI_DQS_DISABLE;

	sCommand.SIOOMode          			= HAL_OSPI_SIOO_INST_EVERY_CMD;

	sCommand.AlternateBytesMode 		= HAL_OSPI_ALTERNATE_BYTES_NONE;

	sCommand.AlternateBytes				= HAL_OSPI_ALTERNATE_BYTES_NONE;

	sCommand.AlternateBytesSize			= HAL_OSPI_ALTERNATE_BYTES_NONE;

	sCommand.AlternateBytesDtrMode		= HAL_OSPI_ALTERNATE_BYTES_DTR_DISABLE;

	sCommand.InstructionMode   			= HAL_OSPI_INSTRUCTION_1_LINE;

	sCommand.InstructionSize    		= HAL_OSPI_INSTRUCTION_8_BITS;

	sCommand.AddressSize 				= HAL_OSPI_ADDRESS_24_BITS;

	/* Instruction */

	sCommand.Instruction 				= 0x99;	/* Reset W25Q128JVSIQ */

	/* Address */

	sCommand.AddressMode       			= HAL_OSPI_ADDRESS_NONE;

	sCommand.Address					= 0;

	/* Data */

	sCommand.DataMode          			= HAL_OSPI_DATA_NONE;

	sCommand.DummyCycles       			= 0;

	sCommand.NbData            			= 0;

	

	if (HAL_OSPI_Command(&hospi, &sCommand, HAL_OSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)

	{

		for(;;);

	}



	/* Enter Quad-SPI Mode --------------------------- */

	/* Common Commands */

	sCommand.OperationType      		= HAL_OSPI_OPTYPE_COMMON_CFG;

	sCommand.FlashId            		= HAL_OSPI_FLASH_ID_1;

	sCommand.InstructionDtrMode 		= HAL_OSPI_INSTRUCTION_DTR_DISABLE;

	sCommand.AddressDtrMode     		= HAL_OSPI_ADDRESS_DTR_DISABLE;

	sCommand.DataDtrMode				= HAL_OSPI_DATA_DTR_DISABLE;

	sCommand.DQSMode            		= HAL_OSPI_DQS_DISABLE;

	sCommand.SIOOMode          			= HAL_OSPI_SIOO_INST_EVERY_CMD;

	sCommand.AlternateBytesMode 		= HAL_OSPI_ALTERNATE_BYTES_NONE;

	sCommand.AlternateBytes				= HAL_OSPI_ALTERNATE_BYTES_NONE;

	sCommand.AlternateBytesSize			= HAL_OSPI_ALTERNATE_BYTES_NONE;

	sCommand.AlternateBytesDtrMode		= HAL_OSPI_ALTERNATE_BYTES_DTR_DISABLE;

	sCommand.InstructionMode   			= HAL_OSPI_INSTRUCTION_1_LINE;

	sCommand.InstructionSize    		= HAL_OSPI_INSTRUCTION_8_BITS;

	sCommand.AddressSize 				= HAL_OSPI_ADDRESS_24_BITS;

	/* Instruction */

	sCommand.Instruction 				= 0x31;	/* Set Status2 W25Q128JVSIQ */

	/* Address */

	sCommand.AddressMode       			= HAL_OSPI_ADDRESS_NONE;

	sCommand.Address					= 0;

	/* Data */

	sCommand.DataMode          			= HAL_OSPI_INSTRUCTION_1_LINE;

	sCommand.DummyCycles       			= 0;

	sCommand.NbData            			= 1;

	reg_data 							= 0x02;	/* Enable QuadI/O Mode */

	

	if (HAL_OSPI_Command(&hospi, &sCommand, HAL_OSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)

	{

		for(;;);

	}

	

	if (HAL_OSPI_Transmit(&hospi, &reg_data, HAL_OSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)

	{

		for(;;);

	}



	/* Enter MemoryMappedMode --------------------------- */

	/* Read Commands */

	sCommand.OperationType      		= HAL_OSPI_OPTYPE_READ_CFG;

	sCommand.FlashId            		= HAL_OSPI_FLASH_ID_1;

	sCommand.InstructionDtrMode 		= HAL_OSPI_INSTRUCTION_DTR_DISABLE;

	sCommand.AddressDtrMode     		= HAL_OSPI_ADDRESS_DTR_DISABLE;

	sCommand.DataDtrMode				= HAL_OSPI_DATA_DTR_DISABLE;

	sCommand.DQSMode            		= HAL_OSPI_DQS_DISABLE;

	sCommand.SIOOMode          			= HAL_OSPI_SIOO_INST_EVERY_CMD;

	sCommand.AlternateBytesMode 		= HAL_OSPI_ALTERNATE_BYTES_4_LINES;

	sCommand.AlternateBytes				= 0xFF;	/* Need for Fast Read QUAD W25Q128JVSIQ */

	sCommand.AlternateBytesSize			= HAL_OSPI_ALTERNATE_BYTES_8_BITS;

	sCommand.AlternateBytesDtrMode		= HAL_OSPI_ALTERNATE_BYTES_DTR_DISABLE;

	sCommand.InstructionMode   			= HAL_OSPI_INSTRUCTION_1_LINE;

	sCommand.InstructionSize    		= HAL_OSPI_INSTRUCTION_8_BITS;

	sCommand.AddressSize 				= HAL_OSPI_ADDRESS_24_BITS;

	/* Instruction */

	sCommand.Instruction 				= 0xEB;	/* Fast Read QUAD W25Q128JVSIQ */

	/* Address */

	sCommand.AddressMode       			= HAL_OSPI_ADDRESS_4_LINES;

	sCommand.Address					= 0;								

	/* Data */	

	sCommand.DataMode          			= HAL_OSPI_DATA_4_LINES;

	sCommand.DummyCycles       			= 4;	/* DUMMY 4Cycle for Fast Read QUAD W25Q128JVSIQ */					

	sCommand.NbData            			= 0;								

	

	if(HAL_OSPI_Command(&hospi, &sCommand, HAL_OSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)

	{

		for(;;);

	}

	

	/* Write Commands */

	sCommand.OperationType      		= HAL_OSPI_OPTYPE_WRITE_CFG;

	sCommand.FlashId            		= HAL_OSPI_FLASH_ID_1;

	sCommand.InstructionDtrMode 		= HAL_OSPI_INSTRUCTION_DTR_DISABLE;

	sCommand.AddressDtrMode     		= HAL_OSPI_ADDRESS_DTR_DISABLE;

	sCommand.DataDtrMode				= HAL_OSPI_DATA_DTR_DISABLE;

	sCommand.DQSMode            		= HAL_OSPI_DQS_DISABLE;

	sCommand.SIOOMode          			= HAL_OSPI_SIOO_INST_EVERY_CMD;

	sCommand.AlternateBytesMode 		= HAL_OSPI_ALTERNATE_BYTES_NONE;

	sCommand.AlternateBytes				= HAL_OSPI_ALTERNATE_BYTES_NONE;

	sCommand.AlternateBytesSize			= HAL_OSPI_ALTERNATE_BYTES_NONE;

	sCommand.AlternateBytesDtrMode		= HAL_OSPI_ALTERNATE_BYTES_DTR_DISABLE;

	sCommand.InstructionMode   			= HAL_OSPI_INSTRUCTION_1_LINE;

	sCommand.InstructionSize    		= HAL_OSPI_INSTRUCTION_8_BITS;

	sCommand.AddressSize 				= HAL_OSPI_ADDRESS_24_BITS;

	/* Instruction */

	sCommand.Instruction 				= 0x32;	/* Page Write QUAD W25Q128JVSIQ */

	/* Address */

	sCommand.AddressMode       			= HAL_OSPI_ADDRESS_1_LINE;

	sCommand.Address					= 0;								

	/* Data */

	sCommand.DataMode          			= HAL_OSPI_DATA_4_LINES;

	sCommand.DummyCycles       			= 0;								

	sCommand.NbData            			= 0;								

	

	if(HAL_OSPI_Command(&hospi, &sCommand, HAL_OSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)

	{

		for(;;);

	}



	/* Set OCTO-SPI as MemoryMappedMode */

	sMemMappedCfg.TimeOutActivation = HAL_OSPI_TIMEOUT_COUNTER_DISABLE;

	sMemMappedCfg.TimeOutPeriod 	= 0;

	if(HAL_OSPI_MemoryMapped(&hospi, &sMemMappedCfg) != HAL_OK)

	{

        for(;;);

    }



}

流れとしてはリセット有効->リセット->クアッドI/Oモード有効->
クアッド高速読み出しコマンド->クアッドセクタ書き込みコマンド
->HALのMemoryMappedMode移行関数呼び出し
となっております。

"クアッドI/Oモード有効"はW25Q128JVSIQ使うなら本来不要ですが
"念のため"突っ込んどきました…一応なくても動作します。

注意点ですがOCTO-SPIは書き込みもMemoryMappedModeが使用可能の為、
クアッド読み出しコマンドの次にセクタ書き込みコマンドの設定が
必須になります！！

なぜそうなっているかというとHALの関数内で書き込みコマンドの
設定まで要求してきやがるからです(別に今回書き込み要らんのに☠)
これも設定しないと先に進めません！

●動作してるところ

MemoryMappedModeで設定したアドレスはSTM32F7のでやった時と同じく
0x90000000からとなりますので過去のリソースが利用できます。
ねむいさんの使い方ではFONTX2ファイルのAnkの方を0x90000000、
Sjis-Kanjiフォントの方は0x90010000から参照しております。
Ankのファイルサイズはどんなにでかくとも65536byte以上にならない
だろうという打算でこのオフセット値を設定してます。

こんな感じでFONTX2(全角&半角)ファイルを仕込んだW25Q128JVSIQから
内蔵フラッシュと変わらない感覚でデータを読み出し表示ができました。
使用したフォントは小夏フォントを12ptのFONTX2に変換したものです。
STM32L5のOCTO-SPIは命令キャッシュだけでデータキャッシュは無い
ですが文字表示や操作感に特にもたついた感じはしてませんね。

デバッガで0x90000000番地を表示してみました。
MemoyMappedMode有効後は内蔵フラッシュと同じようにデバッガで
内部のデータを参照できてますね。

●ところでどうやってQSPI-ROMにデータ書くの？
…今回の記事はこれが最大の難関です…！
OpenOCDではDiscovery系のボードではI/Fの足もQSPI-ROMの品種も
決め打ちのためにQSPI-ROMの読み書きがサポートされていますが
NUCLEO系のやつは足は出ているもののその先に何がつながるかは
わからないのでサポートしているものは何にもありません。

したがってOpenOCDのmmwのコマンドでそれぞれのROMデバイス向けに
上で書いたコードを16進数並べてがむばって定義していくしかないの
ですがねむいさんはそんなことやる気力がないので…
Jtagkey2とSPI-ROM書き込みプログラム"Flashom"にてFONTX2データを
書き込むことにしました。

使用するフォントは12x12pxの小夏フォントです。
AnkはKONATHN12.FNTを、S-JisのKanjiはKONATZN12.FNTを使用します。
上記ファイルについて、私のL5プロジェクトの下記ディレクトリを
参照してください。
./lib/FONTX2/inc/fonts/KONATSU

※小夏フォントについてはTTFファイルで提供されております。
今回はあらかじめFONTX2コンバータでTTF->FONTX2形式に変換
して全角/半角とも使用しております。

まずはSPI-ROMの認識と読み出し。ちゃんと認識されているのを確認。
ついでに読み出したデータは後で使用するのでbin形式で保存します。

JtagKey2(で使用されているFT2232H)のSCKは最大30MHzのスピートなので
配線長はなるべく短くしましょう。5cm以下だとまず問題ないです。
残念ながらげたゲタ基板とNUCLEO基板を合体した状態ではまともに認識
出来なかったのでNUCLEOから5Vだけ拝借してW25Q128JVSIQと一対一で配線
する形になります。なお、CSはプルアップ必須なのですがねむいさんは
念のためCLK除くすべてのI/Oを22kohmでプルアップしてます。
一方CLKはSDMMCと同じく直列終端抵抗を忘れずに！！
ねむいさんはSDMMCと同じ33ohmを直列終端として使用してます。

お次は書き込み用バイナリの作成。
ねむいさんの知る限りではFlashromはアドレスをオフセット指定して
一部の領域だけを書き込むことができず、全領域一気に書き込みしないと
いけないので先に読み出したbinファイルを利用してそこにFONTX2ファイル
を上書きする形で配置しFONTX2を仕込んだROMファイルを作成します。
バイナリ編集プログラム"Stirling"を駆使して0x0000000にANKフォントを
0x00010000にKanjiフォントをそれぞれ上書きモードでコピペ配置します。
オフセットは1バイトでもずれないように注意してください。

Ankは配置されるとこんな感じ

Kanjiはこんなかんじになります。

Stirlingのビットマップ表示だとバイナリイメージはこんな感じです。
まだまだ一杯データ詰め込めますね。

そして書き込み。JtagKey2とFlashromを使用した際は通常のSPIで
書き込むことになりますがW25Q128JVSIQはセクタ書き込み対応なので
16MByteもある容量でも2分もかからず終わっちゃいます。

ねむいさんの公開しているプログラムでは一応作成済みのQSPI-ROM
イメージ(128QVFONT.bin)を添付して簡単な使用手順も書いてますので
酔狂な方はご参考に…。

まぁ私のぶろぐ普段から見られてる方は楽勝だと思います。

そんなわけでSTM32H5からやる予定だったOCTO-SPIでしたがL5でもうまく
使いこなすことができました！
L5でやりたいことは一通り全部やり切ったのでいい感じでSTM32H5へと
繋げて行きたいとおもいます！！

STM32L5を使ってみる2 -FatFsその他の実装-

●いつものやつを実装しよう
前回は144Pin版NUCLEO基板の下駄基板のビジュアルだけ紹介しましたが、
今回はそれを動かすためのファームウエアの要所を紹介していこうと思います。
ねむいさんの"いつもの"ことChaN師のFatFs実装を中心としております。

以下、STM32L5-NUCLEOのFatFs実装例のプロジェクトの要点を掻い摘んで
解説していきたいと思います。

●GCCビルドのためのCortex-M33向けオプション
先ずはmakefileを見ていただいたらお分かりと思いますがCortex-M33は
基本的にCortex-M4Fの進化版と思って頂けたらよいと思います。
GCCコンパイラに与えるCortex-M33コア向けオプションは以下になります。

-mcpu=cortex-m33 -mtune=cortex-m33 -mfix-cmse-cve-2021-35465

-mfix-cmse-cve-2021-35465とかいうのはArmv8-Mコアの脆弱性対策です。
2023年現在の最新のGCCコンパイラはデフォルトでONになっておりいちいち
入れる必要はないかもしれませんが念のため明示してます。

●基本の"き"、タイマーとUARTの実装
STM32に代表されるCortex-M系のコアはほぼすべてにSystickタイマーが
標準装備されております。こちらを1mSecウエイト用のタイマーとして、一方
マイコン周辺機器のタイマー機能を利用してuSecオーダーのタイマーを実装します。
今回はuSec用にはTIM5を利用しました。

以下systick.cより抜粋

	/* Making MicroSecond-Order Timer uses general purpose timer! */

	/* Enable timer clock */

	USEC_TIMx_CLKEN();



	/* calculate TIMx(2 or 5) Prescaler clock(APB1) */

	if(RCC->CFGR & RCC_CFGR_PPRE1){

		if((RCC->CFGR & RCC_CFGR_PPRE1) == RCC_HCLK_DIV2){

			cal_usec_divide = SystemCoreClock/2;   	/* (HCLK(=SYSCLK)*2 */

		}

		else if((RCC->CFGR & RCC_CFGR_PPRE1) == RCC_HCLK_DIV4){

			cal_usec_divide = SystemCoreClock/4; 	/* (HCLK(=SYSCLK)*4)*2 */

		}

		else if((RCC->CFGR & RCC_CFGR_PPRE1) == RCC_HCLK_DIV8){

			cal_usec_divide = SystemCoreClock/8; 	/* (HCLK(=SYSCLK)*8)*2 */

		}

		else if((RCC->CFGR & RCC_CFGR_PPRE1) == RCC_HCLK_DIV16){

			cal_usec_divide = SystemCoreClock/16; 	/* (HCLK(=SYSCLK)*16)*2 */

		}

	}

	

	/* usec wait timer settings */

	TimHandle.Instance 				 = USEC_TIMx;

	TimHandle.Init.Period            = UINT32_MAX;

	TimHandle.Init.Prescaler         = ((cal_usec_divide)/USEC_INTERVAL) - 1;

	TimHandle.Init.ClockDivision     = 0;

	TimHandle.Init.CounterMode       = TIM_COUNTERMODE_UP;

	TimHandle.Init.RepetitionCounter = 0;

	TimHandle.Init.AutoReloadPreload = TIM_AUTORELOAD_PRELOAD_DISABLE;

	if (HAL_TIM_Base_Init(&TimHandle) != HAL_OK)

	{

		/* Capture error */ 

		while (1);

	}

	

	USEC_TIMx->CR1 &= ~(TIM_CR1_UIFREMAP); /* Disable UIF Remap(Must Need!) */

	HAL_TIM_Base_Start(&TimHandle);

最近のHALライブラリは"AutoReloadPreload"構造体が追加されているので
移植の際はご注意ください。また,UIFRemapビットにもご注意ください。

UARTについてはNUCLEO-L552ZE-Q基板上ではSTLinkのVCPとはLPUART
なるもので接続されております。一般のUARTとは多少違いがありますが
やることは同じです。LPUART1、GPIOG7,8をTX,RXとします。
一応LPUART以外のポートも使用できるようにしておりますので詳細は
uart.cupport.cを参照願います(丸投げ)
っとその前にLPUART1を使う際はLPUART1へのクロック供給のほかに
"HAL_PWREx_EnableVddIO2()"の実行も忘れないようにしてください。

またリングバッファによるノンブロッキング送受信なのはいつも通り
なのでスムーズにデータのやり取りができると思います。

●SDMMCドライバの実装・FatFsとの結合
STM32L5にはSDMMCがありますのでこれを実装しますが数年前STM32H7に
実装したSDMMCのドライバをスライド移植するだけのお手軽です☆
ぶっちゃけ今回の移植作業で一番楽でした。

一応使用上の注意なのですがSTM32H7と同じくSTM32L5のSDMMCはDDR
モードが使用可能ですがSDMMCに供給するクロックがバイパスされて
いないと使用不可となりますのでご注意ください。

ねむいさんの作例ではデフォルトではHSI48をSDMMCにバイパスなしで
供給しているためDDRで使用することができませんorz

もしDDR対応のeMMCをお持ちの方はコアクロックを110MHzから100MHzで
動かすとHSI48を使わずコアクロックをSDMMCのクロックにするよう
切り替えますので試してみてください。

STM32L5の最大動作クロックは110MHzなんですけどこういう制約が色々
あって100MHzで動かすほうがよっぽど有利なんですよね～
100MHzとか昨今のマイコンでは遅い部類のクロックですがまぁ初代の
STM32F1とかのMAX72MHz動作と比べたら(消費電力も合間見ると)雲泥の
差ですがすっかり贅沢になってしまいましたね～

STM32H7の実装でも実はひっそり最高速の480MHz対応してますが
こちらもいずれ紹介しようと思います。

●SPIとシリアル接続TFT-LCD
STM32L5のSPIモジュールも言ったって普通のSPIなので実装は容易
でした…が、DMAのほうはちょっと一癖ありました。
ねむいさんが知ってる従来のDMAではなくってDMAのチャネルがマルチ
プレクスされていて柔軟な設定ができるようになっており、逆に扱いに
苦労しましたがExampleを参考に何とかSPIでDMAを吐けるようになって
おります。以下にDMAMUXの設定を抜粋しておきます。
全体は./lib/display/mcu_depend/display_if_basis.cを参照のこと。

#ifdef USE_DISPLAY_DMA_TRANSFER

	/* DMA controller clock enable */

	__HAL_RCC_DMAMUX1_CLK_ENABLE();

	__HAL_RCC_DMA1_CLK_ENABLE();



	/* Configure DMA request LcdDmaHandle */

	LcdDmaHandle.Instance 					= SPILCD_DMA_CHANNEL;

    LcdDmaHandle.Init.Request 				= SPILCD_DMA_REQEST;

    LcdDmaHandle.Init.Direction 			= DMA_MEMORY_TO_PERIPH;

    LcdDmaHandle.Init.PeriphInc 			= DMA_PINC_DISABLE;

    LcdDmaHandle.Init.MemInc 				= DMA_MINC_ENABLE;

    LcdDmaHandle.Init.PeriphDataAlignment 	= DMA_PDATAALIGN_BYTE;

    LcdDmaHandle.Init.MemDataAlignment 		= DMA_MDATAALIGN_BYTE;

    LcdDmaHandle.Init.Mode 					= DMA_NORMAL;

    LcdDmaHandle.Init.Priority 				= DMA_PRIORITY_MEDIUM;

    if (HAL_DMA_Init(&LcdDmaHandle) != HAL_OK)

    {

		for(;;){

			__NOP();

		}

    }

    if (HAL_DMA_ConfigChannelAttributes(&LcdDmaHandle, DMA_CHANNEL_NPRIV) != HAL_OK)

    {

		for(;;){

			__NOP();

		}

    }

    __HAL_LINKDMA(&SpiHandle,hdmatx,LcdDmaHandle);

	

	/* DMA interrupt init */

	/* SPILCD_DMA_IRQn interrupt configuration */

	HAL_NVIC_SetPriority(SPILCD_DMA_IRQn, 0, 0);

	HAL_NVIC_EnableIRQ(SPILCD_DMA_IRQn);

#endif

また下駄基板ではST7789V2を使用したTFT-LCDモジュールを採用して
おりますがこちらのデータ線はSDIとSDOがマルチプレクスされたSDA
となっており、ST7789V2のデバイスIDを取得したいならばSTM32L5側で
SPIのMOSIとMISOを直結し読み出しの際にMISOの信号を正しく受け取る
MOSIをGPIOの入力にわざわざ切り替えてやる必要があります。
以下にそのコードを示します。

void Display_ChangeSDA_If(uint8_t sda_mode)

{

	GPIO_InitTypeDef GPIO_InitStructure;



	if(sda_mode == TFT_SDA_READ){

		/* Enable CTRL Line GPIO Settings */

		DISPLAY_GPIOCLK_EN(DISPLAY_CLK_SDI);

		GPIO_InitStructure.Pin			= CTRL_SDI;

		GPIO_InitStructure.Mode 		= GPIO_MODE_INPUT;

		GPIO_InitStructure.Pull 		= GPIO_PULLUP;

		GPIO_InitStructure.Speed 		= GPIO_SPEED_FREQ_VERY_HIGH;

		GPIO_InitStructure.Alternate 	= 0;

		HAL_GPIO_Init(DISPLAY_PORT_SDI, &GPIO_InitStructure);

	}



	else {

		/* Enable CTRL Line GPIO Settings */

	#if defined(USE_SOFTWARE_SPI)

		DISPLAY_GPIOCLK_EN(DISPLAY_CLK_SDI);

		GPIO_InitStructure.Pin			= CTRL_SDI;

		GPIO_InitStructure.Mode 		= GPIO_MODE_OUTPUT_PP;

		GPIO_InitStructure.Pull 		= GPIO_NOPULL;

		GPIO_InitStructure.Speed 		= GPIO_SPEED_FREQ_VERY_HIGH;

		GPIO_InitStructure.Alternate 	= 0;

		HAL_GPIO_Init(DISPLAY_PORT_SDI, &GPIO_InitStructure);



	#else

		/* Connect SPI pins to Alternate Function */

		/* Restore SPI MOSI pin configuration */

		DISPLAY_GPIOCLK_EN(DISPLAY_CLK_SDI);

		DISPLAY_PERIF_CLK(ENABLE);

		GPIO_InitStructure.Pin			= CTRL_SDI;

		GPIO_InitStructure.Mode 		= GPIO_MODE_AF_PP;

		GPIO_InitStructure.Pull 		= GPIO_NOPULL;

		GPIO_InitStructure.Speed 		= GPIO_SPEED_FREQ_HIGH;

		GPIO_InitStructure.Alternate 	= SRC_SDI;

		HAL_GPIO_Init(DISPLAY_PORT_SDI, &GPIO_InitStructure);

	#endif

	}

}

ちなみにST7789V2側のドライバはデフォルトでは上記の切り替えの
必要なくIDを決め打ちで返すようにしてますのでもの好きな方だけ
SDAマルチプレクス有効にして試してみてください。
SDAマルチプレクスの際はSTM32側のMOSIとMISOをショートしてください。

ST7789V2からIDを読み出す設定でビルドしてデバッガで追っかけてみると
こんな感じにSDAからST7789V2のID(RDID2(0xDB)で0x85が返る)が
読まれてくるのがわかります。

SPI接続で動くモジュールはこんな感じでピン数節約のためにSDIとSDOが
マルチプレクスされてることもあるので覚えておいて損はないでしょう。

というわけでいつものChaN師のファイラー起動からの…

海で働いてるいないさんのpng形式のイラスツをlibpngでデコード！
(LCDのサイズ小さいので画像の一部しか表示できませんが)

libpngのほかにbmp形式はもちろんlibjpegやgiflibでjpg、gif形式
ファイルも表示できますがSTM32L5シリーズはフラッシュメモリ容量が
512kByteしかないのでフォントファイルを乗せつつ画像デコード用の
ライブラリ全部乗せは容量上非常に苦しいです。

そんなときのために容量を食うフォントファイルは外付けのSPI-ROM
にデータを配置してアクセスしたいところですが…
こういう用途に便利なOCTO-SPIという機能がありますが解説が長く
なりそうなので次回に続きます…！

大周回遅れでCortex-M33とSTM32L5はぢめました

●M33出てから何年たってるんだYO
禿ARMから小文字armに代わってもはや数年…ねむいさんもようやっと
ARMv8のCortex-M33コアに手を出しました…！

セキュリティー機能を強化したCortex-M33コアのSTM32L5です！！
ていうか2023年現在はL5をそれぞれの分野別に進化させたSTM32U5や
STM32H5も登場しておりますがまずはL5から行きます！！

実際にはSTM32L552ZET6QUを使用したNUCLEO-L552ZE-Qボードを入手
いたしました。
このNUCLEO基板は(ねむいさんの中での)通称144Pin板NUCLEOと呼ばれる
ものです。NUCLEO基板族の中では最大の大きさとなりますがピン数の
多いマイコンを使っているおかげか外部へ引き出されたポートが固定化
されており、異なるCPU間でも下駄基板を使いまわせられるという
極めて大きな利点があります。

例えばSDMMCのポートはコネクタのこの位置に必ず配置されており、
一度基板をこしらえてしさえすればSTM32H7だろうがSTM32F4だろうが
STM32U5だろうがさらに最新のSTM32H5ですら144Pin版NUCLEOなら
同位置なわけでハードとソフトの切り分けがとても容易になります。

●てわけで144PinNUCLEO基板用汎用下駄基板を作ってみた。

ねむいさんは令和5年になっても自力でプリント基板起こせない雑魚
なのでユニバーサル基板とポリウレタン銅線でせこせこ配線です…。

大動脈の+3.3VラインはLCD,SDMMC,QSPI/OCTO-SPI,I2Sデバイスと大量に
電力を消費するのでNUCLEOの+3.3V出力から取得は不可能です。
したがってVbusの+5Vから+3.3Vを個別に作ることにしました。

ここで登場するのが廉価でぱわふりゃーなLDO、MIC37100-3.3WS-TRです！
LT1963Aが高嶺の花になり、ADP3338がNRNDになってしまった今、高性能
LDO難民となったねむいさんを救うぱわふりゃーなやつです。
ドロップアウト電圧は280mV/1A,10uF以上のセラミックコンデンサで
動作可能でお値段1個240円くらいなので非常にオトクです！！！
こちらでも紹介していますのでヨロシク！

ぇっと話がそれましたがSDMMCの端子はマイクロSDコネクタを採用
しました。それと以前から言っている通り各データラインのプルアップ&
終端の処理は有言実行でしっかり施しております。ねむいさんはCMDと
D0~D3のプルアップを22kohm,CLKの直列終端は33ohmとしました。

結構ラフな実装ですが、CLKに挿入する直列終端の効果は絶大です。
無抵抗状態ではこんな暴れまわっている生意気クロックラインも…

抵抗を直列にぶちこむだけでこんなにわからせられます！これで
安定してSDカードにアクセスができてソフトに専念できますね！

表示デバイスは3年前に購入して温めすぎて腐らせたTFT-LCDモジュール、
ATM0130B3を採用しました。240x240なのに1.3インチととっても小さい
モジュールなのですがこのNUCLEO基板にはまさに最適なヤツです。

このモジュールに使用されているコントローラはST7789V2です。V2とか
お尻に名前が付いていますが2023年現在、このST7789族は電子工作の
お供として必ず名前が上がるくらい有名で、もはやILI9341よりも広く
使用されるようになり、まさに覇権を握ったといってもよいでしょう。
マルチプレックス化されたデータラインからデバイスID取得する方法等の
使用時のコツは場を改めてソフト編で紹介します。

FONTX2等の大容量データの保存先としてメモリマップドでリニアに
アクセスできるQSPIを使用します。選んだデバイスはこれまた電子
工作で定番のSPI-ROMになったWinbondのW25Q128JVSIQです。
ちなみにW25Q128JV自身はQSPIモードをサポートしていますが
(パーツナンバー末尾のIQはデフォルトでQSPIモードの意味)、STM32L5に
おいてはOCTO-SPIというQSPIがさらにパワーアップしたモジュールが
搭載されております。
注：基実装はしましたがたぶんL5版で使用せずH5版Nucleoで使うと思います。
SAIについてもフラッシュ容量の関係でH5版Nucleoで紹介します。
OCTO-SPI実装しました。

そんなわけで下駄基板の紹介だけで一杯一杯になってしまいましたので
ねむいさんのいつものに相当するFatFsの実装等のソフトウエアの紹介は
次回以降順次紹介とさせていただきます。更新頑張るぞい！

また、気づいてる方もいると思いますがすでにおきぱにFatFsの実装例の
L5向けプロジェクトを先行で公開しておりますので興味ある方はこれで
予習をお願いします。

STM32C0を使ってみる2 - OpenOCD正式対応記念 -

20240430追:
秋月さんでNUCLEO-STM32C031C6が販売されました！！！
20240430追:

気づいたら私ってば今月3件も記事更新してますね…北陸侵攻は資金がすぐ
尽きるので気軽に山行けないのとGWの過密期間ずらしの相乗効果でひまが
出来てしまっておかげでしょうか…？それはさておき

さて、去る5月も末になりついにOpenOCDがSTM32C0のフラッシュ書き込みに
正式に対応と相成りました！
ねむいさんもgerritでアシストした甲斐があったものです。

おきぱにあるOpenOCDバイナリは既に対応済みで、もちろんSTM32C0用の
書き込みスクリプトの公開をしております☆

そんでもってSTM32C031-NUCLEO向けの基本プロジェクトも機能を大拡張
して公開しておりますので今のところ誰もC0使ってないようですが、
これからどんどん使ってほしいとおもいます…！

もはや実家のような景色のOpenOCDで書き込んでいるところです。
まぁ10数年やってる同じことだからもう慣れたもんですね～
…ぇ？お前Codelite使ったデバッグ手順の公開はいつだって！？
すみませんそれだけはもうちょっとだけ待ってください・・・・！

その代わりといってはナニですが私のプロジェクトの詳細をちょっと
解説しておきましょう。色んなセンサに対応するために#defineの嵐に
なっておりますがその分細かく各機能の確認が可能です。

私の公開しているSTM32のNUCLEOボード系プロジェクトは簡単質素を
掲げており、他の方が再現しやすいようにペリフェラルも下記機能に
限定して使っております(144Pin系のNUCLEO除く)。

・汎用タイマ(を使ったuSecウエイト)
・UART(割り込み・リングバッファつき)
・I2C(センサ・表示デバイスのドライバ付き)
・1-Wire(GPIO制御による)

まずはI2Cデバイスが何もなくてもLEDとUARTが確認できるものです。
STM32C0-NUCLEO基板を買ってきてすぐに試すことができます。

UARTはSTLinkがVCPの役割もしているので別途USBシリアル変換を
用意する必要もありません☆

お次はI2Cの機能ですが、前回も言いましたがI2Cデバイス用の+3.3V
電源はAVCCからとっているため、SB25ジャンパは必ずしておいて
ください！！！買ったときはジャンパされておらずAVCCがつながって
おりません！STM32C0-NUCLEOの罠です！

NUCLEO系の基板はこんな感じに都合よくI2Cの機能を試すのに丁度よい
ピン配置で線が出ているのでやっけつハーネスを使って外部のI2C
テスト基板に接続しています。

さらにそこからSTN-LCD/OLED用の線をこんな感じで引き出します。
私はブレッドボードは意地でも使わないウーマンなのでこういった
変換基板や、ハーネス製作で汎用性を持たせプロトタイピング性を
高めております。
ちなみにI2Cのバスライン全体のプルアップ抵抗値についてですが
"つぶし"が効くように2.7~4.7kohmを保つように気を付けております。

さらにSCLのクロックはむやみやたらに上げず100kHzをベースとして動作
挿せております。最適化はまず確実に動かしてからするものです。

あとオシロスコープの波形確認用にこのようなブリッジ接続用治具を
作っておくと波形解析に極めて便利です。

秋月さんで売っているこちらのリードアダプタと組み合わせると
安定確実に波形測定が可能となります！

それとI2C程度の速度の波形確認なら今では格安で10万円以下で
USBの2chオシロが手に入るので必ず持っておきましょう。
安物でもあるのとないのとでは開発のスピードが全く違います。
遊びでも投資はケチらずしっかりと行いましょう！

話を戻して5月の更新からデフォルトのドットマトリクス表示デバイスを
I2C-STNから秋月さんで購入可能な入手しやすいI2C-OLEDに替えております。
20240129追:
この時公開していたSSD1309用のドライバでは秋月OLEDを動かせませんでした！！
ごめんなさい！！！
20240129現在は秋月OLED用のSSD1306に対応しております！！！！
20240129追:
STNの方はねむいさんのお気に入りで今みたいにOLEDが自由に使える環境は
まだなかったので時代を感じますね…この辺長くなるのでまた次回にでも。
でもねむいさんこの2.5元I2C-STN液晶いまだ大好きなんですけどね…(一番手前の)

センサは秋月さんで購入できるAosoungのAHT21Bを使用することにします。
実際はAHT2x系ならAHT25やDHT22、AHT20も後述の設定で動作可能です。

main.cのdefineの定義はこのようにしておいてください。
ドットマトリクス表示デバイスはSSD1309を、defineはAHT2X系のテスト
ルーチンとします。

makefileの定義はSSD1309ですがスクロールなどの特殊コマンドは
使用しておらず、基本コマンドだけで動かしているのでSSD1306でも
SH1107でも問題なく動作すると思います(動作は遅いですが)。
20240129追:
この時公開していたSSD1309用のドライバでは秋月OLEDを動かせませんでした！！
ごめんなさい！！！
20240129現在は秋月OLED用のSSD1306に対応しております！！！！
20240129追:

それとソース読んでて気づいているかと思いますがI2Cの各センサ
モジュールとI2CのOLED/STNでSTM32の同じI2Cポートを二重に初期化
しております。

これはドットマトリクス表示ライブラリ(xMSTN)の開発はSPI接続の
ものから行っていた経緯がありI2Cインターフェースのものは後から
追加されたことに由来しております。

はたから見れば二重に初期化してて未意味な無駄コード構成になって
いるように見えますがオシロで波形を確認し、実害はないことを確認
しているので将来の拡張を考えあえてこのようにしております。
決して手抜きではない！

AHT21BをOLEDを変えつつ動かしているところです。
湿度がだいぶ高くなってますがこの記事を書いてる時点で京都も
梅雨入りしたそうです。
以前は対応しておりませんでしたがCRCチェックに対応済みです。
こちらも次回の"いろいろ試す"時に詳細をお伝えします。

DS18B20やAM230x系の1-wire系デバイスももちろん動作します。
プルアップ抵抗は4.7kohmにしておいてください。

BME280をお持ちの方はこちらもしっかり動作します。実はBME280も
シリアルナンバを取得できるのですがこれも次回に詳細をお伝え
しましょう…

そんなわけでまだユーザーがほとんどいないSTM32C0ですが、秋月さんが
STM32G0の後釜でNUCLEOや単体SO8パッケのチップとか販売してくれたら
爆発的に広まると思います！
だから秋月さん頼みますよぅ～！

20240223追:
秋月にSTM32C0参上！！

STM32 Primer2を14年間使い続けた結果

結論から言いますと現役バリッバリで大活躍中です！！
私のSTM32プロジェクトの中で唯一かつ最も成功している作例です！

STM32 Primer2は2009年くらいに発売されたSTM32F103VET6の評価
ボードでした。NUCLEOやDiscoveryがなかった当時は画期的なプロト
タイピングボードだったわけです。

ただ電源の設計に致命的な問題があり、ねむいさんは14年前に
電源の強化を行っております。その後14年経過しましたがねむいさん
改造版電源回路には一切問題はなく-10度～+40度の温度環境下かつ
すさまじい衝撃が常にかかり続けるトレランでも超ド安定動作で
稼働し続けております。

さらに、生セルだったリチウム電池も市販の1000mAhの保護IC付
リポバッテリーにしてさらにハーネスもつけて脱着容易なように
改造しております。

現在は拙作のSTM32Primer2 GNSS Tr@cker専用ハードウエア構成と
なっており、現在はCDTOPとなったGTOP製のGms-G9を使用し、GNSS
ロガーとして機能させております。

●令和のファームウエア大改修
2023年に入って上記GNSSTrackerのファームウエア大改修を行い
ました。細かいバグとか致命的なバグとかいろいろです。

まずC++の予約語扱いになっている__(ダブルアンダースコア)の
インクルードガードの全廃とかウオッチドッグタイマの計算が
オーバーフローしてたとか何よりSTM32F103VETなのになんでか
512Kbyteじゃなくて1MByteでリンカスクリプト組んでたとか
肝心のUSB-MSCとかUSB-CDCのゼロパケットの処理なかったり(!!!)
USB-MSCの時にUSBポートに刺した瞬間に突然デッドロックして
なんでそうなるかわからなくてロジアナで調べてみるとUSBの
コンフィギュレーションの時にEP-INでおだんまりになっている
ことが分かったけど対処がわからずms単位のディレイ突っ込んだら
安定してデッドロックしなくなったけどなんでそうなったか
分らず助けてtsuneoさん！！！！１

…はぁはぁ…STM32F1でこれ以上なにかいじる気力ないので
もう無理ッス・・・・

20230505追加：
ちなみにUSB-MSCの転送速度は以下のようになります。

Read :0.56MByte/Sec(MAX値)
Write :0.20MByte/Sec(MAX値)
なんとWrite(EP-IN)をタブルバッファ化してるのにこの体たらく…
まぁNMEAログはトレラン60kmコース13時間しばきでも7MBもないので
読み出しは直線で0.55MByte/Secあるから許せる範囲内でしょう…

いつも思いますが10数時間フル稼働してもファイルシステムが壊れない
Cha'N師のFatFsのロバスト性の高さにはいつも助けられてます…！
ｻｽｶﾞﾀﾞｧ…
20230505追加終わり：

●今回のエントリここからが本番だ
正直前途の技術的(?)解説とかもうどうでもいいんです！！！！

話は変わりますがねむいさんは現在中部北陸自然歩道と呼ばれる
北陸地域の自然歩道を集中的に攻略しております!

なぜかと言うと北陸新幹線が来春に金沢-敦賀まで開通しその区間
の北陸本線ははぴラインふくいなる頭ハッピーセットみたいな名前の
3セクになってしまいその区間のサンダーバードがなくなってしまう
からです。

サンダーバードが敦賀どまりになる前に敦賀駅から30年前家族旅行で
訪れた金沢駅(正確に言うと兼六園)まで己の足で進み、そこから
どや顔でサンダーバードのグリーン車で京都に帰還するという所業を
達成するのが当面の目的となっております！！！

ちなみに30年前の旅行では特急雷鳥だった記憶なのでサンダーバード
の時点で手遅れだろという意見もありますが在来線特急なのは同じ
なのでノーカンで…

というわけでここから先はSTM32Primer2を使たGNSSロガーと一緒に
北陸攻略をしていった記録をだいぢぇすとでご紹介します…

2022.10.22 敦賀～今庄

すべての出発点の敦賀駅。
ねむいさんは北陸新幹線開通までに金沢に間に合うのか！？

いきなりの洗礼。無意味な廃墟区間400mの上り返しと総延長40km越えの
きつすぎる行程…

しかし一本義っていう良酒に巡り合えた！

2022.10.29 今庄～武生

この時はめっちゃ体調悪く、まだ秋の1デイパスで鈍行オンリーのつもり
でしたがいきなりサンダーバードをショートカットしてしまいました
やっぱ特急はらくちん☆

そして体調不良なのでこういうところほんとつらい。

武生駅はさすがに開けていてお土産もたくさん買って帰還。

2022.12.03 王子保～漆の里河田

もうこのあたりからサンダーバードの移動が当たり前に…資金が…
ちなみに今庄～武生の途中の王子保からなぜかルートが分岐し、
きつい山岳ルートときつい海沿いルートに分かれやがります…☠
今回は山岳ルートの最初の部分となりますが…

日野山っていうきつい山越えその…もう雪積もってやがる…マジか


山から下りて10kmくらい走るとまた山に登らされる…もう桜とか
いいから…

訳が分かりませんがルートの途中で大幅に南に寄り道して600m近くの
山に登らされます…日没ぎりっぎりですよぅ！！

鯖江に帰ったころにはもう真っ暗…なんかコンサートがあったらしくて
場にそぐわないメスガキが大量にいました…なおねむいさんも
ぴちぴちのめすがきなんですけぉ！

2023.01.14 漆の里河田～一乗谷

そろそろ雪の季節…と思ったら雨…雨装備なかったのでぬれねずみに
ところでなんでこのメガネのメスガキは発情してるんですかね…(困惑)

泥だらけになって雲海を見る。

そしてまた無駄に寄り道をする！！こんなんばっかり！！

そして30㎞走ったところでまた山登り…
雪が阻み始めて辛い…

今回でついに福井駅に到着…当面の前線基地になります

2023.02.04 一乗谷～永平寺口

最強寒波の名に恥じぬ積雪量・・
そもそも電車が雪で走ってなかったのでだいぶ足止めを食らいました

…なんだこの雪の量…400m進むのに1時間かかる

なぜか峠越えは雪がなくてよかった♥

永平寺に寄りました。
観光客もだいぶ戻ってますね…そして拝観中にどんどん下がる体温…
ぶるぶる震えてすっかり危ないやつに


今回もボロボロの私…北陸舐めてました…

2023.02.25 武生～梅浦(越前海岸のちょっと手前)

永平寺口から北は最強最悪の浄法寺山がとうせんぼしており、
雪解けまで全く出だしできないので海沿いを攻略攻略しました。

うぉ・・海沿いも標高500m超えると結構積雪が…

日陰は林道もたっぷり積雪が…ぐは…
ラッセル地獄

陶芸の里で道に迷って20分くらいロスorz

織田信長ゆかりの神社だそうです。
ここでかき揚げを買って食べましたが寒さで指がうまく動かない。

海まであと200mくらいでバスが来てしまったので今回はここまで！

2023.03.04 梅浦～波の華温泉

JR西日本はWESTERなるポイントアプリを推しています。

うぉ～！海沿いだ～
久しぶりに雪がないルートだ～！

日本海は豪快ですね～

越前海岸は水仙の里でも有名です

今回はお気楽に温泉も楽しめました♨

そして福井の名物ヨーロッパ件総本山でソースかつ丼定食を
堪能しました☆

2023.03.11 波の花温泉～大味

今回も海沿いからスタートですが…

なんと山の中で分岐を道を間違え4時間もロスする羽目にorz

正規のルートも地獄…！！！

ああああああああもう雪やだぁああああ１１１１！！！！！

心が折れたところで花折峠です

越知山がある越知神社です

大味バス停ってところで終了です…
北陸ルートの中で一番やばかった…

ちなみに"おおあじ"ではなくて"おおみ"だそうです

2023.03.18 大味～三国湊

ｵｲｵｲｵｲまた雨かよぅ…

でも段々晴れてきた…

走っているといつかは超えないといけない最難関、浄法寺山が

三国港駅までやってきました

ゆあぽーと三国で久々にゆったり♨

2023.04.15 永平寺口～芦原温泉(地獄)

逃れられぬ戦いが始まってしまった…
そしてまた雨…

このルートは２年まえから"通行止め"として管理放棄されています…

雨で滑って風がたたきつけてヤバイ岩場！

浄法寺山最後の難関！！腰までの残雪！！！

浄法寺山は拍子抜けするくらい雪がなかった…

丈競山で強風で転倒するということを味わった
あゝ春の嵐

残り懲役30㎞

しかし残り7kmですさまじい暴風雨に遭遇する。
最後まで気が抜けない。

何とか芦原温泉郷にたどり着けました…
温泉も堪能♨

2023.04.22 芦原温泉～大聖寺

芦原温泉郷からスタートです。

三国港から東尋坊に向かいます

東尋坊です。
最高の景色！！風も強い！！

風力発電所のもとを走る。

北潟湖を周回します。

福井県と石川県の県境に！！
ついに福井県を脱出！！

大聖寺までたどり着いてゴール
ようやく石川県に食い込めました。

というわけで駆け足で紹介しましたがねむいさんの北陸攻略は
まだまだ続きます…でもすぐに軍資金が枯渇するので資金繰りを
しっかりしつつ兼六園を目指していこうと思います…

…？お前STM32はどこ行ったって！？
細かいことは気にすんな！です！YO！

STM32C0はぢめました

20240430追:
秋月さんでNUCLEO-STM32C031C6が販売されました！！！
20240430追:

個人ぶろぐでは一番のりかな！？

てわけでリリースしたばかりのSTM32C0シリーズに手を出しました。
立ち位置的にはSTM32G0から機能をシュリンクし、コストを下げて
8/16bitの価格帯に32bitを持ち込む戦略のようです。

評価基板もDiscovery/Nucleo系がすでにリリースされており、
ねむいさんはSTM32C031C6-NUCLEO基板を入手しました。

ところで2021年以降のNucleoはコネクタがUSB-MicroBに変わっているので
ご注意ください…！

そんでもってAVCCが3.3Vに接続されてませんのでご注意ください…
これで30分はまった…orz

基本的な使い方はSTM32G0と全く変わりません。つまりG0からC0への
移植も全く苦ではありませんでした。

ちなみにSTM32CubeC0ライブラリもGithubに登場しております。
STMicro公式からもダウンロードできますが更新が遅く落とすために
登録があって面倒なのでGithubから落としたほうが楽です。

ちなみにuSecディレイに使っている一般タイマですが、HALが微妙に
バージョンアップしていて構造体変数が１個追加されてやがりました。
実はSTM32G0から追加されていたようですが普通に動作してたのでずっと
気づかず、STM32C0では最初うまく動作しなかったところで初めて
気づき30分ほど足止めを喰らいましたorzマニュアルはちゃんと読もう。

というわけでいつものI2Cデバイスをぶら下げて動作させてみます。

こんな感じで何事もなく動作しました☆
AVCCがジャンパされてなかったり変数設定の漏れがあったり
何事もあった気がしたけど気のせいです。

おっとその前に、順番が入れ違いましたがOpenOCDはまだ公式には
STM32C0シリーズのフラッシュ書き込みに対応していませんがgerritに
パッチが上がっています。こいつを適用したOpenOCDをビルドして
さらにSTM32C0用書き込みスクリプトも準備して書き込んでみます。

> "C:¥Devz¥Coreutils¥bin¥make.exe" program

openocd  -s C:/Devz/ARM/OCD/tcl -f interface/stlink-dap.cfg -c "transport select dapdirect_swd" -f target/stm32c0x_swd_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.12.0+dev-00075-g79caea874 (2023-02-23-23:36)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.org/doc/doxygen/bugs.html

dapdirect_swd

Info : STLINK V2J38M27 (API v2) VID:PID 0483:374B

Info : Target voltage: 3.227154

Info : Unable to match requested speed 500 kHz, using 480 kHz

Info : Unable to match requested speed 500 kHz, using 480 kHz

Info : clock speed 480 kHz

Info : stlink_dap_op_connect(connect)

Info : SWD DPIDR 0x0bc11477

Info : [stm32c0x.cpu] Cortex-M0+ r0p1 processor detected

Info : [stm32c0x.cpu] target has 4 breakpoints, 2 watchpoints

Info : starting gdb server for stm32c0x.cpu on 3333

Info : Listening on port 3333 for gdb connections

[stm32c0x.cpu] halted due to debug-request, current mode: Thread 

xPSR: 0xf1000000 pc: 0x08001918 msp: 0x20003000

Info : device idcode = 0x10006453 (STM32C03xx - Rev A : 0x1000)

Info : RDP level 0 (0xAA)

Info : flash size = 32 KiB

Info : flash mode : single-bank

Warn : Adding extra erase range, 0x08006070 .. 0x080067ff

Info : wrote 24688 bytes from file main.elf in 1.217141s (19.808 KiB/s)

Info : verified 24688 bytes in 0.269830s (89.350 KiB/s)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:02

なおOpenOCDでは内部的にはG0と同じくフラッシュ書き込みルーチンが
L4シリーズと同じ扱いになっています。

そんなわけでSTM32C0にも対応したOpenOCDのWindowsバイナリは
すでにおきぱにて公開しております！STM32C0を手に入れた人は
バンバン使っていただけるとありがたいです！

ついでにNUCLEO向けのテストプログラムも公開しております。
新規プロジェクトの取っ掛かりにご利用ください！！

STM32G0使ってみる4 -1wireデバイスをいろいろ使ってみる-

さて、珍しく飽きずに続いているSTM32G0シリーズですが今回は1wireデバイスを
使っていこうと思います。前々回の回路図より1wire用にGPIOポートを一つ開けており、
こいつをフルに活用します。

●DS18B20

金属ケースに入って見えませんが1wireデバイスの代名詞というべきデジタル
温度センサDS18B20です。いろんなマイコンで数多くの作例があり大人気のICです。

基本はVcc,Data,Gndの3線式ですが、ストロングプルアップを行いData線の電力
だけで動かす2線式の動作方式もあります。今回はお手軽に3線式で動かします。

私のSTM32G0のプロジェクトではすでに動作するようになっております。
DS18X20の#defineを有効にしてください。

動かし方はネット上に大量に作例がありますのでそちらに任せるとしてとりあえず
動作させたところです。今回は一つしかつけていませんがDS18B20はROM内に
固有IDがあり、同一のバス上に複数のDS18B20を接続することができます。

さて動作時のデータの波形を記録してみました。
固有IDを指定して温度を取得しているところです(CRC計算は実装してない頃のです)。
Picoscope5444DはDS18x20用のプロトコルアナライザ機能があり、どのような
状態かが一目でわかるので大変便利です！そうだね宣伝だね。

●Aosong製のDHT系の温湿度センサたち

DHT11から始まり今ではAHT20(これはI2C)まで進化しているAosung系の温湿度
センサモジュールが今回はその中でAM2303とAM2322を紹介します。

AM2303はDHT11よりも値段は高いですが性能が良い1-wireのモジュールです。
DS18B20とは互換性はなく独自のプロトコルでデータのやり取りを行います。

AM2322BはAM2303が一まわり小さくなったAM2322にプラスティックのケースで
覆われ、機器に取り付けてすぐに使用可能なモジュールとなっています。
こちらはI2CとDHT系の1wireと2通りのインターフェースを選ぶことができます。
SCLをGNDに落とした状態で電源を投入すると1wireモードになります。
動かし方についてはAM2303と同一になりますがI2cモードで動かすと逆に煩雑に
なってしまうので1wireモードのほうがめっぽう使いやすいです。

てわけでサクッと動かしてみました。ちゃんと検証はしていませんが温度や
湿度の精度もそこそこありそうで実用に足りると思います。

…が…

●AM2322の通信間隔の注意

↑SamplingPeriodが最小2Secだから2秒ごとにアクセスできる！と思い込み2秒ごとに
AM2322と通信して温湿度表示とかやると突然得られるデータがめちゃくちゃになり
しまいには何やってもデータを返さずへそを曲げで黙り込んでしまいます！！！！

AM2303ではこの変な現象にならないのでAM2322(さらにAM2322Bも)
固有の特性だと思います。
RockSolidHead Oyaji様の"AM2322を使ってみた　その3 "の記事にて私が
遭遇したものと酷似した現象に遭遇しております。
I2Cで動作させても同じ感じですね。

先のブログの方はI2Cで動作させており、AM2322がへそ曲げたらAM2322の
電源を一旦落とす荒業で対応しております。ねむいさんは何秒間隔開けたら
へそ曲げないか検証してみました。

条件
　・電源は+3.3V
　・2秒から0.5秒刻みで間隔を広げていきへそ曲げないところを見つけます。
　
結果
　2.0Sec :即死
　2.5Sec :即死
　3.0Sec :即死
　3.5Sec :3分ほどおいてたら死んだ。1時間以上大丈夫なこともあり不安定。
　4.0Sec :1週間連続通電動作させても問題なし。
　4.5Sec :1週間連続通電動作させても問題なし。
　5.0Sec :1週間連続通電動作させても問題なし。

う～～んたぶん個体差のばらつきがあるから5Sec以上間隔開けるようにしましょ

ちなみにAM2322のセンサ素子そのものの反応時間は結構遅いです。

湿度は8Secあります。

温度に至っては最大30Secですって！
5Sec間隔どころか1分でもいいんじゃないかしら…

ちなみにt63%というのは1-exp(-t/τ)で示される一次遅れのシステムにおいて
tのタイミングで0->1のステップ入力を加えたときにtがτの時 1-exp(-1)≒0.6321...
話を戻すとこのセンサでは時定数τは温湿度変化が起こった時変化量の63.2%に
達する時間という意味となります。

すみませんこういう重要なこと今までちゃんと見ないまま動作させていましたが、
このt63%が小さいほど反応性がよいセンサということになりますね。これからは
新手のセンサが現れたら精度や確度だけでなく反応性にも焦点を向けてみます！

STM32G0を使ってみる3 -I2Cライブラリの拡張そしてAHT20-

●AHT20だ！
今回は前回ご紹介したAOSUNGの温湿度センサAHT20を動作させてみます。

AHT20はAOSUNG(ブランド名はASAIR)の新世代の温湿度センサです。これを搭載し、
さらにLDOと信号レベル変換FETを搭載したモジュールをアマゾン経由で入手しました。

そしてつい最近秋月よりDIPモジュール版のAHT25も登場してもう入手されて方もいる
かと思いますが過去世代のAM23xx系よりもさらに使いやすくなっているようですね。

●I2Cドライバを10年ぶりくらいに改造する
さて、私が過去に作成したI2Cライブラリは送信受信ともバイトorワード単位でしか
やり取りすることができず、2バイトコマンドが存在するI2Cデバイスのコントロール
すらできないガバガバっぷりです☠(RaspiのSMBusも同じだし私は悪くなi)

そしてAHT20は温度取得トリガーコマンドが2バイトどころか3バイトもあった…

そんなわけで重い腰を上げてSTM32G0のI2Cレジスタをたたいてマルチバイトを
送受信できる関数を整備してみました。
※受信※

/**************************************************************************/

/*!

	Read RAW MultiByteData Middlelevel.

*/

/**************************************************************************/

uint8_t I2CDev_ReadBytesRaw(uint8_t sla,uint8_t *data,uint8_t count)

{

	/* Wait Bus Busy */

	I2CDevTimer = I2CDEV_SHORT_TIMEOUT;

	while((I2CDEV_PORT->ISR & I2C_ISR_BUSY))

	{

		if((I2CDevTimer--) == 0) return I2CDev_Timeout();

	}



    /* Send Slave Address and Memory Address */

	/* Configure slave address, nbytes, NOLELOAD,NOAUTOSTOP */

	I2C_TransferHandling(I2CDEV_PORT, sla|I2CDEV_SD_READ, count, 0, (uint32_t)(I2C_CR2_START | I2C_CR2_RD_WRN));



	for(int i = 0;i<(count-1);i++){

		*data =  I2CDev_RecvData(I2CDEV_ACK);

		data++;

	}

	*data = I2CDev_RecvData(I2CDEV_NACK);	/* Last data MUST be NACK */

	

	/* Send Stop Condition */

	I2CDev_StopCondition();



    /* Wait until STOPF flag is reset */

	I2CDevTimer = I2CDEV_SHORT_TIMEOUT;

	while(!(I2CDEV_PORT->ISR & I2C_FLAG_STOPF))

	{

		if(I2CDev_ReadNAck() ==I2CDEV_NACK) return I2CDev_Timeout();

		if((I2CDevTimer--) == 0) return I2CDev_Timeout();

	}



    /* Clear STOP Flag */

	I2CDEV_PORT->ICR =I2C_ISR_STOPF;



    /* Clear Configuration Register 2 */

    I2CDEV_PORT->CR2 &= (uint32_t)~((uint32_t)(I2C_CR2_SADD | I2C_CR2_HEAD10R | I2C_CR2_NBYTES | I2C_CR2_RELOAD | I2C_CR2_RD_WRN));



	return 1;

}

※送信※



/**************************************************************************/

/*!

	Write RAW MultiBytes Middlelevel.

*/

/**************************************************************************/

uint8_t I2CDev_WriteBytesRaw(uint8_t sla,uint8_t *data,uint8_t count)

{

	/* Wait Bus Busy */

	I2CDevTimer = I2CDEV_SHORT_TIMEOUT;

	while((I2CDEV_PORT->ISR & I2C_ISR_BUSY))

	{

		if((I2CDevTimer--) == 0) return I2CDev_Timeout();

	}



	/* Send Slave Address and Memory Address */

	/* Configure slave address, nbytes, RELOAD,AUTOSTOP,AUTOSTART */

	I2C_TransferHandling(I2CDEV_PORT, sla|I2CDEV_SD_WRITE, count,  I2C_CR2_AUTOEND|I2C_CR2_RELOAD, I2C_CR2_START);



	/* Send multibytes datas */

	for(int i = 0; i < count ; i++){

		/* Wait until TXIS flag is set */

		I2CDevTimer = I2CDEV_SHORT_TIMEOUT;

		while(!(I2CDEV_PORT->ISR & I2C_ISR_TXIS))

		{

			if(I2CDev_ReadNAck() == I2CDEV_NACK){

				/* Clear STOP Flag */

				I2CDEV_PORT->ICR =I2C_ISR_NACKF;

				/* Clear STOP Flag */

				I2CDEV_PORT->ICR =I2C_ISR_STOPF;

				/* Clear TXE Flag */

				I2CDEV_PORT->ISR |=I2C_ISR_TXE;



				/* Clear Configuration Register 2 */

				I2CDEV_PORT->CR2 &= (uint32_t)~((uint32_t)(I2C_CR2_SADD | I2C_CR2_HEAD10R | I2C_CR2_NBYTES | I2C_CR2_RELOAD | I2C_CR2_RD_WRN));



				return 0;

			}



			if((I2CDevTimer--) == 0) return I2CDev_Timeout();

		}

		I2CDev_SendData(*data);

		data++;

		//I2C_WaitFlag(I2C_ISR_TCR); /* Notneeded in auto STOP */

	}



	/* Send Stop Condition */

	//I2CDev_StopCondition(); /* Notneeded in auto STOP */



    /* Wait until STOPF flag is reset */

	I2CDevTimer = I2CDEV_SHORT_TIMEOUT;

	while(!(I2CDEV_PORT->ISR & I2C_FLAG_STOPF))

	{

		if(I2CDev_ReadNAck() ==I2CDEV_NACK) return I2CDev_Timeout();

		if((I2CDevTimer--) == 0) return I2CDev_Timeout();

	}



	/* Clear STOP Flag */

	I2CDEV_PORT->ICR |=I2C_ISR_STOPF;



	/* Clear Configuration Register 2 */

	I2CDEV_PORT->CR2 &= (uint32_t)~((uint32_t)(I2C_CR2_SADD | I2C_CR2_HEAD10R | I2C_CR2_NBYTES | I2C_CR2_RELOAD | I2C_CR2_RD_WRN));



	return 1;

}

STM32F0以降のI2Cブロックはハードウエアで細かい設定ができる分
ちゃんと仕組みを知っておかないとうまく使いこなせないのでご注意を…！

とりあえずサクッと動きました☆
値段も安くて精度もそこそこなので使い倒せるセンサですね～

次はオシロで波形を観測してみます。
温湿度測定トリガコマンド送信時の波形は以下のようになります。

温度/湿度の受信パケットは以下の波形です。

画像の説明にもある通りCRCチェックが必要なければ6バイトで受信を打ち切って
しまうこともできます。私のプログラムはまだCRCチェックに対応してないので
6バイトめで打ち切りにしています。~~すみません後でCRC実装します。~~
20230929追:
現在おきぱで公開しているソースはCRC値チェックを入れております!
20230929追:

といううわけで10年越しでやっとこI2Cライブラリに拡張性持たせた
改造を行うことができました。これを応用して買いためたままの他の
温湿度センサもガンガン使って行こうと思います！！！
今回の内容を盛り込んだSTM32G0のプログラムも更新しましたのでよろしく！！！

次のネタですが実はもうソースコード見たら実装済みでわかるかと思いますが
1Wireなデバイスたちをオシロの波形と照らし合わせながら動かしてみます。

STM32G0を使ってみる2 -I2Cを使ってみるていうかそれぐらいしか思いつかない-

本年度も後半に入ってしまいましたが今年最初に紹介したSTM32G0を
もうちょっと使って見ようと思います。

さて…本来はこのような構成でI2Cデバイスを使う予定でしたが…
残念ながらリマップの関係上かなり難しいことが判明…オプションバイトを弄らず
自由に使えるのはたったの3ポートのみ！

しかもSTM32G031-Discovery互換ではI2CのSDAで使うPA12(6Pin)が
LEDに取られてしまっているのでお辛い…

そんなわけで折半でこのような回路構成にしてみました。LEDとI2CのSDAを
干渉させないようにわざわざ高速バッファを挟む本末転倒…だがそれがいい
SWCLK,SWDIO,nResetはいつでも使えるようしておきました。先人の方々も
I2C専用で動かすことを前提でこれ使ってる感じですね。

それとあまったPC14(1Pin)は1wireでもぶら下げるとしますか…

ピンの選定については今回は下記の方の記事を参考にしました。
ありがとうございます。

Crescent様
http://meerstern.seesaa.net/article/477348927.html
システム関連ピンのGPIO化に際する注意を詳しく解説されています。

caa45040様
https://qiita.com/caa45040/items/a6ca28ae4b1dfa5c489c
オプションバイトをいじりリスクを負ってたくさん製作されておられます

ねむいさんもS-5851A持っているのでせっかくだからまねさせてもらいます
液晶はもちろんドットマトリクスな中華I2C液晶です！
ROMが32Kbyteあるのでfontx2でankフォントくらいは表示できますね！
液晶については過去記事のこちらをご参照ください。
一時期aitendoで売ってたので持ってる方はまだいるかも！？

特にリマップとかは行わず、パワーオンリセット後のGPIOポートをそのまま
使用するので5PinがI2C2のSCL,6PinがI2C2のSDAとします。

また、S-5851AのアドレスはAD1=1,AD0=0として
0x94(7ビットアドレスだと0x4A)に。

あとはSTM32F03のプロジェクトからI2Cライブラリをサクっと移植し動作完了☆
すごいやっけつ感ですがあっけなくできてしまいました。~~さすが私~~

STM32G0のI2C周りはSTM32F3やF0系とほぼ同じレジスタ構成なのでややこしい
タイミングレジスタの設定値もタイミング値計算機で算出可能です。

STM32のHSIは16MHz,そこからSysClockの64MHzにします。
この設定で100kHzのI2Cクロックを生成する数値を代入します。

オシロスコープで実際の波形をキャプチャしたところです。きっかり100kHzは
出ませんがまぁだいたい近いですね。画像はSTTS751との通信(I2Cアドレス0x72、
7ビットアドレスでは0x39)です。
こんな感じでI2Cの解析にPicoscope大活躍ですわ。
そうだね宣伝だね。

そんなわけで重い腰を上げでSTM32G0の続きやってみましたがあとから来た人に
どんどん先を越されてしまいましたがいつもの感じでやっていこうと思います。

そして…小さな巨人STM32G0で次動かすデバイスは…

こいつだ！
つづく！

おっとーその前に久々の新規プロジェクトになりますがこちらにアップロードして
おりますので自己責任でどうぞ。

今更STM32G0はぢめました

皆様あけましておめでとうございました！！
今年は初詣期間が２か月くらいあるそうなので全然遅くはないですね(手遅れ

さて、先月さらっと紹介したSTM32G0、秋月さんのところで9月に発売されていたのを
12月にようやく手に入れ、そして今ようやく記事にしてみた次第です。

STM32もついに8pinの世界に足を踏み入れてしまいましたがコアのほうもCorte-M0
じゃなくてM0+にパワーアップしています。しかしながらメモリ容量32kb、SRAMも
8kbもあるという小さなボディに大きな力を秘めているわけです！！

メモリ構造も慣れ親しんだSTM32の伝統のアドレス配置で移植も苦ではありません！

このマイコン用のプロジェクトの作成に当たってはSTM32G0-DISCOを参考にさせて
もらっております。

しかしピン数さすがに少なすぎできついですねこれ…どうしたらいいものか…

7,8ピンはSWDで潰れる…そして6ピンはLEDに使用済み…
この小規模なマイコンでもきることはやはり一つ…！I2C！！
PA9がリマップ済みになってるようなので用検討ですね…

ひとまずLチカできるレベルのプロジェクトをF0のプロジェクトをベースに拵えて
見ました…確認用の基板もやっけつ仕事で昔のLPC810基板に乗っけました。

デバッガの接続は定番のSWDです。8PinがSWCLK,7PinがSWDIOあとは電源の配線を
すればつながります。また、購入直後のSTM32G0の接続ではnReset(4Pin)の接続は
特に不要です！(重要)将来的にnResetをGPIO化して使う際には逆に邪魔になって
しまいますので…

OpenOCDはすでにG0シリーズの多くに対応しております。ねむいさんもG0用の
フラッシュ書き込み用のcfgを作成しました。
すでにOpenOCDのバイナリに収録済みです！

まずはVersaloonで書き込みしたところです。

> "C:¥Devz¥Coreutils¥bin¥make.exe" program

openocd  -s C:/Devz/ARM/OCD/tcl -f interface/vsllink_swd.cfg -f target/stm32g0x_swd_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.11.0-rc1+dev-00032-gbd1adcffe (2021-01-23-19:37)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.org/doc/doxygen/bugs.html

Info : VSLLink SWD mode enabled

swd

Info : Versaloon(0x15)by Simon(compiled on Sep 16 2014)

Info : USB_TO_XXX abilities: 0x0000176E:0x010001EF:0xC0000007

Info : clock speed 500 kHz

Info : SWD DPIDR 0x0bc11477

Info : stm32g0x.cpu: hardware has 4 breakpoints, 2 watchpoints

Info : starting gdb server for stm32g0x.cpu on 3333

Info : Listening on port 3333 for gdb connections

target halted due to debug-request, current mode: Thread 

xPSR: 0xf1000000 pc: 0x08000c9c msp: 0x20002000

Info : device idcode = 0x10016466 (STM32G03/G04xx - Rev Z : 0x1001)

Info : flash size = 32kbytes

Info : flash mode : single-bank

Info : Padding image section 1 at 0x08000eac with 4 bytes (bank write end alignment)

Warn : Adding extra erase range, 0x08000eb0 .. 0x08000fff

Info : wrote 3760 bytes from file main.elf in 0.188402s (19.490 KiB/s)

Info : verified 3756 bytes in 0.029309s (125.148 KiB/s)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:01

Win10ではレジスタウインドウ使えませんがInsightのデバッグもすいすい
できちゃいます。

お次はSTLink(STM32-NucleoのSTLink/V2-1)でHLAデバイスとして
書き込んでみます。

> "C:¥Devz¥Coreutils¥bin¥make.exe" program

openocd  -s C:/Devz/ARM/OCD/tcl -f interface/stlink.cfg -c "transport select hla_swd" -f target/stm32g0x_swd_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.11.0-rc1+dev-00032-gbd1adcffe (2021-01-23-19:37)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.org/doc/doxygen/bugs.html

hla_swd

Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD

Info : clock speed 500 kHz

Info : STLINK V2J33M25 (API v2) VID:PID 0483:3752

Info : Target voltage: 3.272439

Info : stm32g0x.cpu: hardware has 4 breakpoints, 2 watchpoints

Info : starting gdb server for stm32g0x.cpu on 3333

Info : Listening on port 3333 for gdb connections

Info : Unable to match requested speed 2000 kHz, using 1800 kHz

Info : Unable to match requested speed 2000 kHz, using 1800 kHz

target halted due to debug-request, current mode: Thread 

xPSR: 0xf1000000 pc: 0x08000c9c msp: 0x20002000

Info : device idcode = 0x10016466 (STM32G03/G04xx - Rev Z : 0x1001)

Info : flash size = 32kbytes

Info : flash mode : single-bank

Info : Padding image section 1 at 0x08000eac with 4 bytes (bank write end alignment)

Warn : Adding extra erase range, 0x08000eb0 .. 0x08000fff

Info : wrote 3760 bytes from file main.elf in 0.156605s (23.447 KiB/s)

Info : verified 3756 bytes in 0.031977s (114.706 KiB/s)

Info : Unable to match requested speed 2000 kHz, using 1800 kHz

Info : Unable to match requested speed 2000 kHz, using 1800 kHz

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:01

こんな感じでサクッと書くこむことができます。

ということでSTM32も8bitマイコンの牙城に続々と乗り込んできたおかげで
小粒マイコンも立派にSTM32として使えるような局面が出てくると思います。

今回はLEDの点滅だけですが豊富なメモリ資源とCPUスピードを利用してI2C
デバイスの制御にちゃれんぢしてみようと思います！

注：プロジェクトはまだ作成中のためもうしばらくお待ちください。

STM32H7を使ってみる6 -CubeH7ライブラリが更新-

←前回　　　　　　　　　　　　　　　　　　　　　　　次回→

今年もあと11か月ですが
あけましておめでとうございます。
当ぶろぐと虹裏メイドをこれからもごひいきに。

さて、昨年からはじめたSTM32H7ですが今月半ばにCubeH7ライブラリが更新して
V1.6.0になっておりました。
私が目についた主だった変更点は以下の点です。

・STM32H7A,STM32H7B追加
・BSPのコードがCubeBSPライブラリへの更改

まず前者について、H7シリーズにメモリと周辺機能をさらに増強したシリーズが
追加されるようです。円形ディスプレイ用に特化したChrom-GRCなる機能が追加です。

海外の掲示板の情報によると既存のH7からSRAMをさらに増強した
STM32H7A3とValueLine版のSTM32HB3名搭載され各Nucleo基板が提供されるだろう
とのこと。20200131の時点ではH7A,H7Bともデータシートすら手に入らないので
CubeH7ライブラリのExampleからしか実際の性能を推測しかできないのですが
楽しみですね☆

そして後者、CubeBSPライブラリですがそもそもSTM32が提供するファームウエア
ライブラリがStandard Peripheral LibraryからHALに変わった際に悪名高き無駄な
抽象化をかましてたのですがそれのBSP版というべきでしょうか、HALにあった
インスタンスの概念がBSPにも流れ込んできやがりました☠

これは何を示すかというとねむいさん側がファイルの置き換えでお手軽に
バージョンアップできなくなりCubeBSPライブラリに合わせて一部コードを
変えざるを得なくなったということです。せっかく夏に血反吐いてH7に
FatFsとかmp3再生とか移植したのにまぢやめて…

…
とぶつくさ言いながらなんとか再移植しました。おきぱのファイルは既に更新済み
なのでご安心ください！パフォーマンスに関してはpngファイルの
デコードで比較してみました。
使用した画像は某女子高の制服着た私のｲﾗｽﾂです！！！~~まだ余裕でいける~~

変更前

変更後
CubeH7ライブラリのバージョンアップによる速度低下の悪影響はほぼないようですね…
これが悪くなったらわざわざ上げる価値がないですからね。

ついでにIJG-Jpegライブラリもバージョンアップしたのでこっちも移植しました。

変更前

変更後

ぁ…あれ…すごい速度下がる…(脂汗

…
(しまった…オチがない…)

ぇっと今年もこんな感じでがむばります！！！！！

STM32H7を使ってみる5 -キャッシュ・ワンダリング(後篇)-

←前回　　　　　　　　　　　　　　　　　　　　　　　次回→

このぶろぐの読者様的にはねむいさんがうっかり「MDMAを使ってみる」などという
公序良俗（こうじょりょうぞく）に大幅に反したタイトルの記事を書いてしまって
警察屋さんに絞られる展開を期待してるのでしょうがそんな安易な手には引っかかり
ませんよぅ！！！てうかそんな明らかにヤバイ合成(まぜ)モノより天然自然のta
ダメ！ゼッタイ！！！

さて今回はエラッタのせいで強制的にライトバックにせざるを得なくなってしまった
キャッシュメモリでDMAとどうやってうまいこと付き合っていくかを解説していこうと
思います。
なお、DMA使うメモリ領域だけキャッシュ不可にするという軟弱な措置はねむいさんの
ライブラリに存在しませんのであしからず！！！！！！！！

●注意すべき前提
キャッシュがきいた状態のメモリアクセスでは、あるひとまとまりのデータの塊
に加えてそのデータ塊のアドレス境界で処理すべきという大大前提があります。
これはキャッシュを搭載するどのCPUでも同一となります。

｢あるひとまとまり」はキャッシュメモリ上のキャッシュラインのバイト数を示し、
｢アドレス境界｣はアドレスがキャッシュラインのバイト数分のビットで同一である
ということを示します。

Cortex-M7においてはデータキャッシュのキャッシュラインサイズが32Byteのため、
｢32バイトごと」かつ｢アドレスの32バイトに当たる下位5ビットが0x0_0000｣
であることが求められます。

過去にSTM32F7でキャッシュ比較したときはあらかじめDMA先を32バイトの境界に
合わせ4kByte刻みで転送という限定的な環境でやってたのでキャッシュコントロールは
かなり端折った記述をしておりましたが今回は腰を据えて汎用的に扱えるよう
落とし込んて行きます。

●DMAで読み取る場合(SDMMCのIDMAの場合)
実はライトバック設定の場合、READの取り扱いが一番やっかいです。
理論的には読み出し先のメモリのキャッシュをInvalidateしてやればよいはずなのですが
なぜかそうは問屋が卸さず、私が試した限りでは必ずCleanもしなけらばならないことが
分かりました?なんでだＹＯ！

DRESULT SD_read(BYTE lun, BYTE *buff, DWORD sector, UINT count)

{

	DRESULT res = RES_OK;

    uint32_t timer = SysTick->VAL + SD_DATATIMEOUT;



    /* first ensure the SDCard is ready for a new operation */

    while((SD_GetCardState() == SD_TRANSFER_BUSY))

    {

		if(timer < SysTick->VAL)

		return RES_NOTRDY;

    }



#if defined(SD_DMA_MODE) && !defined(SD_POLLING_MODE)

    /*

       Force Cache Data Lines content write back to memory and Invalidate them.

       Someone (CPU) might be still accessing those cache lines so we need to

       flush/clean recent content to memory and purge/invalid cache lines before

       allowing Hardware to access RAM.

     */

	if((uintptr_t)buff & 0x3)	/* Check 4Byte Alignment */

	{	/* Unaligned Buffer Address Case (Slower) */

		for (unsigned int secNum = 0; secNum < count ; secNum++){



			SCB_InvalidateDCache_by_Addr ((uint32_t*)dmabuf, SECTOR_SIZE);



			if(SD_ReadBlocks_DMA((uint32_t*)dmabuf, (uint32_t)(sector+secNum), 1)!= MSD_OK)

			{

				MSG_PRINTF("Read error on unaligned buffer¥n");

				res = RES_ERROR;

			}



			memcpy(buff+secNum*SECTOR_SIZE, dmabuf, SECTOR_SIZE);

		}

	} else {

		/* Aligned Buffer Address Case (Faster) */

		SCB_CleanInvalidateDCache_by_Addr((uint32_t*)buff, count * SECTOR_SIZE);



		if(SD_ReadBlocks_DMA((uint32_t*)buff, (uint32_t)sector, count) != MSD_OK)

		{

			MSG_PRINTF("Read error on DMA¥n");

			res = RES_ERROR;

		}

	}

#else

	if(SD_ReadBlocks((uint32_t*)buff, (uint32_t)sector, count) != MSD_OK)

	{

		MSG_PRINTF("Read error on polling¥n");

		res = RES_ERROR;

	}

#endif

	return res;

}

↑CMSIS_v5を使ってSTM32H7でDMA転送(READ)する場合です。
READアクションをとる前にSCB_CleanInvalidateDCache_by_Addr()を実行します。
Invalidateだけではだめです。CleanしてInvalidateです。ここテストに出るので
覚えておきまししょう!そうせざるを得なかった例がこちらの議論にもありますが正直
私もピンときません。だれか詳しい解説を教えてください。
当たり前ですがデータが32Byteの倍数かつ32Byte境界にﾋﾞｯﾁﾘそろった完全読み出し
専用のメモリ領域ならInvalidateだけで問題ないです。ぇ？自分で答え言ってるだろ
って？ねむいさんは他の人の同意とか同情がほしいのですよぅ！
ぁあそうだ、ライトスルーもInvalidateだけでおｋ、エラッタでどうせ使えませんが。

それと上記のルーチンでは先の述べたアドレスの丸め込みがないじゃないかと思う
方がいると思いますがCMSIS_v5ライブラリのほうに丸め込み処理が取り込まれており、
ｺﾞﾃｺﾞﾃしたマクロ組まなくてもシンプルに記述できるようになっています。
STマイクロのCubeライブラリではこちらの更新がまだ取り入れられておらず、自前の
アドレス丸め込みマクロが記述されておりますので二度手間にならないようにご注意
願います。

そんでもってCleanInvalidateしたことによるキャッシュコントロールによる
オーバーヘッドが懸念されますがH7はCPUのコアの速度がMAX480MHzも出るので
多分気にはならないとおもいます(投げやり)

●DMAで送信する場合(SDMMCのIDMAの場合)

DRESULT SD_write(BYTE lun, const BYTE *buff, DWORD sector, UINT count)

{

	DRESULT res = RES_ERROR;

    uint32_t timer;





#if defined(SD_DMA_MODE) && !defined(SD_POLLING_MODE)

    /*

       Force Cache Data Lines content write back to memory.

       Someone (CPU) might be still accessing those cache lines so we need to

       flush/clean recent content to memory before

       allowing Hardware to access RAM.

     */

	if((uintptr_t)buff & 0x3)	/* Check 4Byte Alignment */

	{	/* Unaligned Buffer Address Case (Slower) */

		for (unsigned int secNum = 0; secNum < count; secNum++){



			memcpy(dmabuf, buff+(SECTOR_SIZE*secNum), SECTOR_SIZE);



			SCB_CleanDCache_by_Addr((uint32_t*)dmabuf, SECTOR_SIZE);



			if(SD_WriteBlocks_DMA((uint32_t*)dmabuf, (uint32_t)(sector+secNum), 1) != MSD_OK)

			{

				MSG_PRINTF("Write error on unaligned buffer¥n");

				res = RES_ERROR;

			}

		}

	} else {



		SCB_CleanDCache_by_Addr((uint32_t*)buff, count * SECTOR_SIZE);



		if(SD_WriteBlocks_DMA((uint32_t*)buff, (uint32_t)sector, count) != MSD_OK)

		{

			MSG_PRINTF("Write error on DMA¥n");

			res = RES_ERROR;

		}

	}

#else

	if(SD_WriteBlocks((uint32_t*)buff, (uint32_t)sector, count) != MSD_OK)

	{

		MSG_PRINTF("Write error on polling¥n");

		res = RES_ERROR;

	}



#endif



	/* ensure the SDCard is ready for a next operation */

	timer = SysTick->VAL + SD_DATATIMEOUT;

	res = RES_ERROR; /* Timeout */

	/* block until SDIO IP is ready or a timeout occur */

	while(timer > SysTick->VAL)

	{

		if(SD_GetCardState() == SD_TRANSFER_OK)

		{

			res = RES_OK;

			break;

		}

	}



	return res;

}

↑CMSIS_v5を使ってSTM32H7でDMA転送(WRITE)する場合です。
WRITEのほうは単純明快、転送前にCleanしてやるだけです！
READのほうが扱いがめどくて誤れば致命的なのがなんとも…

ちなみにSTM32のマイコンにおいてREAD/WRITEいずれの場合も
DMAコントローラのWORD(4Byte)制限があるのでそれも加味しておきましょう。

●DMAで送信する場合(SAIのCircularDMAの場合)
ライトスル―が使えなくなったせいでいろんなコードにキャッシュコントロールを
突っ込まざるを得なくなってしまいましたがねむいさんのいつものではAudio再生に
SAIのCircularDMAを使用しており、こちらもきっちり対策しております。

ねむいさん最初にH7触った時に無対策で挑んで見事返り討ちに会いました。サンプル
音源のBeachBoysのハーモニック・サウンドがﾌﾞﾋﾞﾋﾞﾋﾞｯﾌﾞｯというげりうんちみたいな
汚い音が得られてしまったのですが移植時にcodecの音量設定が最大になっていたのも
気づかずげりうんち音で鼓膜が破壊されるかと思いましたがどうでもいいですね。

SAIの場合はWrite専用のぶっぱなのでCleanだけで問題ないです。
問題は挿入する箇所です。

/* on the first buffer fill up,start the dma transfer */

	if(EVAL_AUDIO_Init(OUTPUT_DEVICE_BOTH, DEFAULT_VOLUME, (uint32_t)mp3FrameInfo.samprate))

	{

		MSG_PRINTF("Mp3Decode: audio init failed¥r¥n");

		nResult = -4;

		break;

	}

	/* I2S DMA Transfer First Trigger */

#if defined(STM32H7XX)

	SCB_CleanDCache_by_Addr((uint32_t*)g_pMp3DmaBuffer, MP3_DMA_BUFFER_SIZE);

#endif

	/* Needed to AAC_DMA_BUFFER_SIZE*2,16-bits audio data size(2Byte) */

	/* See more detail,BSP_AUDIO_OUT_Play()							  */	

	EVAL_AUDIO_Play(g_pMp3DmaBuffer, MP3_DMA_BUFFER_SIZE*2);

↑転送なのでCleanのみでおｋ(mp3.support.cにて)
まずはCircularDMAの最初のキックです。まぁこれは当然。
ていうかなんかtypoしてますね私orz AACじゃなくてここではMP3です。

if(unDmaBufMode == INIT_RINGBUF || unDmaBufMode == FULL_RINGBUF)

{

	/* Check FirstHalf Transfer in LastHalf and BufferInit Mode */

	if(em & TRANSFER_FIRST_HALF)

	{

		MSG_PRINTF("Mp3Decode: DMA out of sync (expected TC, got HT)¥r¥n");

		nResult = -3;

		break;

	}

	else{

		g_pMp3DmaBufferPtr = g_pMp3DmaBuffer + (MP3_DMA_BUFFER_SIZE/2); /* 16bit address pointer calc */

	#if defined(STM32H7XX)

		SCB_CleanDCache_by_Addr((uint32_t*)g_pMp3DmaBufferPtr, MP3_DMA_BUFFER_SIZE);

	#endif

	}

}

else /* unDmaBufMode == HALF_RINGBUF */

{

	/* Check LastHalf Transfer in FirstHalf Mode */

	if(em & TRANSFER_LAST_HALF)

	{

		MSG_PRINTF("Mp3Decode: DMA out of sync (expected HT, got TC)¥r¥n");

		nResult = -3;

		break;

	}

	else{

		g_pMp3DmaBufferPtr = g_pMp3DmaBuffer;

	#if defined(STM32H7XX)

		SCB_CleanDCache_by_Addr((uint32_t*)g_pMp3DmaBufferPtr, MP3_DMA_BUFFER_SIZE);

	#endif

}

お次はこちら。
半分転送完了割り込み後の処理で次の転送予定のバッファにCleanをかけます。
g_pMp3DmaBufferPtrに次に転送するバッファのアドレスをコピーした後Cleanです。
g_pMp3DmaBufferPtrはuint16_tのポインタなので注意が必要です。

●DMAじゃないけどLTDCもキャッシュと競合する
ライトスルーが使えなくなった弊害はDMAと同じくキャッシュコヒーレンシーを
求められるLTDCにも波及します。

static void disp_blt (

	int left,				/* Left end (-32768 to 32767) */

	int right,				/* Right end (-32768 to 32767, >=left) */

	int top,				/* Top end (-32768 to 32767) */

	int bottom,				/* Bottom end (-32768 to 32767, >=right) */

	const uint16_t *pat		/* Pattern data */

)

{

	int yc, xc, xs;

#if !defined(USE_TFT_FRAMEBUFFER)

	int xl;

	uint16_t pd;

#endif



	if (left > right || top > bottom) return; 	/* Check varidity */

	if (left > MaskR || right < MaskL  || top > MaskB || bottom < MaskT) return;	/* Check if in active area */



	yc = bottom - top + 1;			/* Vertical size */

	xc = right - left + 1; xs = 0;	/* Horizontal size and skip */



	if (top < MaskT) {		/* Clip top of source image if it is out of active area */

		pat += xc * (MaskT - top);

		yc -= MaskT - top;

		top = MaskT;

	}

	if (bottom > MaskB) {	/* Clip bottom of source image if it is out of active area */

		yc -= bottom - MaskB;

		bottom = MaskB;

	}

	if (left < MaskL) {		/* Clip left of source image if it is out of active area */

		pat += MaskL - left;

		xc -= MaskL - left;

		xs += MaskL - left;

		left = MaskL;

	}

	if (right > MaskR) {	/* Clip right of source image it is out of active area */

		xc -= right - MaskR;

		xs += right - MaskR;

		right = MaskR;

	}

	Display_rect_if(left, right, top, bottom);	/* Set rectangular area to fill */

#if defined(STM32F7XX) || defined(STM32H7XX) /* Flush Cache Datas */

	SCB_CleanDCache_by_Addr((uint32_t*)pat, xc*yc*2);

#endif

#if defined(USE_TFT_FRAMEBUFFER)

	Display_wr_block_if((uint8_t*)pat, xc*yc);

#else

	do {	/* Send image data */

		xl = xc;

		do {

			pd = *pat++;

			Display_wr_dat_if(pd);

		} while (--xl);

		pat += xs;

	} while (--yc);

#endif

}

↑ts_fileload.cにて
Cha'N氏のTinyJPEGライブラリででコード後のデータをブロック転送するときにClean
しないと化けます。DMA2DだけじゃなくCPUが介在するFIFOコピーでも化けます。

大量のデータを一気に吐かせるimgファイル(動画データ)ならその都度キャッシュも
総入れ替えとなるので化けないようですが中途半端に転送サイズが小さいとだめな
ようですね。本来なら動画再生のほうもClean突っ込んでやるのが筋なんですけど。

なお、前回触れたライトアロケートキャッシュ設定にしてしまった場合は逆汚染に
よってせっかく書き込んだデータが潰されてしまうためデータの書き込み都度に
Cleanをしてやらないといけなくなってしまいこれによるオーバーヘッドで見かけの
処理速度が大きく落ちてしまいます。
前回も言いましたがSAIでもビットレート上がるとﾌﾟﾁﾌﾟﾁノイズ入りまくり使い物に
なりませんしやはりSTM32でライトアロケート設定は使わないのが無難です。

というわけで癖が非常に強いSTM32H7ですが、その特性を把握して上手に
コントロールすれば本来の性能をいかんなく発揮できることがわかりました。
STM32F7で十分と思い、食わず嫌いしてましたがSTM32H7、良い感じです！

STM32H7を使ってみる4 -キャッシュ・ワンダリング(中篇)-

←前回　　　　　　　　　　　　　　　　　　　　　　　次回→

自宅のPC環境を完全にWin10に切り替えました。
ハードウエアも11年ぶりに新調してメモリも16GBも乗っけてます！！！！
システムディスクも最新のM.2SSDに換装してこれで向こう20年は戦うことが
できるでしょう！！！！！

さて、今回は前回説明した各種キャッシュ設定がパフォーマンスにどう影響
してくるのかを実動作を交えて説明していこうとおもいます。

比較ということでlibpng(倍精度浮動小数点演算あり)のデコード/表示時間を計測して
いきます。ﾃｽﾂ用png画像は自作の虹裏的美少女ｲﾗｽﾂを使用してまいります！
突っ込みは受け付けません！！いないさんかわいい！!1！！！1！

また、png画像を読み出すストレージは以前紹介した産業用MicroSDの64GB品を使用
します。安くて信頼性があって使い勝手が良いので重宝します♥

●キャッシュ無し

まずはデータキャッシュそのものを無効にします。
本当はAXI-SRAMだけ無効にしたかったのですがなぜかpngのデコード時にHardFaultに
なってしまったので仕方なくぜんぶキャッシュOFFにしてます。

キャッシュ効いてないせいで遅いのですがAXIバスのクロックが200MHzと高速なので
それでも十分"早い"ですね…

●ライトバック&ライトアロケートなし

こちらはいつもので公開しているキャッシュ設定となります。
ライトスルーのエラッタが認知されてしまった今これに頼らざるを得ません。

●ライトバック&ライトアロケートあり

ライトアロケートなしとほとんど変わらず誤差程度です。

これならライトアロケートありでいいじゃんとお思いでしょうが…

残念ながらLTDCと相性が非常に悪くLTDCが管轄するフレームバッファ領域にこの
設定を行っているとご覧の通り表示が崩れてしまいます…
一応対策できないこともないですがキャッシュコントロール関数をあちこちに放り
こまないといけないため全く現実的ではないです。

それならSDRAMにはその設定しないでAXI-SRAMだけにすればとお思いででしょうが
ねむいさんもそうしようと思ったのですがなんとSAIとも相性が悪く高ビットレートの
音声再生時にﾌﾞﾁﾌﾞﾁノイズが入りやがりますorzこちらもあちこちでキャッシュコント
ロールしまくったら問題ないのですがそんなんするくらいならライトバック＋ライト
アロケートなしのほうでいいやとなり今に至った次第です。

●ライトスルー

今となってはエラッタで禁じ手になったライトスルーモードです。
ライトバックより遅いですがキャッシュ無しより断然早い理由は実メモリに書き込みに
いったときにライトバッファが効いて速度が上がっているからです。
いちいちcleanしないで済むから楽だったんですけどねライトスルー…

●おまけ・ｶﾘｶﾘﾁｭｰﾝのF7

STM32F769I-Discoでも同じMicroSDを使ってやってみました。
フレームバッファを除くDMAの送受信バッファ・各変数・ヒープ領域をキャッシュ
しなくても超高速に動作できるDTCMに設定して同じようにやってみたのがこちら。
H7と比べるとコアクロックが1/2の200MHz動作なのですが意外と健闘してます。
F7シリーズではDTCM領域でもDMAできるのでこのような芸当ができるのですが
H7は直接できなってしまいましたのでライトスルーが使えなくなったのもあって
DMAするだけでもいろんな工夫が必要です。

次回はSTM32H7でキャッシュを効かせた状態でDMAをどのように安定して動かして
いけば良いのかを解説していこうと思います。

20191104追:
jujurouさんがF7ではSDRAMのライトバック+ライトアロケートなしでもDMA2Dで
表示おかしくなると報告されているのでねむいさんも追って知らべてみました…

が…(STM32F746G-Discoveryで試した)

ううむねむいさんのいつものじゃどういう状況でもデータ化けしてぬぇ…
※9月度版の時点でライトバック版に変更済みです。

キャッシュを効かせたRAM領域にフレームバッファを確保してLTDCを動作させている
時点でDMAしてる時と同じようになりDMA2DせずともキャッシュとLTDCコントローラ
との干渉が発生してしまいます。これはライトアロケートあるなしに関係は
ないのでライトバックではデータ転送前に必ずキャッシュのCleanが必要です。

ねむいさんのいつものでこれに引っかかった例がChaNさんのjpegライブラリを使い
jpegファイルを表示させようとした時で、disp_blt関数内で転送直前にクリーンを
行うことにより対策しております。

そして前回も簡単に説明しましたがキャッシュコントロールをしているにもかかわらず
ライトアロケート時に表示が崩れてしまう原因は書き込みキャッシュミス時に実メモリ
からデータを読み出しキャッシュラインに展開している動作そのものにあります。
実メモリ(SDRAM)からのread動作によってキャッシュラインが逆汚染され、結果として
寄生Evictionが起こりまくり表示が崩れてしまうことになります。
データキャッシュサイズ上限以下の容量でチマチマ書き換える…たとえばFONTX2の
表示とかの時に一番崩れやすくなります。

↑こんな感じに崩れます。
これはLTDCに限らずSAIとかの基本書き込みっぱなしのぶっ放しのペリフェラルでも
起こりますが長くなりそうなので次回にでも解説します。

STM32H7を使ってみる3 -キャッシュ・ワンダリング(前篇)-

←前回　　　　　　　　　　　　　　　　　　　　　　　次回→

今から4年以上前、STM32F7ではぢめてキャッシュという概念に対峙し、分かった
つもりでお茶を濁してきましたがH7になった今どうしても正面から向き合わざるを
得ない事態になってしまいました…それも最悪な形で！！

●Cortex-M7のキャッシュにエラッタ発覚!

オイオイオイ死ぬわ私。(一般には今年春くらいに知れ渡った内容です)
要約しますとCortex-M7系マイコンでキャッシュポリシーをライトスル―にした状態で
Double-WORD(ARMの場合8バイト)の読み書きを同一のアドレスで行った時に、読み
出しの時にデータが壊れる事があるという内容…しかも現行の全リビジョン…
そしてカテゴリーAとかいうﾌｭｰｼﾞｮﾝｼﾞｬｯｸした剣崎さんでも不覚をとりかねない
クリティカルっていうか実質使用禁止設定判定なエラッタ…すざけんな！！１１１！
全文はこちらで読めますので各自把握しておいてください。

※おきぱのSTM32F7/H7向けFatFsデモはライトバックを
使用するようにすでにコードを修正済ですので安心してお使いいただけます。

STM32F7/H7側の障害情報ではF7はもちろん最新のH745/755に至るまで当エラッタが
網羅され、全滅状態ですorz

つまり、STM32F7/H7でキャッシュを使用する際はキャッシュの取り扱いが面倒な
ライトバック以外にキャッシュポリシーがとれないことを示しますorz

ぁーぁ…

●ひとまずSTM32H7のキャッシュのおさらいっ
まずはけしかん様のブログ記事も熟読の上で…

STM32F7/H7に搭載されてたキャッシュメモリは命令(I)とデータ(D)用に独立した
キャッシュが設けられております。キャッシュの方式はI/D両者ともセット・
アソシエイティブという回路規模とキャッシュ性能を折半した方式が採られていて、
とりわけデータ用では4ウェイセット・アソシエイティブという方式となっています。
ｳｴｰｲが4つもあってどんだけリア充なんだＹＯ！

そしてキャッシュポリシーとしてはSTM32F7/H7は下記の3タイプ存在します。
1.ライトスルー(ライトアロケート無し固定)
　キャッシュに書き込みと同時に実メモリにも常に書きこむ。
　キャッシュの取り扱いは簡単だが動作は一番遅い。
　使い勝手一番良かったのにエラッタのせいで使用不能！！１１！１

2.ライトバック・ライトアロケート有り
　キャッシュラインがいっぱいになるかCleanしないと実メモリに書きこまない。
　書き込み時キャッシュミスした場合1ライン分実メモリから読みだして
　キャッシュラインに展開する。ちょっと遅い。
　頻繁に読み書きする変数領域向けなのでフレームバッファのような書きっぱの
　用途では著しく不利になるのでむやみに設定してはならない。

3.ライトバック・ライトアロケート無し
　キャッシュラインがいっぱいになるかCleanしないと実メモリに書きこまない。
　書き込み時キャッシュミスした場合も実メモリから読みだす動作はしない。
　理論上一番早い。ライトスルーが封じられた今これが一番無難。

1～3のいずれも読み込み側動作(リードアロケート)はすべて同様に行われる。

1.はエラッタのせいで死に設定なので2.や3.を選びます。尤もライトバック・ライト
アロケートありでもmemset等の関数で同じデータを書いていくような動作を検知して
自動的にライトアロケート無しに動的に切り替わりキャッシュが動くらしいです
(↑ほんまかいな)

詳しい解説はAPSさんのサイトにあります。
Cortex-Aのキャッシュについての解説ですがCortex-M7も動作や設定は同一です。

●で、具体的な設定はどうすればよいのか
Cortex-M7に置いてはMPU(メモリプロテクションユニット)からキャッシュポリシーの
設定を行います。ねむいさんのいつもののhw_config.cにあるMPU設定のサブルーチン
より、AXI-SRAMの設定を例に紹介します。

	/* Configure the MPU attributes as Write-Back/No-Write-Allocate for AXI-SRAM D1 */

	MPU_InitStruct.Enable 			= MPU_REGION_ENABLE;

	MPU_InitStruct.BaseAddress 		= 0x24000000;

	MPU_InitStruct.Size 			= MPU_REGION_SIZE_512KB;

	MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;

	MPU_InitStruct.IsBufferable 	= MPU_ACCESS_BUFFERABLE;

	MPU_InitStruct.IsCacheable 		= MPU_ACCESS_CACHEABLE;

	MPU_InitStruct.IsShareable 		= MPU_ACCESS_NOT_SHAREABLE;

	MPU_InitStruct.Number 			= MPU_REGION_NUMBER0;

	MPU_InitStruct.TypeExtField 	= MPU_TEX_LEVEL0;

	MPU_InitStruct.SubRegionDisable = 0x00;

	MPU_InitStruct.DisableExec 		= MPU_INSTRUCTION_ACCESS_ENABLE;

	HAL_MPU_ConfigRegion(&MPU_InitStruct);

AXI-SRAMの512kByte丸々ライトバック・ライトアロケート無しの設定をする場合
上記のようにします。

MPU_InitStruct.IsBufferable 	= MPU_ACCESS_BUFFERABLE;

MPU_InitStruct.IsCacheable 		= MPU_ACCESS_CACHEABLE;

MPU_InitStruct.IsShareable 		= MPU_ACCESS_NOT_SHAREABLE;

↑特にこの3行は重要です。ライトバッファ有効・キャッシュ有効でライトバック
となります。また、SHAREABLEの設定は必ずMPU_ACCESS_NOT_SHAREABLEに
しておいてください！ここをMPU_ACCESS_SHAREABLEにするとキャッシュを
無効にしたのと同じになってしまいます。実に罠設定です。

ちなみにこの超重要な情報はNXPのM7コアのマイコンiMXのアプリケーションノートに
明記されております。
しかしSTのマニュアルやアプリケーションノートには何所にも全く書いておらず、
罠にはまってキャッシュの効力殺してるの気づいてない人多いんじゃないかと☠

SHAREABLE有効にしつつキャッシュ動作を有効させる方法もありますが今回の
システムではまだ利用価値が無いので割愛します。

また、ライトアロケート有りで行きたい場合は
MPU_TEX_LEVEL0->MPU_TEX_LEVEL１に変更します。
でもCortex-M7コアでライトアロケートありするくらいならエラッタ付き
ライトスルーにした方が10000000000倍マシです☠
こちらの比較も次回以降解説しますね。

	/* Configure the MPU attributes as Write-Back/No-Write-Allocate for AHB-SRAM1 D2 */

	MPU_InitStruct.Enable 			= MPU_REGION_ENABLE;

	MPU_InitStruct.BaseAddress 		= 0x30000000;

	MPU_InitStruct.Size 			= MPU_REGION_SIZE_128KB;

	MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;

	MPU_InitStruct.IsBufferable 	= MPU_ACCESS_BUFFERABLE;

	MPU_InitStruct.IsCacheable 		= MPU_ACCESS_CACHEABLE;

	MPU_InitStruct.IsShareable 		= MPU_ACCESS_NOT_SHAREABLE;

	MPU_InitStruct.Number 			= MPU_REGION_NUMBER1;

	MPU_InitStruct.TypeExtField 	= MPU_TEX_LEVEL0;

	MPU_InitStruct.SubRegionDisable = 0x00;

	MPU_InitStruct.DisableExec 		= MPU_INSTRUCTION_ACCESS_ENABLE;

	HAL_MPU_ConfigRegion(&MPU_InitStruct);

	

	/* Configure the MPU attributes as Write-Back/No-Write-Allocate for AHB-SRAM2 D2 */

	MPU_InitStruct.Enable 			= MPU_REGION_ENABLE;

	MPU_InitStruct.BaseAddress 		= 0x30020000;

	MPU_InitStruct.Size 			= MPU_REGION_SIZE_128KB;

	MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;

	MPU_InitStruct.IsBufferable 	= MPU_ACCESS_BUFFERABLE;

	MPU_InitStruct.IsCacheable 		= MPU_ACCESS_CACHEABLE;

	MPU_InitStruct.IsShareable 		= MPU_ACCESS_NOT_SHAREABLE;

	MPU_InitStruct.Number 			= MPU_REGION_NUMBER2;

	MPU_InitStruct.TypeExtField 	= MPU_TEX_LEVEL0;

	MPU_InitStruct.SubRegionDisable = 0x00;

	MPU_InitStruct.DisableExec 		= MPU_INSTRUCTION_ACCESS_ENABLE;

	HAL_MPU_ConfigRegion(&MPU_InitStruct);

	

	/* Configure the MPU attributes as Write-Back/No-Write-Allocate for AHB-SRAM3 D2 */

	MPU_InitStruct.Enable 			= MPU_REGION_ENABLE;

	MPU_InitStruct.BaseAddress 		= 0x30040000;

	MPU_InitStruct.Size 			= MPU_REGION_SIZE_32KB;

	MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;

	MPU_InitStruct.IsBufferable 	= MPU_ACCESS_BUFFERABLE;

	MPU_InitStruct.IsCacheable 		= MPU_ACCESS_CACHEABLE;

	MPU_InitStruct.IsShareable 		= MPU_ACCESS_NOT_SHAREABLE;

	MPU_InitStruct.Number 			= MPU_REGION_NUMBER3;

	MPU_InitStruct.TypeExtField 	= MPU_TEX_LEVEL0;

	MPU_InitStruct.SubRegionDisable = 0x00;

	MPU_InitStruct.DisableExec 		= MPU_INSTRUCTION_ACCESS_ENABLE;

	HAL_MPU_ConfigRegion(&MPU_InitStruct);

	

	/* Configure the MPU attributes as Write-Back/No-Write-Allocate for AHB-SRAM4 D3 */

	MPU_InitStruct.Enable 			= MPU_REGION_ENABLE;

	MPU_InitStruct.BaseAddress 		= 0x38000000;

	MPU_InitStruct.Size 			= MPU_REGION_SIZE_64KB;

	MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;

	MPU_InitStruct.IsBufferable 	= MPU_ACCESS_BUFFERABLE;

	MPU_InitStruct.IsCacheable 		= MPU_ACCESS_CACHEABLE;

	MPU_InitStruct.IsShareable 		= MPU_ACCESS_NOT_SHAREABLE;

	MPU_InitStruct.Number 			= MPU_REGION_NUMBER4;

	MPU_InitStruct.TypeExtField 	= MPU_TEX_LEVEL0;

	MPU_InitStruct.SubRegionDisable = 0x00;

	MPU_InitStruct.DisableExec 		= MPU_INSTRUCTION_ACCESS_ENABLE;

	HAL_MPU_ConfigRegion(&MPU_InitStruct);

残りの内蔵SRAMの設定もライトバック・ライトアロケート無しの設定としました。
AHB-RAMはAXIバスマトリクス上にはないので意味なさそうですが実はキャッシュの
恩恵にあずかることができます。

	/* External-Memories cache setting */

	/* Configure the MPU attributes as Write-Back/No-Write-Allocate for External SDRAM */

	MPU_InitStruct.Enable 			= MPU_REGION_ENABLE;

	MPU_InitStruct.BaseAddress 		= 0xD0000000;

	MPU_InitStruct.Size 			= MPU_REGION_SIZE_32MB;			/* STM32H747I-Disco have 32Mbyte SDRAM */

	MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;

	MPU_InitStruct.IsBufferable 	= MPU_ACCESS_BUFFERABLE;

	MPU_InitStruct.IsCacheable 		= MPU_ACCESS_CACHEABLE;

	MPU_InitStruct.IsShareable 		= MPU_ACCESS_NOT_SHAREABLE;

	MPU_InitStruct.Number 			= MPU_REGION_NUMBER6;

	MPU_InitStruct.TypeExtField 	= MPU_TEX_LEVEL0;				/* MUST be No-WriteAllocation to avoid collision LTDC-Hostage */ 

	MPU_InitStruct.SubRegionDisable = 0x00;

	MPU_InitStruct.DisableExec 		= MPU_INSTRUCTION_ACCESS_ENABLE;

	HAL_MPU_ConfigRegion(&MPU_InitStruct);

	

	/* External-Memories cache setting */

	/* Configure the MPU attributes as Write-Back for QSPI-DirectRemapping(ReadOnly) */

	MPU_InitStruct.Enable 			= MPU_REGION_ENABLE;

	MPU_InitStruct.BaseAddress 		= 0x90000000;

	MPU_InitStruct.Size 			= MPU_REGION_SIZE_128MB;		/* STM32H747I-Disco have 64*2=128MByte QSPI-ROM */

	MPU_InitStruct.AccessPermission = MPU_REGION_PRIV_RO_URO;

	MPU_InitStruct.IsBufferable 	= MPU_ACCESS_BUFFERABLE;

	MPU_InitStruct.IsCacheable 		= MPU_ACCESS_CACHEABLE;

	MPU_InitStruct.IsShareable 		= MPU_ACCESS_NOT_SHAREABLE;

	MPU_InitStruct.Number 			= MPU_REGION_NUMBER7;

	MPU_InitStruct.TypeExtField 	= MPU_TEX_LEVEL0;

	MPU_InitStruct.SubRegionDisable = 0x00;

	MPU_InitStruct.DisableExec 		= MPU_INSTRUCTION_ACCESS_ENABLE;

	HAL_MPU_ConfigRegion(&MPU_InitStruct);

外部メモリ領域のSDRAMやQSPIはAXIバスでつながっているので当然のことながら
大きな影響を受けます。しっかりキャッシュ設定をしておきましょう。
また、SDRAMをLTDCのフレームバッファに使用したい場合は必ずライトアロケーション
なしを選択してください。ライトアロケーションありだといちいちCleanをしてやる
必要が出来てしまい、それを怠るとDMAの時のようにデータの一貫性が保たれ
なくなり表示がおかしくなります。フレームバッファはデータを読みだすことは
ほぼ無く書きっぱなしなのでライトアロケーションなしの方が都合が良いのです。

QSPIはメモリマップドモードのリードオンリーで使用するためどうでもよいですが
AccessPermission以外はSDRAMとキャッシュ設定を合わせておきましょう。

そしてSAI等の周期的にデータ投げる用途ではAXI-SRAMをライトアロケート有りにして
いるとキャッシュコントロールを今よりさらに厳格にしないと高ビットレートでﾎﾟﾂﾎﾟﾂ
ノイズが入りやがることが分かったので･･･＃＃＃＃＃
もう全部一律ライトアロケート無しでやります！１１１！！！

次回は上記キャッシュポリシーの設定別に実動作をさせたときの性能の比較を
行ってみたいと思います！

STM32H7を使ってみる2 -スライムが強すぎてアリアハンから出られない件-

おおねむいよしんでしまうとはなさけないっ…ていうかさ、お前このぶろぐ立ち上げて
10年間ずっと何やってきたんだ？毎年初心に帰ってないでさっさと先に進めや！！１!と
王様に副業先とほぼ同じ内容(本業は虹裏メイド)で怒られてる今現在でございますが
STM32って言う名前のスライムなんですがこれ世間一般の認識の青色のプルプル形状
しててワンパンで死ぬ雑魚と違ってねむいさんの前に立ちはだかるそいつは液状で高速で
動き、物理攻撃が効かず強力な"溶かす"攻撃してくる最強クラスの敵なんですがねむい
さんのほうがﾜﾝﾊﾟﾝで死んでしまうのですがこいつのせいでFatFsの実装という最初期
段階で踏みとどまって10年が経過してしまったのですが年数の経過とともにねむいさん
倒しまくって経験値増やしていった結果スライム君の方が先にレベルアップしてしまって
STM32F4とかF7とかどんどん数字が上がって挙句の果てにクロック周波数480MHz
デュアルコアH7とかにパワーアップしてしまったスライムに包囲されアリアハンは壊滅
寸前もうだめだでもよく考えたらねむいさんの職業て勇者じゃなくて虹裏メイドだから
別に無理してアリアハンから出なくてもいいんじゃねっていう弱い考えが浮かびそうに
なりますが今度こそスライムを倒すために異世界モノなろう小説風に毎回恒例の初心
表明を宣言するのでした！10年後に転生したら10年たっていた件

さて、謎の文字列は置いといてSTM32H747I-Discovery向けいつものはこちらに
なります！！！！１！！！！！
まだ暫定版なので明らかなバグ以外はご意見無用とさせていただきます！！！！

上記のブツを元にプログラムの解説をしていきますのでよろしくお願いします。

●アリアハン脱出作戦開始
まずすべきことはSTM32H7のメモリ/バスのアーキテクチャを理解してプログラム
作りの土台を作ること、つまりはH7向けのリンカスクリプトとビルド環境を構築
することです。

STM32F7に比べてメモリ構成はさらに複雑になっています。しかもデュアルコア
なのでそれを意識してメモリを分け分けしないといけません。

ねむいさんの戦略としては当分の間はH7コアをシングルで動かすことを主眼に入れ、
上記画像のように組んでみました。H7コアと同じ周波数で動作できる密結合メモリの
DTCM-RAMはほぼスタック専用に、大容量&バス幅64bitのAXI-SRAMは
DATA,BSS,HEAPに割り振ります。
ITCM-RAMも容量が増えたので今回から積極的に使用していきます！
そしてAHBバスマトリクスに配置されているSRAMですがこちらはバスマトリクスが
どこで繋がってるかをしっかりわかっておかないとDMAとかでハマるので以後
個別に詳しく解説しようと思います。

また、すでに先達の使用者からよく言われていることですがF7では便利だった
DTCMはH7に上がってDMAの制約が極めてきつくなり、実質上直接DMA不可と
なっていますF**K！！！１１！！！！！
一応やれないこともないのですがMasterDMAを介した面倒な間接転送となります。
これについてもいずれ別記事で詳しく解説したいです(弱い願望)。

/* Linker script Upperside for STM32H747XIH6		*/

/* Nemui Trinomius (http://nemuisan.blog.bai.ne.jp)	*/



OUTPUT_FORMAT ("elf32-littlearm")



/* Memory Spaces Definitions */

MEMORY

{

	/* Instruction TCM SRAM */

	ITCM_RAM (xrw)	: ORIGIN = 0x00000000, LENGTH = 64k		

	/* Data TCM SRAM */

	DTCM_RAM (xrw)	: ORIGIN = 0x20000000, LENGTH = 128k		

	/* AXI-SRAM D1 Domain */

	AXI_SRAM (xrw)	: ORIGIN = 0x24000000, LENGTH = 512k

	/* AHB-SRAM1 D2 Domain */

	SRAM1_D2 (xrw)	: ORIGIN = 0x30000000, LENGTH = 128k

	/* AHB-SRAM2 D2 Domain */

	SRAM2_D2 (xrw)	: ORIGIN = 0x30020000, LENGTH = 128K

	/* SRAM3 D2 Domain */

	SRAM3_D2 (xrw)	: ORIGIN = 0x30040000, LENGTH = 32k

	/* SRAM4 D3 Domain */

	SRAM4_D3 (xrw)	: ORIGIN = 0x38000000, LENGTH = 64k

	/* Backup SRAM */

	BKP_SRAM (rw)	: ORIGIN = 0x38800000, LENGTH = 4k

	/* External SDRAM(FMC) */

	EXT_SDRAM (xrw)	: ORIGIN = 0xD0000000, LENGTH = 32M

	/* Main Embedded Dual-Bank FlashROM */

	FLASH_ROM (rx)	: ORIGIN = 0x08000000, LENGTH = 2M

	/* External Dual-Mode QSPI-ROM */

	QSPI_ROM (rx)   : ORIGIN = 0x90000000, LENGTH = 128M

}



/* higher address of the stack bottom,AAPCS said "stack MUST BE 8byte alignment". */

_estack = (ORIGIN(DTCM_RAM)+LENGTH(DTCM_RAM)) & ~ 0x7;



/* higher address of the heap end */

_eheap = ORIGIN(AXI_SRAM)+LENGTH(AXI_SRAM);





/* include the section management sub-script */

INCLUDE "STM32H7xxxx_FLASH.ld"

こんな感じでリンカスクリプトに落としました。
今回はスクリプトそのものも見直して意味不明なことやってた記述は排除/修正
しております！その修正内容は…

ねむいさんスタックポインタとかヒープの設定で9年間くらい謎の引き算やってた…
なんでこんなんでアライメントが揃うと思っていたのか…
(↑ARM7TDMIは設定するSRAMの最終アドレスから-8バイト引いた値をspに設定
　　しないといけなかったのでCortex-Mからスタック設定の仕様が変わった
　　後も仕様をよく見ないでやっていたと考えられる…
　　これじゃスライムにやられるわけだ)

●クロック設定とかGPIO入出力とか
こちらに関してはSTM32H7CubeのBSPを参考にすれば問題はありません。
最大480MHzで動作するH7コアですがエラッタやSDRAMを使った時の速度的な
制約がありH7コアクロック400MHz、AXI/AHBバスクロック200MHzがつぶしが
効く設定となり、BSPのExampleではすべてこの周波数設定となってます。
これをそっくりそのまま頂いちゃいましょう!
ぇ…？CubeMX?なんスかそのバグコード生成機?
そんなもん使ってたら時間無駄にして頭がﾊﾟｰﾝしちゃいますよぅ？

/* Defines -------------------------------------------------------------------*/

/**

  * @brief  System Clock Configuration

  *         The system Clock is configured as follow : 

  *            System Clock source            = PLL (HSE)

  *            SYSCLK(Hz)                     = 400000000 (Cortex-M7 CPU Clock,upto 480MHz)

  *            HCLK(Hz)                       = 200000000 (Cortex-M4 CPU, Bus matrix Clocks,upto 200MHz)

  *            AHB Prescaler                  = 2 (AHB/AXI Bus Matrix Clock upto 200MHz)

  *            D1 APB3 Prescaler              = 2 (APB3 Clock upto 100MHz)

  *            D2 APB1 Prescaler              = 2 (APB1 Clock upto 100MHz)

  *            D2 APB2 Prescaler              = 2 (APB2 Clock upto 100MHz)

  *            D3 APB4 Prescaler              = 2 (APB4 Clock upto 100MHz)

  *            HSE Frequency(Hz)              = 25000000

  *	           VCO Frequency                  = 800000000 (160*5)

  *            PLL_M                          = 5

  *            PLL_N                          = 160

  *            PLL_P                          = 2

  *            PLL_Q                          = 4

  *            PLL_R                          = 2

  *            VDD(V)                         = 3.3

  *            Flash Latency(WS)              = 4

  * @param  None

  * @retval None

  */

#define PLL1_M		5

#define PLL1_N		160

#define PLL1_P		2

#define PLL1_Q		4

#define PLL1_R		2

#define PLL1_FRACN	0

上記はコア/バス/ペリフェラルクロック用のPLL設定値のdefineです。
F7と比べるとPLLが増えてかなり変わってる感じがしますね。
hw_config.cに具体的なコードがあるのでご参考に。
また、ユーザーマニュアルではカーネルクロックなるややこしい概念が出てきますが
殆どのペリフェラルではHCLK(AHB)のクロックを指します。

static void LED_Configuration(void)

{

	GPIO_InitTypeDef GPIO_InitStructure;



	/* Enable GPIO_LED clock */

	GPIO_LED_CLKEN();

	

	/* Configure GPIO for LEDs as Output push-pull */

	GPIO_InitStructure.Pin 			= LED_D1;

	GPIO_InitStructure.Mode 		= GPIO_MODE_OUTPUT_PP;

	GPIO_InitStructure.Pull 		= GPIO_NOPULL;

	GPIO_InitStructure.Speed 		= GPIO_SPEED_FREQ_VERY_HIGH;

	GPIO_InitStructure.Alternate 	= 0;

	HAL_GPIO_Init(GPIO_LED1, &GPIO_InitStructure);

	LED_D1_OFF();



	GPIO_InitStructure.Pin 			= LED_D2;

	HAL_GPIO_Init(GPIO_LED2, &GPIO_InitStructure);

	LED_D2_OFF();

	GPIO_InitStructure.Pin 			= LED_D3;

	HAL_GPIO_Init(GPIO_LED3, &GPIO_InitStructure);

	LED_D3_OFF();

	GPIO_InitStructure.Pin 			= LED_D4;

	HAL_GPIO_Init(GPIO_LED4, &GPIO_InitStructure);

	LED_D4_OFF();

}

LED(GPIO)の出力設定はF7とほぼ変わりませんが100MHz越えのI/Oトグリング
対応の為"GPIO_SPEED_FREQ_VERY_HIGH"という定義が追加されてます。
特に必要が無い場合はVERYHIGHにしておきましょう。

static void KEY_Configuration(void)

{

	GPIO_InitTypeDef GPIO_InitStructure;



	/* Enable GPIO_LED clock */

	RCC->AHB4ENR |= (RCC_AHBPeriph_GPIO_KEY_USER1);

	RCC->AHB4ENR |= (RCC_AHBPeriph_GPIO_KEY_SEL);

	RCC->AHB4ENR |= (RCC_AHBPeriph_GPIO_KEY_DOWN);

	RCC->AHB4ENR |= (RCC_AHBPeriph_GPIO_KEY_LEFT);

	RCC->AHB4ENR |= (RCC_AHBPeriph_GPIO_KEY_RIGHT);

	RCC->AHB4ENR |= (RCC_AHBPeriph_GPIO_KEY_UP);

	

	/* Configure GPIO for Key Input */

	GPIO_InitStructure.Pin 			= KEY_USER1;

	GPIO_InitStructure.Mode 		= GPIO_MODE_INPUT;

	GPIO_InitStructure.Pull 		= GPIO_NOPULL;

	GPIO_InitStructure.Speed 		= GPIO_SPEED_FREQ_VERY_HIGH;;

	GPIO_InitStructure.Alternate 	= 0;

	HAL_GPIO_Init(GPIO_KEY_USER1, &GPIO_InitStructure);



	GPIO_InitStructure.Pull 		= GPIO_PULLUP;

	GPIO_InitStructure.Pin 			= KEY_SEL_PIN;

	HAL_GPIO_Init(GPIO_KEY_SEL, &GPIO_InitStructure);

	GPIO_InitStructure.Pin 			= KEY_DOWN_PIN;

	HAL_GPIO_Init(GPIO_KEY_DOWN, &GPIO_InitStructure);

	GPIO_InitStructure.Pin 			= KEY_LEFT_PIN;

	HAL_GPIO_Init(GPIO_KEY_LEFT, &GPIO_InitStructure);

	GPIO_InitStructure.Pin 			= KEY_RIGHT_PIN;

	HAL_GPIO_Init(GPIO_KEY_RIGHT, &GPIO_InitStructure);

	GPIO_InitStructure.Pin 			= KEY_UP_PIN;

	HAL_GPIO_Init(GPIO_KEY_UP, &GPIO_InitStructure);

}

入力についても同様です。
H7-Discvoeryは4+1入力ジョイスティックが追加されたので物理キー入力処理も
追加しております。

/* Macros */

/* uncomment to enable joy input */

//#define USE_HWKEY_INPUT_SUPPORT



/* ITCM Fastest call for IRQ */

#define ITCM			__attribute__ ((section (".itcm")))

//#define ITCM			__attribute__ ((long_call, section (".itcm")))

hw_config.h内で上記の物理キー入力有効無効が切り替えられるようにしておきました。
タッチパネルがあるのでデフォルトは無効です。

●タイムベースは重要ですよね

	/* Making MilliSecond-Order Timer */

	/* Select Clock Source  */

	SystemCoreClockUpdate();

	HAL_SYSTICK_CLKSourceConfig(SYSTICK_CLKSOURCE_HCLK);

	/* Setup SysTick Timer for 1 msec interrupts  */

	if (SysTick_Config(SystemCoreClock/interval))

	{ 

		/* Capture error */ 

		while (1);

	}

マイコンを動かすにおいて必要不可欠なタイマですがsystickの設定についてはF7と
殆どかわりません。ほんの少しの修正で使用可能です。
ねむいさんのいつものではミリ秒オーダーのタイムベースとして動作させてます。

	/* Making MicroSecond-Order Timer uses general purpose timer! */

	/* Enable timer clock */

	USEC_TIMx_CLKEN();



	/* calculate TIMx(2~5) Prescaler clock(D2 Domain) */

	if(RCC->D2CFGR & RCC_D2CFGR_D2PPRE1){

		if((RCC->D2CFGR & RCC_D2CFGR_D2PPRE1) == RCC_D2CFGR_D2PPRE1_DIV2){

			cal_usec_divide = SystemCoreClock/2;   	/* (HCLK(=SYSCLK/2)*2)*2 */

		}

		else if((RCC->D2CFGR & RCC_D2CFGR_D2PPRE1) == RCC_D2CFGR_D2PPRE1_DIV4){

			cal_usec_divide = SystemCoreClock/4; 	/* (HCLK(=SYSCLK/2)*4)*2 */

		}

		else if((RCC->D2CFGR & RCC_D2CFGR_D2PPRE1) == RCC_D2CFGR_D2PPRE1_DIV8){

			cal_usec_divide = SystemCoreClock/8; 	/* (HCLK(=SYSCLK/2)*8)*2 */

		}

		else if((RCC->D2CFGR & RCC_D2CFGR_D2PPRE1) == RCC_D2CFGR_D2PPRE1_DIV16){

			cal_usec_divide = SystemCoreClock/16; 	/* (HCLK(=SYSCLK/2)*16)*2 */

		}

	}



	TimHandle.Instance 				 = USEC_TIMx;

	TimHandle.Init.Period            = UINT32_MAX;

	TimHandle.Init.Prescaler         = ((cal_usec_divide)/USEC_INTERVAL) - 1;

	TimHandle.Init.ClockDivision     = 0;

	TimHandle.Init.CounterMode       = TIM_COUNTERMODE_UP;

	TimHandle.Init.RepetitionCounter = 0;

	if (HAL_TIM_Base_Init(&TimHandle) != HAL_OK)

	{

		/* Capture error */ 

		while (1);

	}

	

	USEC_TIMx->CR1 &= ~(TIM_CR1_UIFREMAP); /* Disable UIF Remap(Must Need!) */



	HAL_TIM_Base_Start(&TimHandle);

μ秒オーダーは32bitタイマを利用しています。F7/H7でTIM5のフリーランニング動作で
実現しております。ただH7ではAHBの番号が異なっているので変更は必用です。
また、バスクロックも2倍に上がっているのでそれを考慮した計算値を与えましょう。
各詳細はsystick.c参照

●リングバッファ付UARTもはや基本
ねむいさんUARTという文字列をなぜかずっとウラートと呼んでました
…ソビエト連邦かな？(正解:ユーアート)

#if defined(USE_STM32H747I_DISCO)

 #define UART_DEFAULT_NUM		1

 #define UARTx					USART1

 #define USARTx_IRQHandler		USART1_IRQHandler

 #define USARTx_CLKEN()			¥

			/* Enable GPIO clock(UART_TX) */ ¥

			RCC->AHB4ENR |= (RCC_AHB4ENR_GPIOAEN); ¥

			/* Enable GPIO clock(UART_RX) */ ¥

			RCC->AHB4ENR |= (RCC_AHB4ENR_GPIOAEN); ¥

			/* Enable UART clock */ ¥

			RCC->APB2ENR |= (RCC_APB2ENR_USART1EN);

 #define USART_TxPin			GPIO_PIN_9

 #define USART_RxPin			GPIO_PIN_10

 #define USART_TxPort			GPIOA

 #define USART_RxPort			GPIOA

 #define USART_TXALT			GPIO_AF7_USART1

 #define USART_RXALT			GPIO_AF7_USART1

 

/* This is the ARDUINO Option(not used) */

 //#define UART_DEFAULT_NUM		8

 //#define UARTx					USART8

 //#define USARTx_IRQHandler		USART8_IRQHandler

 

#else

 #error "Select or make board settings!!"

#endif

こちらについてもF7と大きな変更はなく、H7-Discovery内のSTLink/V3のVCPに
つながっているPA9(TX),PA10(RX)を割り当てるだけです。まぁこのポートは
ブートローダーでも使うSTM32伝統のUARTポートみたいな感じですね～

#if defined(UART_INTERRUPT_MODE)

/**************************************************************************/

/*! 

    @brief	Handles UARTx global interrupt request.

	@param	None.

    @retval	None.

*/

/**************************************************************************/

ITCM void USARTx_IRQHandler(void)

{

	uint32_t IntStat = UARTx->ISR;



	if(IntStat & USART_ISR_RXNE_RXFNE)

	{

		/* Clear Errors */

		UARTx->ICR = USART_ICR_ORECF | USART_ICR_NECF | USART_ICR_FECF | USART_ICR_PECF;



		/* Advance buffer head. */

		unsigned int tempRX_Head = ((&USARTx_Buf)->RX_Head + 1) & (UART_BUFSIZE-1);



		/* Check for overflow. */

		unsigned int tempRX_Tail = (&USARTx_Buf)->RX_Tail;

		uint8_t data =  UARTx->RDR;



		if (tempRX_Head == tempRX_Tail) {

			/* Overflow MAX size Situation */

			/* Disable the UART Receive interrupt */

			UARTx->CR1 &= ~(USART_CR1_RXNEIE);

		}else{

			(&USARTx_Buf)->RX[(&USARTx_Buf)->RX_Head] = data;

			(&USARTx_Buf)->RX_Head = tempRX_Head;

		}

	}



	if(IntStat & USART_ISR_TXE_TXFNF)

	{

		/* Check if all data is transmitted. */

		unsigned int tempTX_Tail = (&USARTx_Buf)->TX_Tail;

		if ((&USARTx_Buf)->TX_Head == tempTX_Tail){

			/* Overflow MAX size Situation */

			/* Disable the UART Transmit interrupt */

			UARTx->CR1 &= ~(USART_CR1_TXEIE);

		}else{

			/* Start transmitting. */

			uint8_t data = (&USARTx_Buf)->TX[(&USARTx_Buf)->TX_Tail];

			UARTx->TDR = data;



			/* Advance buffer tail. */

			(&USARTx_Buf)->TX_Tail = ((&USARTx_Buf)->TX_Tail + 1) & (UART_BUFSIZE-1);

		}

	}

}

#endif

また、実際の通信では割り込みを用いてノンブロッキング(非同期)のリングバッファ
構成を取っています。割り込みルーチン本体はITCMにコードを配置して超高速に処理
できるようにしておきました。

/**************************************************************************/

/*! 

    @brief	Copy Time-Critical codes into ITCM-RAM.

	@param	None.

    @retval	None.

*/

/**************************************************************************/

static void datacopy(unsigned int romstart, unsigned int start, unsigned int len)

{

	unsigned int *pulDest = (unsigned int*) start;

	unsigned int *pulSrc  = (unsigned int*) romstart;

	unsigned int loop;

	for (loop = 0; loop < len; loop = loop + 4)

		*pulDest++ = *pulSrc++;

}

/* _stitcm,_sitcm,_eitcm are MUST be decrare in likerscript file */

static void ITCM_Datainit(void)

{

	unsigned int *LoadAddr, *ExeAddr, *EndAddr, SectionLen;



    /* Copy ITCM Codes into ITCM-RAM */

	LoadAddr = &_stitcm;

	ExeAddr  = &_sitcm;

	EndAddr  = &_eitcm;

	SectionLen = (void*)EndAddr - (void*)ExeAddr;

	datacopy((unsigned int)LoadAddr, (unsigned int)ExeAddr, SectionLen);

}

当たり前の事ですがITCMで動作させるためにはあらかじめコードを転送しておかないと
いけないので起動直後とかにコードを送っておきましょう。
その他細かい部分はhw_config.cに詰まっていますのでそちらをご参照ねがいます。

というわけでまだほんの少ししか紹介出来ておりませんがひとまずH7を動かすための
基本的な項目の解説を行いました。次回からはH7最大の難関であるキャッシュとDMAの
問題に切り込んでいこうと思います！

STM32H7はぢめました・・・本当にいまさら

ｷﾀ━━━(ﾟ∀ﾟ)━━━!!
まってたぜぇ…この瞬間(とき)をよぉ…！

出る出る詐欺で一向に出る気配がなかったSTM32HのDiscoveryがついに私の
手元に入りました…！本当に長かった…！(※正式名称はSTM32H747I-DISCO)

基板の形状はSTM32F769I-Discoveryとほぼ同一ですね

メインCPUはH7シリーズ第二世代のSTM32H747XIH6です。第2世代になって何が
変わったかというとなんとCortex-M4コアがもう一つ付いたデュアルコア構成と
なっております！！！！

そんでもってビルトインされたSTLinkも最新のV3仕様で使用CPUはSTM32F723です！
なんとオンチップでUSB-Highspeedの物理層が乗っかっているすごい奴なのです！！

SDRAMはISSI製の32Bitデータバスの32MByteの奴が乗っかっています。

液晶を外して基板表面も見てみましょう。液晶モジュールはSTM32F769I-Discoveryと
全く同じMIPI-DSI接続のWVGAなTFT-LCDです(容量性タッチパネルICも同じ)

LANの物理層はおなじみMicrochipのLAN8742Aです。

そしてこの多CHフォトカプラみたいなのなに…と思ったのですがこれがQSPI-ROM
なのです！マイクロンのMT25QL512ABB8ESF-0SITが乗っています。

そして基板の反対側にもついている。STM32H747XIでは2つのQSPI-ROMを一つの大
容量クアッドSPI-ROMのように使えるDUAL-QUAD Modeが搭載されております！

I2S-CodecはおなじみのWM8994Eです。

そしてArduinoスタイルのコネクタの他にもI/Oを外部に拡張できるコネクタが
新設されました！Xbeeとかをそのままつけられそうですね～

…
ぜんぜんピン間隔ちがってたorz

外観はこの辺にしておいてUSBMicroケーブルぶっ刺して通電です！
STMicroがイチオシするSTemWinとTouchGFXをふんだんに使用したでもアプリが
起動します。

TouchGFXはSTM32F769I-Discoveryの時のようにCPUの負荷状態とか見られる機能や
JPEGやDMA2Dみたいな各種ハードウエアアクセラレーションの効果を見ることが
できるプログラムもあり…おや…これは…

ク　ソ　ゲ　ー　再　び
モーやってられませんわこれ(←律儀にやる人

さて、STM32H7でもいつものベアメタルでとりあえず組んでみる予定です。
現在はLチカにはぢまってねむいさんのコンテンツでは欠かせないDMA動作を絡めた
FatFsの実装まで完了しております(画像はLED点滅しているところ)。

H7に上がって機能も制約もF7とは段違いに変わってますので実装を進めながら
次回以降にみっちりと解説していけたらと思います！

OpenOCD小ネタ25 -STM32F746G-Discoveryでステップ実行が上手くできない件-

令和明けましておめでとうございます。
今年は明けましておめでとうが2回もあった年なわけですが新元号明けたとたんに
景気が悪くなりだしてヤッパつれぇわ‥
…ってダジャレ言いたかっただけです。

さてOpenOCDも地味に着々と更新が加わっておりますが4月頭にCortex-M7初期
リビジョンでデバッグのステップ実行時に強制的に割り込みでブレークがかかる
という難儀なエラッタに対する回避策が講じられた模様でねむいさんもさっそく
試してみることにしました。

STM32F746G-Discvoeryがそのエラッタ持ちのシリコンのSTM32F7の品種なので
これで実験してみます。

無対策の場合では私のプログラムの場合、ステップ実行で最初のprintf関数まで
実行したら強制的にUARTのIRQに飛んで行ってしまいます。これが上記のバグ
の具体的な影響となります。現在のOpenOCDではこれに対して強制的にブレークが
掛からないようにする回避策の修正を加えられています。はずです！

回避策の使い方はopenocdの起動時のコマンド引数若しくは起動時に読み込むcfg
ファイルに"cortex_m maskisr steponly"を沿えるだけとなっております。
しかし、cortex_mコマンドはSTLink等のHLAでは使用不可能な固有コマンドです…
STM32F746G-DiscvoeryはSTLink/V2一体型…orz

そんなわけで改造してみます。SWDがつながっているジャンパ抵抗を外し外に引きだ
しができるようにします。
今回使用する外部のデバッガアダプタはJ-Linkに化かしたLPC-Link2です。

それでは開始…！
…
ぁれ…またUARTのIRQで止まってる…orz

いろいろ調べましたがstepi(=アセンブラの1命令単位のステップ実行)は問題ない
ようでしたが、C言語ソースレベルのやつ(=step)が駄目orz

というわけで私のいつものでSTM32F746G-Discoveryを使う際はUARTを割り込み
なしのポーリングの設定(uart_support.h参照)に替えてデバッグしていただきたく
思います…！

STM32F7Cube更新そのほか

●STM32F7Cubeが1.15.0になった
世に出てからはや数年が経過したSTM32F7ですが現在もSTM32F7Cubeライブラリの
更新は精力的に続いております。

前々から挙がっていたクレーｍ…要望にやっとこ対応できたのかダウンロードサイト
見たら前バージョンも落とせる仕様となっていましたね（やっとかYO!

それと昨年のFacebook等のSNSの勝手に情報収集問題からかサイトを開くと
いちいち｢クッキー取得するかんな！了承しないとサイト見せないぞ！｣っていう
ウインドウが開くようになりやがりました＃＃＃STに限らずほかのサイトでも
こういう風潮が増えていますが正直うざったいですね…#####

話を戻しますが前バージョンが落とせる仕様に変わったのは2月以降に更新が
入ったCubeライブラリのみのようです更新してない奴はそれっきりorz

ボヤキはこの辺にして主な変更は暗号化関連のコードが大変更になったようです
ねむいさん暗号化は使ってないのでほぼ影響ありませんが
それと今までEXTI(外部入力&イベントコントローラ)のHALってなかったのか…！？
LL(ローレベル)ライブラリ版は昔からあったようですが…
あんま使ってない機能だからまぁいいか‥

ChaN氏のFatFs0.13c最新パッチ版を適用して無事動作しております。
静止画なのでわかりづらいですがgifライブラリも3年ぶりに更新したので
ばっちり適用しております☆

というわけで最新のライブラリや修正を盛り込んだ私のFatFs移植例"いつもの"は
更新しておきぱに置いておりますのでどしどしご利用ください☆

もちろんSTM32F4のいつものも更新済みです！

ついでにSTM32F4Cubeも更新が入ってましたのでF4Nucleo用のプロジェクトも
更新しております！こちらもよろしく！

●STLinkのファームウエア更新
ついにV3とかも出てきておりますがSTLinkのファームウエアも続々進化しております。

J33.M25になってMassStorageも使えるmbedファームと従来のSTLink+VCPの
ファームも使用可能となってます☆
しかし…

新ファームだとOpenOCD使うとL0に書けないorz

ST謹製のCubeProgrammerからなら書けます…ファック！！！

J32.M22のファームならOpenOCDでも大丈夫です。
おそらく修正が入るでしょうがSTM32L0シリーズ使ってる人はSTLink/2の
ファームウェアバージョンには気を付けてくださいね。

STM32F7CubeがV1.12.0になった

とうとう1年の半分が終わってしまいましたね…
STM32やOpenOCD関連は今でも地味に着実に更新が続いておりますのでこちらも
地味に紹介を続けさせていただきます…

さて、今回の更新ではSTM32F7の低価格帯製品であるSTM32F73xとF75xのサポートが
追加されています。それに伴いHALライブラリもV1.2.6にアップデートしました。

F73xやF75xはたぶん早々にNUCLEOが出ると思いますがリリースされたら購入して
レポートさせてもらいます。それと海外の人にも"H7の記事はまだか！？"と頻繁に
メッセージいただきますがH7シリーズはひたすらDiscovery待ちです。
現行出ているH7は機能がちょっと微妙でF7から乗り換える利点があまりなく、
次世代のもうちょっと機能が上がった奴を待っている状態です。

もう一つの更新は…STM32F7もどっかのLPC4300シリーズみたいにQSPI等の外部
ROMにメモリマップドでつながったプログラムを実行できるのですがそれの実例が
追加されたことです。残念ながらSTM32の場合はブート時にいきなり外部ROM
から起動は出来ず一旦内部Flashでブートコードを経由して実行する仕組みに
なっています。

まぁF7の場合はキャッシュと莫大なRAMと内部Flashがあるので無理くそQSPIに
プログラムを実行しないでもいいのですが来月あたりに時間ができたら私も
実証してみたいと思います。

ということでSTM32F7CubeV1.12.0を反映したFatFs移植例はおきぱに公開したので
皆さんご利用ください。またFatFsも0.13bの新しいパッチが出ていたのでこちらも
盛り込んでおります！

STM32F7CubeがV1.11.0になった

あと2日で新年度になってしまいますね～。私は相も変わらずの日々となって
おります。これからさらに忙しくなりそうですが月一の更新くらいは続けて
いこうと思います。ていうか最近月末ばっかりになってるー！！

さて、STM32F7Cubeライブラリが表題のとおりV1.11.0になりました。ねむいさんの
記憶では前回更新が今年はじめのV1.9.0でV1.10.0はどこ行ったんだという野暮な
突っ込みは昔からSTM32弄ってる奴にとってはその程度1LSBの誤差にも入らないから
まったく問題ないでしょう。

私が注目した主な変更点は以下のとおりとなっています。
・全般
->Improve cache management for all examples and applications
using cache maintenance routines.

キャッシュメモリの扱いを改善したそうです。ていうか今まで適当だったんかい##
ちなみにねむいさんは数年前からF7シリーズのキャッシュの扱いを自分なりに纏めて
適切に設定しているので私のおきぱの作例については特に問題はないです。

・HALライブラリ
->Add new macro to get variable aligned on 32-bytes,
　　required for cache maintenance purpose.

これもキャッシュがらみですね～･･･CortexM7のキャッシュは32Byte単位なので
理由も分かりますが･･･

･･･??????
ねむいさんにはなにがどう改善したのかちょっと分かりかねますが多分なんか
改善されているのでしょう･･･もしかして無意識に問題回避してるのかも･･･

というわけで新しいHALライブラリを反映したSTM32F7向けのFatFs移植例は既に
おきぱに反映しておりますのでどしどしご利用ください。

ついでにSTM32F4CubeもV1.21.0にアップデートしていますがこっちも
V1.20.0をどっかに落っとこしてきたみたいですがF401RE-Nucleo板上で問題なく
動作を確認しております。こちらも既に反映していますのでどしどしご利用ください！

そして2017年度最後のぶろぐ記事も書き終えたところでOpenOCDのメーリング
リストから久々にかなりの大変更がマージされた報が飛び込んできました･･･
これcortex-m以降のすべてのARMマイコンに関わる大変更になるので次回の
OpenOCDのエントリにてみっちりと解説していきたいと思います･･･！！

STM32F7CubeがV1.9.0になった(とSTM32にかかわる話あれこれ)

皆様あけましておめでとうございます。

今月末に急にネムNEMネムって私の名を呼ばれる機会が増えましたが私の魅力に
ついに気づいてくれたのでしょうか？｢｣すら忘れかけているのにちょっぴり嬉しいでｓ
ｹﾞﾌﾝｹﾞﾌﾌﾝ今年も残すところあと１１か月になってしまいましたがわずかな時間を
見つけてがむばらせていただきます！

さて、昨年中盤から副業(本業は虹裏メイド)のほうが超ピークの稼ぎ時でなんと
基本給と歩合給あわせて今までの手取りの3倍ということでマジ超フィーバー状態で
家族のためにSALARYを稼ぐためにとても忙しくなりなかなかマイコンいじりに
割ける時間が取れなくなってしまいましたが、それでもなお沢山の方がとくに
平日日中にもかかわらず多数の方が来てくださっていますので
今後もSTM32を中心に目ぼしい情報を発信していく次第です！！！！！！！！
※ねむいさんのぶろぐは土日のアクセスは平日の1/3以下しかないです･･･
　さぼるな！

●STM32F7CubeがV1.9.0にアップデート
今月末にひっそりとリリースされておりました。
今回の変更内容はCANドライバが大型変更となっており過去のHALドライバと互換性
が消滅しているようです。この容赦のない大変更はSDMMCでもありましたがまぁ今
までSTM32を使いこなしている方ならすぐにアジャストできると思います。

既におきぱのSTM32F7のFatFs移植例は最新のCMSISv5ヘッダライブラリとともに更新
しております。どしどしご利用ください！

●STM32H7ついに一般市場に
･･･今更遅ぇえーＹＯ！
すでに廉価版のNUCLEOとフル機能の高価なEVALはでていますがねむいさんはひたすら
Dicovery板待ちです･･･EVALは高すぎでNUCLEOは高速I/Fをバラックで組める自信が
ないしでやっぱし中間的な地位のDiscovery板がしっくり来ます。

しかしながらねむいさんもデータ流し読みしてて気づいたのですが、H7では
DTCM領域をDMAのデータバッファとして使用できなくなり常に内蔵SRAMとの
キャッシュの整合性を気にする必要がでてきてしまいました…。
なんというか本当にもはや"マイコン"ではなく"プロセッサ"ですねこりゃ･･･
けしかん様のブログにくわしい解説が記されております。
STM32CUBEの吐くキャッシュ設定のデフォルトがライトスルーじゃなくて
ライトバックなのハマる人続出でヤバいと思うんですがまぁこういうの触る人は
キャッシュの事熟知しているでしょうから問題ないでしょう☆

そういえばDMAで思い出しましたがアライメント制約って4バイト制約のほかに
AHBバスのバースト転送の1kバイト境界制約もあったと思うのですが誰も気に
してなくってねむいさんもずっと使い続けてて特に問題も起きてないから
なんか大丈夫っぽいですね。たぶんSTM32の中の人が上手いこと処理してくれて
いるのでしょう☆

20230920追：
そしてねむいさんはキャッシュ地獄にはまった…！！！
20230920追:

●STM32CubeProgrammer現る！
STM32の内蔵フラッシュメモリに書き込むためのSTマイクロ謹製のPCツールはいくつか
提供されていてﾃﾝでばらばらの場所にあったのですがそれをすべて統合した奴が昨年
リリースされておりました。その名もSTM32CubeProgrammer!

モノとしてはSTLinkUtility,DFUDemonstrator,FlashLoaderDemonstratorの3つの
ライタプログラムが一つのUIに統合されたものとなっており直感的な操作が
可能となっております。

ちなみにJAVAランタイム必須です･･･
ねむいさんのぶろぐを見ている剛の者ならば入れて当然入って当然の代物ですがまし
てや無いと無音でプログラムが即終了するので最初何が原因か分からず1日時間潰し
たりするような軟弱野郎はこのぶろぐの読者にいないはずですがねむいさんのように
1日時間潰してうろたえないようにJAVAランライムはインストールしておきましょう。
入れるのは32bitJAVAランタイムのほうです。

インストール時にはSTLinkとDFUとSTLinkV2-1用の仮想COMのドライバが同時に
インストールされるのでドライバを探してあっちこっちせずにすむのでとても
親切な作りとなっています。

操作画面はあっさりした構成になっています。
ひとまずSTLink/V2を接続したところです。

なんとSTLinkのファームウェアアップグレードも出来たりしちゃいます☆

書き換えた新ファームのSTM32F4Discovery付属のSTLink/V2で接続します。
もちろん困ったときの助け舟、ConnectUnderResetもありますね！

書き込みは10秒くらいで終わっちゃいます。OpenOCDより早いです。

お次はDFUモードで書き込んで見ます。
使用したボードはねむいさんの液晶表示用のF4ボード(紅牛板に無理やり
STM32F407ZGT6乗っけた奴)でブートモードにして接続すると"USB"として
認識されます。STM32F4は単体でUSBのDFUモードになれるので本当は
ライタいらずなのです。

これも書き込み速度はまずまずのスピードです。
まぁUSB接続ですもんね。

最後にシリアルブートモード接続で･･･
これさすがに遅いですね･･･128kb位なら気になりませんが･･･

や、やっとおわった･･･
まぁ普段使いの場合はSTLinkを経由して使用することがほとんどでしょうから
DFUやUARTブートモードはホントに緊急の場合に使用するくらいですね～

そんなわけで私が思っていた以上に使い勝手があがったSTM32CubeProgrammer、
MACやLinux系OS用のパッケージも同梱されているので多くのOSで使うことができ
ますのでますます利用者が広がると思います！
あ、JAVAランタイムは忘れず入れましょう･･･

●STM32限定でAtollic TrueStudioが無料で使える！
STマイクロがAtollic社を食べたのでSTM32限定でTrueStudioが無償でフル機能が
使えるようになったそうです！！ARMマイコンのユーザを高機能な有償ツールの
無償化を餌に取り込む攻勢でしょうか、ライセンス的に企業はどこまで無償で使えるのか
どうかちょっと調べ中ですがホビイストレベルならまったく問題ないと思います。

ちなみにねむいさんのばあいは徹底したIDEの皮を被ったコマンドラインビルド環境
なのでTrueStudioとか必要ないだろと突っ込みうけそうですけどTrueStudioも結局は
GCC使っているのでデモプログラムのビルド条件の解析や他の人が公開しているプロ
ジェクトファイルがこれだった場合はやっぱり必要なので食わず嫌いせず必要な
場面で使っていく次第です。

ちなみにねむいさんは素のEclipseで殴られると全身から血を噴出して即死しますが
メーカーお仕着せのまさにTrueStudioみたいな奴ならば死にませんのでノーカンです！

STM32F7を使ってみる19 -CubeF7がv1.8.0になった-

9月も終わりを迎え、ようやく涼しくなってきましたね。
ねむいさんはここ数年は初夏～晩秋にかけては登山や自然歩道攻略にリソースを
全振りしているのでこちらのぶろぐはなかなか更新するネタが無いのですが、
OpenOCDやSTM32のトピックは常にチェックしておりますのでご安心ください。

さて9月の下旬にSTM32F7Cubeが更新されV1.8.0になっております。
それに伴いCubeF7の中核をなすHALライブラリも大幅更新となっていました。

大きな変更はソースコード中にソースのバージョン表記が一切なくなったこと
です…なぜこのようなことにしたのか理解できないのですがこれあとあと面倒な
事になりそうでちょっと心配です。特に公式のフォーラム上でくだらない漫才が
繰り広げられそうで私はちょっと戦慄しております。

あとはコールバックや割り込みハンドラの細かいバグ潰しでこちらもそれほど
致命的なものではないようですね。実際にCubeF7V1.7.0のHALライブラリと直接
差し替えても特に動作に支障はなかったです。

USBライブラリのMSCのアレについては相変わらずバグったままなので注意して
ください。scsi_blk_addrのuint32_tをuint64_tにしておくのを忘れずに。

それとBSP関連が結構変わっており手を加えないといけません。
私のいつものサンプルにおいてはSTM32F769-Discoではotm8009のドライバを使用
していますがV1.7.0まではランドスケープ(800x480)だったのがポートレイトに
(480x800)なってしまっています。ひとつ前のに戻しておかないと表示も入力も
めちゃくちゃです！これに関してはotm8009.hの定義を元のV1.7.0のやつのに
戻すことで対処。

それともう一件はmp3等のサウンド再生用の関数でこれまたSTM32F769-Disco上に
搭載されたcodec、wm8994を駆動するための初期化の関数内で微妙な改変が行われ
ておりそのままではヘッドフォンから音が出力されなくなってしまったことが
判明しましたorz。(STM32F746G-Discoも同様です)

これについては私が作成してた上位関数があるmp3_support.c,aac_support.c,
そしてwav_support.cのEVAL_AUDIO_Initの第一引数をOUTPUT_DEVICE_SPEAKER
からOUTPUT_DEVICE_BOTHにすることで対処しました。ほんとはこれが正しい
記述だったのかな！？

と言うわけでCubeF7V1.8.0を適用し上記の修正を加えた今月分のいつものの更新
を行いましたので皆様どしどしご利用ください。
ちなみにARM提供のCMSISのヘッダファイルはCubeF7梱包の奴は使用せずgithubで
日々更新されているその時の出来たてﾎﾔﾎﾔの奴を適用しています☆
F7のサンプルに限らず他の品種にも時間が空いた時にこのCMSISヘッダファイル群は
まとめて適用して更新しておりますのでSTM32に限らず他のCortex-Mx系のARM
マイコンを使用されてる方にも恩恵があると思います。

ここまで書いて思い出しましたが一般信者へのリリースが待ち焦がれている
STM32H7について、CubeH7ライブラリは実は既にお披露目となっていました。
STM32H7のSDIOはなんとUHS-1対応となりましたがリファレンスマニュアルを読むと
動的にI/O電圧を内部で切り替えられる機構はなく専用のトランスレータICと組み
合わせて制御する仕組みとなっています。Discovery系のボードではさすがにトラ
ンスレータは乗ると思いますがNucleo系はちょっと予算的にも信号の精度的にも
難しそうですね。一応トランスレータ無しの3.3Vオンリーなら従来のNS(25MHz)と
HS(50MHz)はサポートしてるのでホビーならこれで十分ですけど。

この辺H7のさらなる進化でUHSモード時のI/O電圧動的切り替えがチップ内部で
出来るようになってくれると嬉しいですね～

STM32F7を使ってみる18 -CubeF7がv1.7.0になった(ついでにCubeF4も上がった)-

当らないミサイルやGWが日本に迫る中、STマイクロがリリースしている統合
ファームウエアパッケージ群のCubeF7がアップデートしV1.7.0になりました。
ややこしいですがCubeF7中のHALライブラリ本体は1.2.1(CubeF7v1.6.1時)から
1.2.2へとバージョンアップしています。

変更点はCANのライブラリのバグが修正されたことくらいで前回私が指摘していた
幾つかのSDMMC関連ライブラリに関するバグの致命的な部分はそれより前の
CubeF7v1.6.1で修正されていますがまだバグが残ったままとなっています。
でもねむいさんはCubeF7v1.6.1v1.5.0をベースに最新の奴にアジャストしてるので
何も影響ありませんけどー！！！

ちなみにCubeF4とかの他の品種もアップデートしているようですがHP上で
数字だけ変わっても変更直後はまだ従来の奴だったりする罠がありますので
すぐに落とそうとせず一日ほど待ってからの方がよいです。
ねむいさんは新しモノ好きなのでよくSTマイクロの罠に引っかかるたちです。
この件は昔からフォーラムでたびたび指摘されていますが今に至るまで
真剣に対処されず連携の取れて無さが見て取れるようでちょっと悲しいです。

ちなみに私は現在もDropboxの画像表示できなくなった問題にひたすら
対処している段階なのでマイコンその他のアイテムに関する深い解説記事が取れず
お預け状態となっておりますがおきぱのプロジェクトファイルの更新は
ライブラリのアップデートとともに月一ペースで更新しておりますので
よろしくお願いします。
今月もちょっと早いですけど5/1版のいつものを更新しました。OpenOCDも
新しいのがマージされたら常に更新掛けてますのでよろしくお願いします。

やる気を保つために次回更新予定のネタを少しお見せします。
OpenOCDのSTM32L0への対応が漸く使い物になるレベルになったので解説を
絡めながらDiscovery基板を動かしていく予定です☆

STM32F7を使ってみる17 -とっくの昔ですがCubeF7がv1.6.0になっていた-

前回少しだけ触れましたが、STM32F7向けのHALライブラリCubeF7のバージョンが
v1.5.0(CubeMXの場合v1.5.1)からv1.6.0に上がっておりました。

主な変更点はARMv8系コアのSTM32F7x2・7x3シリーズのレジスタ定義が追加された
事と、SDMMCドライバの大変更、さらに悲願のマルチメディアカード&eMMCサポート
の追加です。

eMMCのサポートはねむいさんも歓迎すべき事柄なのですがソースコードを読み解くと
その期待は完全に裏切られました☠なぜなら…

１.初期化シーケンスさえしっかり記述したら同一のソースコードで読み書きできる
　　はずなのになぜかSDカードとMMCのソースコードがわざわざ分離されている。
　　(↑まじふぁっく)

２."１."のおかげでSDカードとMMCが同時に使用できない。
　　(↑まじふぁっく)

３．MMCの処理中でMMCv4以降のカードで必須のExtCSDレジスタを取得していない
　　ため4GB以上のeMMCが全く使用不可能。昨今のeMMCは最低8GBからなので全く
　　無意味。
　　(↑まじふぁっく)

４．DMA転送のコードが適当で使い物にならずデフォのポーリング版しかまともに
　　動作しない。v1.5.0の時は私が手を加えなくともある程度まともに動いていた。
　　(↑まじふぁっく)

５．SD/MMCとも両規格で指定されている電源投入->動作電圧到達後1mSec待ちその
　　後74クロック空撃ちする処理が無くたまにイニシャライズすら失敗するカードが
　　出る。eMMCは一部カードでbootシーケンスの際に74クロックが必須。
　　(↑まじふぁっく)

６．まともなはずのポーリング版でも一見動いてるように見えるけどランダムで
　　ReadもWriteもエラー発生するのが判明orz v1.5.0に戻すと全く問題なし。
　　(↑馬鹿野郎)

私を含め外人さんたちも憤慨していますが最終的にねむいさんのコードで動いたYO!
とのことで胸をなでおろしております。
CubeF7とは関係ないですがこちらの方は歓喜の絶叫を上げております。

ねむいさんはChaN師の｢xxの上手な使い方はxxを使わないことである｣と言う
格言に倣いCubeF7v1.6.0にv1.5.0のSDカードのドライバ(ややこしいですがHALライ
ブラリ自身のバージョンはv1.2.0)を無理やり移植してやりましたよｵﾗｰ！

無理糞移植なものでねむいさんの環境以外で使用するには多少コツが要ります。
１．"stm32f7xx_hal_conf.h"内の"#define HAL_SD_MODULE_ENABLED"をコメント
　　アウトし"#define HAL_MMC_MODULE_ENABLED"を有効にする。

２．ねむいさん謹製の無理糞ドライバ"sdmmc_stm32f7.c"をプロジェクト/makefile
　　のビルド対象にする。

３．"diskio.c","ff_gen_drv.c"はv1.5.0の物を流用する。

４．内部変数はDTCMからとるようにリンカ/スキャッタファイルを設定しておく。
　　(アライメントずれとデータキャッシュ不整合対策です)

"１．"で何故本来は不必要なはずの"#define HAL_MMC_MODULE_ENABLED"を
有効にしているかと言うと、これを有効にしておかないとstm32f7xx_ll_sdmmc.c
で必要なローレベルの関数がビルドされずエラーになるからですファッ●ク！
ちなみに"#define HAL_MMC_MODULE_ENABLED"と"#define HAL_SD_MODULE_ENABLED"
を両方とも有効にしていると定義がぶつかって
またまたビルドエラーになりますフ●ァック！１１！！１

そんなこんなでCubeF7v1.6.0でも安定してFatFsが動作するようになっております。
FatFs0.12cの最新パッチやCMSISv5の最新版ヘッダフィルを適用した4月版のソース
コードも先行ですがアップしておりますのでどしどしご利用ください。

一方でむぎたさんは私のドライバを既に試されており残念ながら上手く動作できな
かったとのことですがv1.5.0時代のコードでも大幅にSDMMCのクロック周波数を落と
さないと駄目とのことでSDMMCの各信号波形そのものが変になってる
可能性があります。

いわゆるインピーダンスミスマッチ状態で各信号の波形に相当なリンギングが発生
している事が考えられますのでオシロで波形を確認したのちインピーダンス整合用の
直列抵抗(最大47Ω)をSDMMC_CKの出力端(MCUの端子直近に)挿入する、それでも駄目
ならさらに全信号ラインにフェライトビードを挿入する等の措置でクロック周波数を
落とさずに改善できるはずです。そこまでやっても駄目なら配線の引き回し自体に
根本的な問題があるのでmicronのeMMC使用時の設計ルールを参照して基板のレイ
アウト設計から見直す必要があります。

RTOSを絡めて使用されている場合はDMA転送用のメモリ領域がDTCMに割り当てられて
おらずキャッシュの整合性が崩れてこけている可能性もあるため切り分けのために
まずはDMA版ではなくポーリング版で動作確認してみてください。

STM32F7を使ってみる16 -USB-MSCを使ってみる応用編-

前回はSTM32F7のSDMMCインターフェースを用いてDELKINの工業用SDカード
からSMARTの情報をCMD56コマンドを駆使し読み出す事に成功しました。

その前にUSBカードリーダーに直接DELKINのカードを接続した時はDelkinDashboard
なるWindowsアプリを用いるとSMART値を読み出す事が出来るのを確認しています。
そこで今回はUSB接続のカードリーダーに化ける奴でDashboardが使えるかどうか、
いくつか試してみました☆

1．OLYMPUS STYLUS TG-4
　->SMART読み出しOK!
　
　TG-4はねむいさんが品質管理の証拠写真取る際やトレランで大活躍のでぢかめです！

２．STM32Primer2 GNSS Tracker(のUSB-MSCモード)
　
　->SMART読み出しOK!!

いわずと知れたSTM32Primer2を用いたねむいさんのぶろぐ唯一の実用品です。
2009年から今に至るまで8年間、-10度～+40度の過酷な環境を耐え抜き延べ3000km
以上の山道をねむいさんと共に駆け抜けてきたすごい奴です！

３．STM32F746G-Discovery(のUSB-MSC(HighSpeed))
　
　->SMART読み出しOK!!

とりあえずSDカードが読めるUSBカードリーダー(USBマスストレージクラス)なら
何でもいけるような気がしてきましたよぅ･･･

"１．"はともかく"２．"と"３．"についてはUSB-MSCに明示的にCMD56を発行する
ようなルーチンは実装していなかったのでこれはつまりCMD56を用いなくても何か
別の方法でSMARTを読み出せられる手段があるのではないかと考えました。

そこでSTM32F746G-Discoveryを使って何が起こってるか解析してみる事にしました。
USB-MSCのSCSIコマンドを解釈するサブルーチンとSDMMCのRead/WriteにPrintfの
トラップを仕掛けどのSCSIコマンドが発行されているか、またSDカードのどの
アドレスに読み書きを行っているのかを調べます。ファームウェアを柔軟に弄る
事が出来るという市販のUSBカードリーダーでは絶対に出来ない利点がSTM32F7には
あるのです！！

STM32F746G-DiscoveryのSTLinkV2の仮想COMを開いて待機しておいた上で
Dashboardの"GO"ボタンを押すと全てが分かってしまった･･･

諸般の事情で細かい解説は省きますがある一定の順序でSDカードの特定の
ブロックアドレス群に読み書きを行う事によりCMD56による取得方法と同じ
SMART情報を得られることがわかりました･･･！

これなら特別なハードウエアを用意しなくても市販のUSBカードリーダーさえあれば
気軽にSMARTとかSDカードの寿命を確認できますね～！
それを組み込んだこいつも更なる進化を遂げてさらに最強に強まることが出来たので
ねむいさんはこれからの近畿自然歩道の攻略に向けて燃えに燃えています！
20170308追:
このような工業用SDカードの寿命診断についてですが実際は頻繁なカードの
取り外しが困難な場所や機器に特に威力を発揮します。
性悪説的に言うとケーシングや樹脂化でSDカードを完全に隠ぺいし第三者から
"SDカードを使用している機器"と分からなくして"何らかのメモリデバイス"と
して見せることにより商売上でSDAのライセンス条件を完全に逃れている場合の
リモートメンテナンスの際にも役立ちます。
正攻法でもCMD56なりUSB-MSC経由でSMART取ればいいので品質管理の面から見て
仕事が進めやすくなるのでメリットだらけですね～♥
20170308追:

でぢかめ向けには大容量品があるUtility+がよさそうですね。これも上記と同じくCMD56&
Windowsツール経由でSMART取れるので特にカードの寿命や動作環境を気にする
プロの人必須のアイテムだと思います。ねむいさんもお金に余裕が出来たら購入して
TG-4と併せて使った感想をレポートしてみたいと思います。

ちなみに民生品のSMART非対応のカードだと失敗しちゃいます。
TDKやApercer配布のSMART取得ツールだと非対応のカード使うと先頭1kb分のデータが
問答無用で破壊されてしまうのですがDelkinDashboardではそういうことはまったく
ありませんが興味本位で非対応のカードで試すのはやめておきましょう！！
とまぁこんなかんじで各メーカごとにSMARTの仕様がバラバラなのでSDAが早く統一
規格作るべきだと思いますよぅ。

さらにおまけですが･･･
解析途中でDELKINカードのパーティションの全容量と実容量が一致してなくてディスク
ユティリティーソフトが異常を検出してておかしいなと思っていたのですが･･･

STM32F7CubeのSDカードドライバ(v1.5.xまで)はSDHCにしか対応してなかったため
SDv1の初期化コマンドすらなかったのは周知のとおりですがUSB-MSCのサンプルも
その仕様を引きずっていたため正しい全容量を返していないのが分かりました。
20170329追:
SDv1どころかSDv2でも正しい全容量を返していないことが分かりました。
別な部分で一番最後の論理ブロックアドレスを示すよう-1している個所があり、
上記の部分で-1してしまうと余分に-1したことになるので実容量より1ブロック
分小さい値が返されてしまいます(ほとんどの場合は512Byte小さい値)。

具体的にはusbd_msc_scsi.cのSCSI_ReadFormatCapacity()で総ブロック数から１を
引いた数をホストPCに送っています。

一方SDHC/SDXC等の大容量のSDカードなら多少の容量の相違は無視できる
ほど小さいので問題はありませんでしたが、Delkinカードは1GBしかないため
ParagonHardDiskManagerではそれを見逃さず無効なパーティションと
見なしたようです。ちなみに値が微妙にずれた状態でもWin7からは普通に
読み書きできてました。
SDナビさん曰く、この値が容量偽装とかでズレが大幅になるとWindowsも
おかしいと検知してフォーマットを促すダイアログが出るようです。
20170329追:

そういえば今年になってv1.6.0が出てSDカード周りが刷新されたのですが待望のMMCが
追加されたのはｲｲのですがなんかいたるところが欠陥だらけで超やばいことになって
いたのですが話が長くなるので次回に続きます･･･

STM32F7を使ってみる15 -工業用SDカードからSMART情報をスマートに読み出そう-

あれ？ESP-WROOM-32が秋月から発売されて絶好のチャンスなのに
ESP-WROOM-32の記事書かないのですって？
あああれね…去年の時点で飽きました･･･今更になって弄ってるとか時代遅れ
ですよぅ！(挑発

今回はS.M.A.R.T.(以下SMARTと記載)対応のSDカードからSMART情報を読み出して
みます。別にF7じゃなくてもよいのですけど次回以降のネタに繋がる内容なので
しばし御静観願います。
今回もSTM32F746G-Discoveryを使います。

工業用のSDカードの中にはSSDやHDDのようにSMARTの情報が取れる希有なものが
存在しております。残念ながら一般に購入出来る民生向けSDカードではその
ような機能は搭載されておらず、SMART対応どころか工業用SDカードも入手が
ごく限られております。もちろん値段も民生品に比べ極めて高価です。

なんで高価かと言うとカードの動作に関する"信頼性"を保証しているからに
つきます。皆さんご存知の通り2017年現在市販で流通しているSDカードは明記が
無い限りはTLCタイプのNANDフラッシュメモリが使用されており、TLCという
のはSLCやMLCに比べて大容量が取れる割にデータ保持のための寿命が短い、
また書き換えできる回数も極端に短いという代物となっております。

一方工業用SDカードは4GB以下はSLC,それ以上の容量でもMLCを保証しており
(容量を犠牲にして疑似的にSLC風の動作をするpSLCやaMLCなんで奴もありますが)
さらにSDカード内コントローラのファームウェアもデータ保護に特化した
特別となっております。たとえばECCチェック機能とかパワーダウン
プロテクションとかオートリフレッシュ機能とかバッドブロックマネージメント、
ダイナミック+スタティックウエアレベリング等々いろいろありますが、実は
これTLCカードを世に出すために必須の技術でそれが耐久性がもともと高い
SLCやMLCを使用した工業用製品にフィードバックされて最強に強まった
信頼性を謳うわけです。

というわけでこれらの機能実装は最早当たり前となった今、カードの健康情報を
把握するための機構を仕込む事が新たな付加価値として注目されており、
各社でSMARTもしくは独自の寿命診断を組み込んだ工業用SDカードが販売
されております。

で、われわれホビイストが問題となるのはその工業用SDカードの入手から
始まりさらにSMART情報を取得するための"情報"を入手し利用せしめるまでに
多くの壁があることです！

まずDigikeyやmouser,RSの海外在庫くらいからしか工業用カードの入手法が
日本国内からではまず困難で、さらにSMART対応と謳っていてもカタログの
隅っこに(※オプション対応)とか書いてあったりして高い金出して購入したのに
目当てのSMART機能が実は搭載されてなかったとか悲惨なことがほとんどです。

それでやっと入手にこぎつけたとしてもSMART情報を取得するための手段や
ツールは公開されておらずメーカに直接問い合わせることになりますがほとんどの
場合対企業間の問い合わせにしか対応してなかったり(もちろん個人事業主として
問い合わせてもTHE・シカト)、SDAのライセンスに加入していないと情報を
渡すことができないよなどつっけんどんの反応しかもらえません。

ねむいさんも方々に手を尽くしましたが個人レベルではなしのつぶてて困り果て
ていましたが灯台下暗し、DELKINというメーカの工業用SDカードを扱っている
代理店が日本国内に存在しておりました。こちらは在庫があれば
一枚から対応(無ければ受注生産20枚単位)というホビイストにもうれしい
対応でしたので早速1GB品を注文し、ゲッツしました。

でかいDELKIN箱に小さいMicroSDが対照的です。

今となっては微々たる容量の1GB、見た目も普通のMicroSDカードですが…
このDELKINのU331というシリーズは中身は某粉飾決算にチャレンジしたおかげで
倒産寸前の日本メーカのSLC型NANDフラッシュが使用されております！
~~なにルネサスより先に死んでんだよ東芝！！１１！１１！！１！！！！！！~~
動作温度範囲もやたらと広くて-40~+85度まで保証しております。

ひとまずUSB接続のカードリーダーに接続してパフォーマンスを見てみました

規格的には"2GB以下のSDSC"に位置するカードなのでUHS-1とかには対応しておらず
理論上最大でも25MB/Secの転送スピードとなりますがマイコンで使用する限りでは
ハイスピードモード(最大SCLK=50MHz)に対応さえしてれば全く問題ないです。

SMART情報をPC経由で取得するために"USBカードリーダ"を用いて
"DELKIN DashBoard"なるアプリケーションを使用する必要があります。
ねむいさんの持っているTranscend製のUSB3.0カードリーダーは無事に
SMART情報を読み出すことができました。やったぜ！
どういう理屈でSMART読み出してるかしらないけど(伏線)

ちなみに"DELKIN DashBoard"の動作保証しているDELKIN製カードリーダーは
上記のねむいさんのもってるTranscendのと全く同じチップが使用されてます。

お次はSTM32を使って動作させてみます。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Dec  6 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 14338 kB/sec.

>ds 0

rc=0

Drive size: 1947648 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Byte)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  00 5E 00 32 5B 59 A3 B6 FF FF FF 80 0A 40 00 6D .^.2[Y.......@.m

CID:

00000000  58 44 44 44 44 49 4E 43 30 6D 6D D4 59 01 0C 49 XDDDDINC0mm.Y..I



Parsing SD CID Register

Manufacturer ID    :0x58

OEM/Application ID :DD

Product Name       :DDINC

Product HwRev      :3

Product SwRev      :0

Serial Number      :0x6D6DD459

DateCode.Month     :12

DateCode.Year      :2016



OCR:

00000000  80 FF 80 00 ....

SD Status:

00000000  80 00 00 00 00 00 00 28 03 03 90 02 00 AB 00 00 .......(........

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 25 80 00 01 00 00 00 .%......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Spec Version X  :0

SD Security        :2

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDSC Card!

Available NS(or HS) Mode Only.

>

先ずはいつものでSDカードの情報を読み出してみました(これだけSTM32F429を使用)
2016年製！
ATPの工業用カードでもそうでしたが現在はW/R性能はSDカード内コントローラの
ファーム次第なのでSLCとはいえ転送速度がめちゃくちゃ早いとは言えません。
どちらかと言うとSLCを使う理由は速さよりもデータの確実性を求める方向に概念が
遷移していると感じます。

そしてついにSTM32F7-Discoveryを使いSMART情報の読み出しに掛かります！
このDELKINのカードはSDカードに昔から存在するCMD56という"汎用コマンド"を
用いてSMART情報の取得を行います。SMART情報を取得する方法は各社バラッバラで
門外不出の所もありますがDELKINは"CMD56でSMART採れるYO!"と公言している
ためかなりフレンドリーと感じます。

この"CMD56"は引数によってデータの受信送信を変えることができるコマンドで
CMD17等のシングルブロック転送と同様最小512Byte単位でやり取りをおこないます。
DELKINカードにおいては特別な引数で、ある一定の順番で、CMD56の送受信動作を
行うことにより目的とするSMARTの情報を得ることができました。

↓

DelkinDashboardとCMD56で読みだしたSMART直値をUARTに吐かせて値の
比較です。カードに何らかの書き込み動作を行うと電源再投入時にDashboardの
"TotalPowerupCount"に相当するSMART直値が更新されているので正しく
SMARTが読めていると判断しました。
ところで具体的にどうやってCMD56投げたのと知りたい方がいると思いますが
対価を払って得た情報ゆえこのぶろぐ上で詳しく公表できません
が…
…おや？このデータシートDELKINと関係ないのになんだかそっくりだー(棒読み

詳しくは言えませんが512バイト分のSMART情報のフッタに相当する部分の
データがCIDの情報と一致しておりました。何かのvalidationに使うので
しょうか???????(棒読み
まぁあまり重要な情報ではないでしょう(伏線

このDELKINカードを選んだ理由は拙作のSTM32Primer2を使ったGNSSロガーの
信頼性向上につきます。一度Primer2の筐体中に組み込んでしまうと構造上
ケースの中にカードが封印されてしまうため簡単に取り出せなくなるのでSDカードの
寿命診断を何らかの形で外部から行いたいと思いSMARTが取れるカードを選んだ…
と言う経緯です。
次回のちょっとネタバレになりますがこのGNSSTrackerのマスストレージモード
でもDelkinDashboardを使いSMARTの取得に成功しています。
なんでCMD56発行してないのにSMART採れるんでしょうね(意味深

願わくばSMARTを利用した寿命診断機能がSDAで正式に規格化され、民生用の
SDカードでも気軽に寿命診断できる素敵な時代が来るようになることを願います。

だからSDAの中の人のPanasonicさん頼みますよ！
なぜか不自然なくらいﾊﾟﾅ推しのねむいさん。

ここでねむいさんFAQ特別編
Q:ねむいさんねむいさん、確実にSLCのカードを見極める方法を教えてくださいっ！
A:

　SLCってカードにでかでかと書いてあるカード選べばＯＫです☆

STM32F7を使ってみる14 -HS ULPIでUSB-MSCを使ってみる-

みなさまあけましておめでとうございます

今年もねむいさんほか虹裏メイドたちをごひいきにm( )m
今年はねむいさんのイラストが100枚くらい増えますように
↑本音

さて新年早々ですがHALライブラリにバグを見つけたので解説しようと思います。

遡る事約一ヶ月前、ねむいさんはSTM32F7で新しい事をやろうとCubeF7に同梱されて
いるUSBライブラリとそのExamplesたちに手をつけ始めていました。
STM32F746G-DiscoveryにはULPIとかついているのでUSB-MSC(MassStorageClass)の
実装を試みました。もちろんUSBのバス速度はHighSpeed(480Mbps)です。

幸いにもSTM32F746G-Discovery向けのサンプルコードもあったのでそれを
ねむいさん謹製のいつものをベースに実装しようとしましたがUSBライブラリが
DMA使ってるくせにキャッシュの事全然考えてない作りでそれにブチ切れながら
GCC向けに移植していましたが最終的にL1キャッシュがないと足を引っ張る
SRAM1,SRAM2を使わずにノーウエイトでアクセス出来るDTCM領域だけでがんばる
ことにしました･･･orz

Ac6STM32用のプロジェクトファイルのリンカスクリプトもそうなってますし
･･･フォーラムでも奇跡の積み重ねで動いてると情けない指摘を
されています。HALライブラリみたいなバグだらけの変なものリリースしっ放し
にしてないできっちりバグつぶせYO!
☝って言ったらたくさん非難されていっぱい哀しい…

と言いつつも何とか動いて認識しました♥

もちろんeMMCとかもしっかり認識しちゃいます★

とおもったらまだ問題がありました…幾つかのカードでデータが正常に
読み込めない事がありました。

64GBのカードでも容量はしっかり見えてるんですけどね…なんか4GB以上
データを詰めてるカードで動作がへんなのです…
…
…4GB…？これって…

かつてUSB付きのARMマイコンでMSCのサンプルではカード容量を示す変数が
uint32_tで現わされていて4GB以上の容量を正しく表示できないという
4GB問題がありました。対策は単純に容量を示す変数をuint32_tから
uint64_tへ変えるだけのものなのですがUSBライブラリを見る限りでは
それはちゃんと64ビット変数になっており問題がありませんでした。

しかしブロックアドレスにブロック容量を掛け算し代入してやがる式を
見つけました。指定するブロックアドレスによってはuint32_tで扱える
範囲を超えてしまう可能性があります。このscsi_blk_addrって奴なのですが
まさか…まさか…

ﾃﾞﾃﾞｰﾝ
…
思いっきりuint32_tじゃん…
…
ば　っ　か　じ　ゃ　ね　ぇ　の　！　？
ねむいさんのむなしい叫び越えが夜の闇にこだまする。

ていうわけでscsi_blk_addrをuint64_t化すると4GB以上データ詰めている奴でも
正常に読み書きすることができるようになりました…なんちゅう初歩的な。

一応フォーラムにも報告しておきましたがSTM32フォーラムのguruと呼ばれている
clive師より｢ブロックアドレスをいれた変数にバイトアドレスに変換した値を放り
込むSTの昔っからのコーディング姿勢自体が愚。scsi_blk_addrの安易な64bit化は
不必要」と指摘されましたがねむいさんもごもっともだと思いました。

そんなわけで漸く正常に繋がるようになったので読み込み比較です。今回は
USBの転送用に確保していると思われるバッファの容量を増やすことで転送
スピードがどこまで変わるか見てみました。

条件STM32F746G-Diacovery,USB-HS ULPI,最適化オプションは"-s"
132MBのmp3ファイルをFastcopyを使ってPCのRAMDISKへコピーする時の平均転送速度を記録。
SDのクロックはNS(24MHz)とHS(48MHz)で比較。

ある程度分かっていたことですがやはり容量を増やしていくと転送スピードは
上がっていきましたがある程度(16kb以上)以上で転送スピードは横ばいになる
ことが分かりました。これはNSとHSもほぼ同様の傾向なので16384byte以上
パケット容量確保してもそれ以上は余り効果がないことが分かります。
まぁこれだけ速度出せたら御の字でしょう。とにかく16384byte分確保して
おけば何の問題もないですね。

ちなみに今回はお仕着せEclipse環境のAC6STM32で一旦プロジェクトをビルドして
ねむいさん環境に移植しましたが(単にリンカスクリプトをDTCMしか使わない
ようにしただけですけど)もっと性能の高いF769I-Discoveryで何で
試さなかったの？と言う話になるでしょうけど理由が…

CPUが対応してない･･･このせいでボード対応しててもビルドが通らないorz

やっぱ自分でmakefile書いてコマンドラインビルドが最強ですって☆

STM32F7を使ってみる13 -STM32F769I-Discoveryを動かしてみる2-

>ARM、禿に喰われる
>ARMはもう終りDA!
うろたえるな小僧共ー！

(↑C.V.牡羊座のシオン様で)

禿の習性からして中身ろくに見ないでまーた買い物のための買い物やっただけだから
アリババの時みたいにどうせすぐにリリースしちゃうでしょう。
ていうか"買収する"と言ってるだけで20160803の時点で買収が完了"した"とは
言ってないのでまだ禿に喰われてすらいない段階ですね。

こと電子工作で使用するARMマイコンの範囲においてはまったく何の影響も出ない
と思います。尤もARMが禿に衰退させられるような程度のジョンブル野郎だったの
ならねむいさんのほうからお断りで自然歩道一本に絞ってこのぶろぐ続けます。

というわけでこの件についていろいろ質問もらったので虹裏メイドねむいさんとしての
見解をさせていただきました。かしこ。

20160906追：
正式に買収完了と同時に上場廃止になりました。
ねむいさんとしても今後の禿の動向に注視いたします。
最悪のシナリオは小規模マイコン向けのコアIPが捨てられることです。
20160906追：

20170411追:
少し前の話ですが予想通り早々に4分の一を売却するそうです…
ねむいさんの予想以上に売るの速かったわ！
今度はアラビアンARMになるのですね…
20170411追：

20230918追:
ARMが小文字armになって幾数年…
armは再び再上場する運びになりました！！
20230918追：

すみませんうっかり本日のぶろぐ終わらせそうになってしまいました。

今回は主にSTM32F769I-Discoveryに実装されたAudioCodecを利用してサウンド
再生機能つけるべく頑張ってみました。

●STM32F4-Discoveryからのサウンド再生機能の移植

STM32F769I-Discoveryはご覧のとおりAudioCodec(WM8994)とは生粋のI2Sでは
無くSAI(SerialAudioInterface)のI2S機能から接続されています。
基本的なものはSTM32F4-Discoveryの時と同じなので基本的な部分を押さえつつ
F7のHALに合わせるよう移植していきました。

困ったのがサンプルレートから実際のI2S用のクロックを生成する関数で既存の
BSPの関数を流用すると何でか2倍速で再生してしまうという現象にぶち当たって
しまったことです。
これなんとなくHALのバグっぽいな～と思っているのですがeMMC対応したときに
かなり時間を喰って懲りているので深追いはせず、自作のテーブルを参照して
適切なPLL値をPLLI2Sに付与する関数を経由させるようにしました。
ややこしいですがSAIのクロック元はPLLI2Sから供給しています。
BSPもそのようになっています。

ていうわけで2作業日くらいで移植完了です。
画像はmp3ファイルを再生しているところです。画面のIART,INAMはID3v1もしくは
ID3v2タグを解析し表示しております。aac,wavファイルも同様に再生できます。

最初にmp3を移植した頃は良く分からなくて実装していなかったのですが、ID3に
格納されている"UTF-16LE"の文字列をChaN氏のFatFsに収録されているff_convert()
関数を用いてS-JIS形式の2バイト文字に直して表示するようにしました。もちろん
ascii形式でも崩れないように対策済みです★
ていうかID3関連はかなり長い期間適当に作って放置しててID3タグ解析の段階でコケて
mp3/aac形式ファイルが再生できない場合があったのず～～～～っと放置してました
ごめんなさいごめんなさい！！！！！
STM32F4のほうも今回の修正は横展開しておきましたのでご安心ください。

STM32F769I-DiscoveryなんてもってないYO!という方もご安心ください！
makefileの定義を変えるだけで秋月さんのところで購入できるSTM32F746G-Discovery
でも同じようにオーディオファイルの再生が可能です！

そいえばビットレートが高いデータをサーキュラDMAでバリバリ送る使い方すると
SDIO/SDMMCのDMA転送に干渉してコケる問題はSTM32F7になっても解消されて
いないのでmp3/aac/wav形式対応にした場合SDMMCはDMAでは無くFIFOの
ポーリングで転送するようにしておりますorz

さらにポーリングの場合はSDIOのクロック周波数が高い場合受信時のアンダー
フローが起こりやすいのでハードウエアフローコントロールを有効にするように
しました。STM32F4ではエラッタで使用不可とされてきましたがF7シリーズでは
解禁です★

さらにさらにですが昨年STM32F4で行ったアライメントズレ対策をSTM32F7に展開
して実装した際に大バグを作りこんでいた事が発覚しコレも修正しています･･･
一年以上ほっぽっていましたが皆raspberryに逝っちゃってSTM32F7に見向きも
しなかったのでばれずに助かりました･･･これもID3タグ解析の実装見直した
ときに発覚orz

●画面がでかくなったからでかいサイズの動画再生してみる
ChaNさんのLPC2388向けFatFs移植例には独自形式で動画を再生できる機能がありま
した。ねむいさんはこれを他マイコン向けに拡張しつつ使い続けてきました。

STM32F769I-Disccoveryになって画面サイズが800x480に一気に広がったので、
少しデカめのファイルを作ってちゃれんぢです。

とある動画からAVCフォーマットでエンコードされたmp4形式のファイルをAviutilで
無圧縮aviにしてそこからChaN氏のツールで独自形式のファイルに直します。

ちなみに独自形式に変換するavi2imgはChaN氏のFatFs実装例ffsample.zip内¥lpc23xx¥tools¥にあります。
今回のねむいさんの移植例ではDMA2Dの関係でビッグエンディアンが要求されるので
avi2imgを自前でビルドしなおさなければなりません。さらに最大サイズも変更する
必要があります。真似される方はご注意ください。

再生するプログラムのほうも少し手を加えました。
ファイル名と現在フレーム/総フレームを表示できるようにしておきました。

また、display_basis.hのENABLE_PERFORMANCE_MEASUREMENTのdefineを
有効にすると上記の代わりに一秒あたりのフレーム数を表示できるようにしました。

この動画は640x360サイズあります。一ドットあたりRGB565の16bit=2バイトあるので
一画面あたりのバッファサイズは640*360*2=460800byte必要です。そこから30fpsの
動画を表示せしめようとしたら460800*30=13824000(byte),つまり約13.8MByte/Sec
の速度で読み出さないといけないためSDMMCのNomalSpeedMode(MAX12.5MByte/Sec)
ではまったく歯が立ちません。

この動画はオリジナルは29.97fpsとなっており、そこから生成されるimgファイルも
同じく29.97fpsのためノーマルスピード(ねむいさんの移植例ではSDMMC用のベース
クロックがPLLSAIから生成される48MHzからのため最大12MByte/Sec)では先に述べた
とおりまったく足らず20fps前後しか出ません。

SDMMCのクロックをハイスピードモード対応(ねむいさんの移植例では最大24MByte/Sec)
にすると転送が余裕で間に合うためきっちり29.97fpsが出ます♥
う↑ま↓ぃ↑やったぜー
さすがにこれ以上のサイズだと転送サイズも肥大化していくためスムーズな再生は
難しくなりますがねむいさんはﾀｲﾁｮｳの作る動画がオリジナルサイズとFPSで再生でき
ればそれで満足なのでコレでよしとします。ぜんぜんよくないですけど。
使用するSDカードそのものの転送速度も重要になるはずなのでこちらを熟読して、
私の真似される方はカードもしっかり選んでみてください。

･･･ぇ？元の動画を見てみたいですって？･･･まあ別にいいですけど動画内コメントに
警告がありますが桁外れにヤバイ内容なので無理だと感じた方はすぐにブラウザを
閉じて退避した方がいいと思います

"すぐに"を具体的に言うと最初の3フレームめまでです。時間で言うと100mSec以下の
反応速度でブラウザを閉じれば安全となります。ねむいさんのぶろぐを会社や学校
から見ているクレイジーな方々はuSecオーダーで超反応できる人間だらけなので
多分大丈夫と思います。ちなみにねむいさんのSTM32F7のサンプルから再生した場合、
タッチパネルの読み込みが100mSec間隔のため逃れられません。覚悟してください。

ねむいさん的にはゼEROの中でもコレはテーマ性・ストーリー性・変態性・音楽性・
危険性・テンポ・○ンポの全てが危険水準を大きく逸脱した迷作中の冥作であり、
634ﾀｲﾁｮｳの無限の可能性と危険性を垣間見ることが出来る貴重な作品であると確信
しているのですがリアルタイムで投下されたときはこの人本当に気が狂ってしまった!
と思ったのですがこんなヤバイ動画ばっかり作っててラブライバーに自爆テロ食ら
わないのかYO!大丈夫か曜!とか思っているのですがねむいさんもイケナイお口のほむコラばっかり
やっててやってる事あんまし変わらないかもと思っているのです！が！
虹裏メイドねむいさんは｢ラブライブ！サンシャイン！！｣を応援しております！
.見ないと注↑射↓なんですぅ♥

戯言はこの辺にしてちょっと早いですが上記の更新を追加したSTM32F7のいつもの
をいつもの場所に上げておきます。この一ヶ月間でFatFsにも大量にぱっちが
当たってR0.12aになっていますので全て適用しております★
上のほうでも述べましたがSTM32F4にも横展開しましたのでSTM32F4-Discovery
しかもっていない･･･！なんていう方も安心です♥

次回は真面目にブログ更新します！！！！！！！！！！！

STM32F7を使ってみる12 -STM32F769I-Discoveryを動かしてみる-

超忙しい状態が続いてるせいかせっかく買ったのに半月ほど寝かせてたらその間に
円安が進んで損しましたorz

それはおいといてSTM32F769I-Discoveryを私も手に入れました★昨年販売された
STM32F746G-Discoveryを機能的に踏襲しつつ新たな機能が更に盛り込まれています。

今回の目玉はMCUのF7系最強のSTM32F769Iなわけですが、今回ついに、ついに倍精度
浮動小数点ユニットが搭載されることとなりました！！長かった･･･
ついでに細かいCortex-M7のエラッタがさりげなく直されていますがあとで紹介します。

ハードウエア的には前回は16bit分減らされて容量も半分しか使えなかったSDRAMが
32bit分全開使えて容量もアップした事とすっかりおなじみになったQSPIも64Mbyte品
に容量アップでまさに最強に強まっています！！！

では早速電源投入を･･･
･･･ぁ･･･microUSBコネクタだ･･･

microUSBケーブルを引っ張り出してきて改めて電源投入！

なんかTouchGFXというのとEmbeddedWizardとかいうのが新たにメニューに追加
されていますね。

TouchGFXのBirdtheCoinとかいうのをやってみましょ

･･･！！！
クソゲーすぎる･･･
DMA2Dのパフォーマンステスト兼ねてるみたいですね。

さてお次はEmbeddedWizardです

容量性タッチパネルコントローラの機能を最大限に生かした入力デモが利用できます。

このようなオシロ風表示もらくらくです★

お遊びはこの辺にして私のいつものをF769Iに移植してみました。

移植に関してですがF746シリーズと決定的に違う点は内蔵RAMが増量、PLL-Rが追加
されているのと倍精度浮動小数点演算ユニットの対応です。
newlibで倍精度演算ライブラリを利用できるようにするためにはGCCコンパイラに
"-mfloat-abi=hard -mfpu=fpv5-d16"を渡すべきです。

後は液晶表示のためのペリフェラルがRGBでは無くDSIを利用している点です。
DSIは速度が速すぎるため、他ポートとの兼用はしておらず完全独立しております！
DSIの叩き方等の見本はBSPが充実していますのでライセンスに乗っ取ってまるっと
利用させてもらいます。

そんでもってSDMMCのポートは二つに増えましたがこのボードではSDMMC2のみを
SDカード用のポートとして利用していますのでこちらに替えるようにします。

そしてOpenOCDでビルドしたバイナリを焼く･･･！
ねむいさんのおきぱのOpenOCDバイナリはSTM32F76x/77x系にすでに
対応しています★

いつものが無事起動しました。SDカードもしっかり見えてディレクトリを
読めています！

libjpeg,giflib,libpng等の画像デコードもいつものように無事に表示できてます♥
でも展開時の表示がなんかもたついてる感じがするんですよね･･･
解像度が800x480に上がったせいかはたまたDSIとDMA2Dの連携が上手く
いってないのかこの辺の調査は次回に繰り越します。

あと今回重要なポイントは冒頭で述べたCortex-M7コアのエラッタでデバッグ時に
ペンディングビットが立った状態だとブレークポイント張ってないのにもかかわらず
強制的にその割り込み処理の先頭でブレークしてしまうと言うちょっと厄介な
エラッタが修正されています。
画像はF746におけるUART割り込みでブレークポイント無効なのに何故かUARTの
割り込み処理の先頭でとまっちゃているのが分かると思います。

というところで駆け足で紹介しましたが今からF7に入門される人たちは上記
エラッタが修正されたSTM32F769が搭載されているSTM32F769I-Discoveryを
購入して遊ぶのが最も最適かと思います。

んでもって私のF7のサンプルはすでにSTM32F769I-Discoveryに対応している
(もちろんmakefileの設定でF746-G化も可能です)ので手前味噌でありますが
どしどしご利用ください！

STM32F4シリーズを使ってみる15 - FatFsとSDカード再考その4(SDカードを手当たりしだい読み出してみる) -

一年以上ぶりの企画になってしまいましたが前回の続きです。
STM32F4を使ってSDカードのカード情報を読み出したり読み取り速度の比較を
行います。

とりあえず手持ちのカードを全部！！！

MMCから始まり10年以上前のSDカードや最新のSDXCまで網羅します！！

条件は以下のとおりとします。
・各カードはあらかじめSDFormatterでFAT32でフォーマットする。
　64GB以上のSDXCもHardDiskManagerで無理やりFAT32でフォーマットします。
・プログラムはSTM32F4版のいつものの3/31日版とします。
・使用するボードは180MHzで動作可能なSTM32F427IIT6が乗った
　STM32F4全部乗せボードを使用します。
・SDのクロックはハイスピードモードとします。このボードでは
　SDIO_CLKの最高クロック周波数は51.43MHzとなります。
　また、SDIOの転送にはDMAを使用します。
・読み出し速度は132949600Byteのファイルのシーケンシャル読み出しの速度を
　比較します(128MBのMMCv3を除く)。また、ねむいさん的には読み出ししか興味
　ないので書き込み比較はやりません。

それでははじめましょう！

●Toshiba製eMMCv5 8GB

まずは前回のおさらい、Toshiba製のeMMC8GBです。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr  3 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 22961 kB/sec.

>ds 0

rc=0

Drive size: 15269888 sectors

Erase block size: 1024 sectors

Default r/w block size: 512 bytes

Card type: MMC(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  D0 5E 00 32 0F 59 03 FF FF FF FF EF 92 40 00 D3 .^.2.Y.......@..

CID:

00000000  11 01 00 30 30 38 47 45 30 00 5A DD 41 40 B2 0D ...008GE0.Z.A@..



Parsing MMC CID Register

Manufacturer ID    :0x11

OEM/Application ID :<0>

Product Name       :008GE0

Product Rev        :0.0

Serial Number      :0x5ADD4140

DateCode.Month     :11

DateCode.Year      :2015



Detected as MMCv5.0x Device!

OCR:

00000000  C0 FF 80 80 ....

読み出し速度が22961kByte/SecとSDカードを抑えてダントツに早いです！

●Transcend製2GB MMCplus

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Mar 22 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 21261 kB/sec.

>ds 0

rc=0

Drive size: 3939328 sectors

Erase block size: 256 sectors

Default r/w block size: 1024 bytes

Card type: MMC(Byte)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  90 2F 00 2A 1F 5A 83 C1 B6 DB 9F FF 96 80 00 3F ./.*.Z.........?

CID:

00000000  37 FF FF 4D 4D 43 30 32 47 10 F3 02 67 50 2C F5 7..MMC02G...gP,.



Parsing MMC CID Register

Manufacturer ID    :0x37

OEM/Application ID :��

Product Name       :MMC02G

Product Rev        :1.0

Serial Number      :0xF3026750

DateCode.Month     :2

DateCode.Year      :2009



Detected as MMCv4.0 Device!

OCR:

00000000  80 FF 80 80 ....

こちらもなかなかのお手前で。

●日本製MMCv3カード

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr  3 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fl

D---- 2016/03/14 23:28         0  .             

D---- 2016/03/14 23:28         0  ..            

----A 2010/03/13 20:06  44679600  ftbt.mp3      

   1 File(s),  44679600 bytes total

   2 Dir(s),   83640320 bytes free

>fr 44679600

44679600 bytes read with 1904 kB/sec.

>ds 0

rc=0

Drive size: 250880 sectors

Erase block size: 32 sectors

Default r/w block size: 512 bytes

Card type: MMC(Byte)

SpeedMode: NomalSpeedMode(17.14MHz)

DataBusWidth: 1bit



CSD:

00000000  8C 26 01 2A 0F 59 81 E9 F6 DA 81 E3 9E 40 00 7D .&.*.Y.......@.}

CID:

00000000  11 00 00 30 31 32 38 4D 32 0A 05 80 FE CB 28 7D ...0128M2.....(}



Parsing MMC CID Register

Manufacturer ID    :0x11

OEM/Application ID :<0><0>

Product Name       :0128M2

Product Rev        :0.10

Serial Number      :0x0580FECB

DateCode.Month     :2

DateCode.Year      :2005



Detected as MMCv3.xx Card!

OCR:

00000000  80 FF 80 00 ....

MMCv3は20MHz以下のクロックでなければいけないのでそれを守っています。
20MHz以上では確かに動作しませんでした。

ここから先はSDカードです。

●Transcend製x600のMicroSDHC8GB(TS8GUSDHC10U1)

昨年末に紹介したMLCアピールの奴です。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Mar 22 2016

>fg piano

rc=0 FR_OK

>fo  1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 20025 kB/sec.

>ds 0

rc=0

Drive size: 15759360 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5B 59 00 00 3C 1D 7F 80 0A 40 00 63 @..2[Y..<....@.c

CID:

00000000  74 4A 60 55 53 44 55 31 20 3B A1 5F AA 00 F6 25 tJ`USDU1 ;._...%



Parsing SD CID Register

Manufacturer ID    :0x74

OEM/Application ID :J`

Product Name       :USDU1

Product HwRev      :2

Product SwRev      :0

Serial Number      :0x3BA15FAA

DateCode.Month     :6

DateCode.Year      :2015



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 03 00 00 00 04 00 90 00 08 11 39 00 ..............9.

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 80 03 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDHC Card!

結構読み出しが早いですね。SDカードでは20000kB/Sec以上だと
早い部類です。

●Transcend製x600のSDHC32GB(TS32GSDHC10U1)

今度はさっきの32GB版、かつ通常サイズのものです。
今年春までTG-3の撮影用記録媒体として活躍していました。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr  3 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 18130 kB/sec.

>ds 0

rc=0

Drive size: 63272960 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5B 59 00 00 F1 5D 7F 80 0A 40 00 79 @..2[Y...]...@.y

CID:

00000000  74 4A 60 53 44 55 31 20 20 46 F9 B9 1D 00 F5 67 tJ`SDU1  F.....g



Parsing SD CID Register

Manufacturer ID    :0x74

OEM/Application ID :J`

Product Name       :SDU1 

Product HwRev      :2

Product SwRev      :0

Serial Number      :0x46F9B91D

DateCode.Month     :5

DateCode.Year      :2015



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 05 00 00 00 04 00 90 00 08 11 39 00 ..............9.

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 80 03 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDHC Card!

まずまずですね。

●Transcend製MicroSDHC8GB

普通の廉価版の奴です。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr  3 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 15279 kB/sec.

>ds 0

rc=0

Drive size: 15456256 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5B 59 00 00 3A F5 7F 80 0A 40 00 43 @..2[Y..:....@.C

CID:

00000000  74 4A 45 55 53 44 55 31 02 05 B0 00 60 00 D1 E3 tJEUSDU1....`...



Parsing SD CID Register

Manufacturer ID    :0x74

OEM/Application ID :JE

Product Name       :USDU1

Product HwRev      :0

Product SwRev      :2

Serial Number      :0x05B00060

DateCode.Month     :1

DateCode.Year      :2013



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 03 00 00 00 04 00 90 00 08 11 19 00 ................

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 80 03 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDHC Card!

廉価版だけに速度はそれなりです。

●SuperTalent MicroSDHC 4GB

お店で同容量比で最安値に近い値段で買えたSupterTalentのSDカードです。
たしか780円でした。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr  3 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 13677 kB/sec.

>ds 0

rc=0

Drive size: 7841792 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5B 59 00 00 1D E9 7F 80 0A 40 00 69 @..2[Y.......@.i

CID:

00000000  73 42 47 4E 43 61 72 64 10 19 23 6D 71 00 BB 81 sBGNCard..#mq...



Parsing SD CID Register

Manufacturer ID    :0x73

OEM/Application ID :BG

Product Name       :NCard

Product HwRev      :1

Product SwRev      :0

Serial Number      :0x19236D71

DateCode.Month     :11

DateCode.Year      :2011



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 02 00 00 00 04 04 90 00 08 05 00 00 ................

00000010  00 00 00 00 00 00 00 00 00 53 4D 49 00 00 00 00 .........SMI....

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 80 00 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDHC Card!

リードが13MB/Sec･･･ﾀﾞﾒﾀﾞﾒですね。

●SuperTalent MicroSDXC64GB(FAT32 Format)

続いては64GB版のSDXCの奴です。フォーマットは無理やりFAT32で
行ったうえで試しました。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Mar 22 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 15772 kB/sec.

>ds 0

rc=0

Drive size: 125302784 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5B 59 00 01 DD FD 7F 80 0A 40 00 07 @..2[Y.......@..

CID:

00000000  28 42 45 20 20 20 20 20 02 00 33 3C 22 00 FA D3 (BE     ..3<"...



Parsing SD CID Register

Manufacturer ID    :0x28

OEM/Application ID :BE

Product Name       :     

Product HwRev      :0

Product SwRev      :2

Serial Number      :0x00333C22

DateCode.Month     :10

DateCode.Year      :2015



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 08 00 00 00 04 00 90 00 08 11 19 00 ................

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 45 80 03 00 00 00 00 .E......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Security        :4

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDXC Card!

4GBの奴よりマシなものの15MB/Secちょっと･･やっぱしダメですね・・・
ちなみにSCRの値が示すとおりちゃんとSDXCとして認識できているので
カードとしてはれっきとしたSDXCです。

SDHCとSDXCの見分け方は容量のほかにSCRのSD Securityのバージョンから
分別することも可能です。

●KingMAX MicroSDHC32GB

こちらも廉価で替えるカードの筆頭です。
当時ちょっと値が張った32GBをFatFsの動作確認用に購入していました。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr  3 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 13668 kB/sec.

>ds 0

rc=0

Drive size: 62683136 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5B 59 00 00 EF 1D 7F 80 0A 40 00 27 @..2[Y.......@.'

CID:

00000000  13 4B 47 53 44 33 32 47 10 C2 00 51 1A 00 C7 A3 .KGSD32G...Q....



Parsing SD CID Register

Manufacturer ID    :0x13

OEM/Application ID :KG

Product Name       :SD32G

Product HwRev      :1

Product SwRev      :0

Serial Number      :0xC200511A

DateCode.Month     :7

DateCode.Year      :2012



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 05 00 00 00 04 04 90 00 08 05 00 00 ................

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 80 00 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDHC Card!

SuperTalentと同じ13MB/Sec...ﾀﾞﾒﾀﾞｺﾘｬ

●Toshiba EXCERIA 16GB Type2国内正規版

こちらはTG-3の購入と同時に購入した国内の正規品です。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr  3 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 21617 kB/sec.

>ds 0

rc=0

Drive size: 30867456 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5B 59 00 00 75 BF 7F 80 0A 40 00 93 @..2[Y..u....@..

CID:

00000000  02 54 4D 53 44 31 36 47 86 DE 58 C2 6E 00 E3 23 .TMSD16G..X.n..#



Parsing SD CID Register

Manufacturer ID    :0x2

OEM/Application ID :TM

Product Name       :SD16G

Product HwRev      :8

Product SwRev      :6

Serial Number      :0xDE58C26E

DateCode.Month     :3

DateCode.Year      :2014



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 04 00 00 00 04 03 90 02 00 06 1A 00 ................

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 B5 80 03 32 02 23 82 ....2.#.



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDHC Card!

20MB/Sec越えです･･･やったね☆
値段張った甲斐がありました･･･

●Toshiba EXCERIA MicroSDHC32GB 並行輸入版

今度は並行輸入版の奴です。高速の信号のやり取りを意識してか
いかなる変換アダプターも使用不可と警告がありました。ねむいさんの
使用法では高々50MHzぽっちなので別に関係ありませんが。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr  3 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 22154 kB/sec.

>ds 0

rc=0

Drive size: 61079552 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5B 59 00 00 E8 FF 7F 80 0A 40 00 AF @..2[Y.......@..

CID:

00000000  02 54 4D 55 43 30 44 33 20 E9 C2 CF A5 00 EC 01 .TMUC0D3 .......



Parsing SD CID Register

Manufacturer ID    :0x2

OEM/Application ID :TM

Product Name       :UC0D3

Product HwRev      :2

Product SwRev      :0

Serial Number      :0xE9C2CFA5

DateCode.Month     :12

DateCode.Year      :2014



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 05 00 00 00 02 02 90 02 00 06 3C 00 ..............<.

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 B5 84 03 32 02 29 02 ....2.).



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :1

SD Security        :3

SD Bus Width       :5



SD_Spec V4.xx!

Detected as SDHC Card!

おおっ！東芝のeMMCv5に匹敵するスピードですよぅ!!
こいつはオススメです☆

●Toshiba8GB MicroSDHC

廉価な東芝製のmicroSDHCです。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr  3 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 20202 kB/sec.

>ds 0

rc=0

Drive size: 15564800 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5B 59 00 00 3B 5F 7F 80 0A 40 00 75 @..2[Y..;_...@.u

CID:

00000000  02 54 4D 53 44 30 38 47 56 C0 14 C0 4F 00 B1 C5 .TMSD08GV...O...



Parsing SD CID Register

Manufacturer ID    :0x2

OEM/Application ID :TM

Product Name       :SD08G

Product HwRev      :5

Product SwRev      :6

Serial Number      :0xC014C04F

DateCode.Month     :1

DateCode.Year      :2011



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 03 00 00 00 04 03 90 08 00 F2 19 00 ................

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 B5 80 03 28 03 51 02 ....(.Q.



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDHC Card!

これもなかなかですね～

●Panasonic 2GB MicroSD

380円でたたき売りされていたMicroSDです。
STM32Primer2用に控えで購入していました。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr  3 2016

>fg piano

rc=0 FR_OK

>fo  1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 10776 kB/sec.

>ds 0

rc=0

Drive size: 3862528 sectors

Erase block size: 8192 sectors

Default r/w block size: 1024 bytes

Card type: SDv2(Byte)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  00 7F FF 32 5F 5A 83 AE F6 DB DF FF 8E 80 00 4B ...2_Z.........K

CID:

00000000  01 50 41 53 30 32 47 46 12 43 20 E0 52 00 B6 E1 .PAS02GF.C .R...



Parsing SD CID Register

Manufacturer ID    :0x1

OEM/Application ID :PA

Product Name       :S02GF

Product HwRev      :1

Product SwRev      :2

Serial Number      :0x4320E052

DateCode.Month     :6

DateCode.Year      :2011



OCR:

00000000  80 FF 80 00 ....

SD Status:

00000000  80 00 00 00 00 00 00 28 02 02 90 00 10 05 00 00 .......(........

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 25 00 00 00 F0 02 10 .%......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :0

SD Spec Version 4  :0

SD Security        :2

SD Bus Width       :5



SD_Spec V2.00!

Detected as SDSC Card!

まぁこんなものですね･･･

●Panasonicの512MBSLC金色カード

これは他の奴らとは一味違います！！！
Panasonic製の工業用SDカードです！！！
そしてTLCが全盛になった今希少なS・L・C!!!!

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Mar 22 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 17939 kB/sec.

>ds 0

rc=0

Drive size: 967680 sectors

Erase block size: 4096 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Byte)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  00 0E 01 32 5B 59 81 D8 7F FF FF FF 12 40 00 FD ...2[Y.......@..

CID:

00000000  01 50 41 52 46 35 31 32 23 74 EF 95 6D 00 F6 B9 .PARF512#t..m...



Parsing SD CID Register

Manufacturer ID    :0x1

OEM/Application ID :PA

Product Name       :RF512

Product HwRev      :2

Product SwRev      :3

Serial Number      :0x74EF956D

DateCode.Month     :6

DateCode.Year      :2015



OCR:

00000000  80 FF 80 00 ....

SD Status:

00000000  80 00 00 00 00 00 00 14 03 03 80 00 08 07 00 00 ................

00000010  00 00 00 00 00 00 00 00 00 98 DC 90 26 76 16 08 ............&v..

00000020  01 00 93 02 41 12 22 00 00 00 00 00 00 00 00 40 ....A."........@

00000030  29 29 00 00 10 20 82 88 00 01 C6 00 00 00 17 1F ))... ..........

SCR:

00000000  02 A5 80 00 01 F0 01 01 ........



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Security        :2

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDSC Card!

あり･･･普通だ･･･ま、まぁ工業用ですからピーキーな性能よりも
安定性とかｿｯﾁのほうがすごいのでしょうね(脂汗)

●名も無き16GB MicroSDHC

1078円でたたき売りされていたMicroSDHCです。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr  3 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 18257 kB/sec.

>ds 0

rc=0

Drive size: 31275008 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5B 59 00 00 77 4D 7F 80 0A 40 00 9D @..2[Y..wM...@..

CID:

00000000  28 42 45 48 30 33 30 39 10 00 00 19 C9 00 B1 ED (BEH0309........



Parsing SD CID Register

Manufacturer ID    :0x28

OEM/Application ID :BE

Product Name       :H0309

Product HwRev      :1

Product SwRev      :0

Serial Number      :0x000019C9

DateCode.Month     :1

DateCode.Year      :2011



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 04 00 00 00 04 04 90 00 08 05 00 00 ................

00000010  00 00 00 00 00 00 00 00 00 53 4D 49 00 00 00 00 .........SMI....

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 80 00 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDHC Card!

･･･たたき売りのくせにやるじゃない(ﾆﾔ

●名も無き256MBMicroSD

こちらは10年位前に6800円で購入した古の256MBのカードです。
まだまだ現役バリバリなのですよぅ

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr  3 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 12321 kB/sec.

>ds 0

rc=0

Drive size: 499712 sectors

Erase block size: 128 sectors

Default r/w block size: 512 bytes

Card type: SDv1

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  00 5E 00 32 57 59 83 CF ED B6 FF 87 96 40 00 D3 .^.2WY.......@..

CID:

00000000  4B 46 4D 53 44 20 20 20 10 03 00 25 63 00 69 7D KFMSD   ...%c.i}



Parsing SD CID Register

Manufacturer ID    :0x4B

OEM/Application ID :FM

Product Name       :SD   

Product HwRev      :1

Product SwRev      :0

Serial Number      :0x03002563

DateCode.Month     :9

DateCode.Year      :2006



OCR:

00000000  80 FF 80 00 ....

SD Status:

00000000  80 00 00 00 00 00 00 28 00 00 00 00 00 00 00 00 .......(........

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  01 25 00 00 00 00 00 00 .%......



Parsing SCR

SD Spec Version    :1

SD Spec Version 3  :0

SD Spec Version 4  :0

SD Security        :2

SD Bus Width       :5



SD_Spec V1.10!

Detected as SDSC Card!

大昔のカードなのでSDのバージョンは1.10です。
このカードはBIOSの更新用ブートメモリとしてUSBカードリーダと
組み合わせて今でも使用しております。

●RiDATA 256MB MiniSD

そして更に昔の11年前にMP3プレーヤー用に購入したMiniSDのカードです！
確か9870円くらいで買ったと思いました。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr  3 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 7666 kB/sec.

>ds 0

rc=0

Drive size: 492544 sectors

Erase block size: 128 sectors

Default r/w block size: 512 bytes

Card type: SDv1

SpeedMode: NomalSpeedMode(25.72MHz)

DataBusWidth: 4bit



CSD:

00000000  00 7F 00 32 13 59 81 E0 EE BB 3F FF 16 40 00 E9 ...2.Y....?..@..

CID:

00000000  04 00 00 53 44 00 00 2A 10 00 00 03 3A 00 48 97 ...SD..*....:.H.



Parsing SD CID Register

Manufacturer ID    :0x4

OEM/Application ID :<0><0>

Product Name       :SD<0><0>*

Product HwRev      :1

Product SwRev      :0

Serial Number      :0x0000033A

DateCode.Month     :8

DateCode.Year      :2004



OCR:

00000000  80 FF 80 00 ....

SD Status:

00000000  80 00 00 00 00 00 00 14 00 00 00 00 00 00 00 00 ................

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  00 A5 00 00 00 00 00 00 ........



Parsing SCR

SD Spec Version    :0

SD Spec Version 3  :0

SD Spec Version 4  :0

SD Security        :2

SD Bus Width       :5



SD_Spec V1.0x!

Detected as SDSC Card!

なんとSDのバージョンはHighSpeedModeにすら対応していないV1.0です･･･
私が持つ最古のSDカードです。

●ATP ProMAX MiniSD 1GB x150

ねむいさんイチオシのメーカーATP製のカードです。
こちらは箱にSLCと明記されておりました。15000円くらいでヨドバシで
買った記憶があります。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr  3 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 19499 kB/sec.

>ds 0

rc=0

Drive size: 1999872 sectors

Erase block size: 128 sectors

Default r/w block size: 512 bytes

Card type: SDv1

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  00 5E 00 32 5F 59 83 D0 6D B7 FF 9F 96 40 00 8F .^.2_Y..m....@..

CID:

00000000  09 41 50 41 46 4D 44 50 10 45 30 00 C2 00 63 DD .APAFMDP.E0...c.



Parsing SD CID Register

Manufacturer ID    :0x9

OEM/Application ID :AP

Product Name       :AFMDP

Product HwRev      :1

Product SwRev      :0

Serial Number      :0x453000C2

DateCode.Month     :3

DateCode.Year      :2006



OCR:

00000000  80 FF 80 00 ....

SD Status:

00000000  80 00 00 00 00 00 00 38 00 00 00 00 00 00 00 00 .......8........

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  01 25 00 00 00 00 00 00 .%......



Parsing SCR

SD Spec Version    :1

SD Spec Version 3  :0

SD Spec Version 4  :0

SD Security        :2

SD Bus Width       :5



SD_Spec V1.10!

Detected as SDSC Card!

やりますね～！

●ATP MicroSDHC4GB MLC (AF4GUD-ATP023)

こちらはSTM32F4のいつもので使用しているおなじみのATPのMicroSDHCです。
一般用なのでMLCです。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Mar 22 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 21173 kB/sec.

>ds 0

rc=0

Drive size: 7861248 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5F 59 00 00 1D FC 7F 80 0A 40 00 97 @..2_Y.......@..

CID:

00000000  09 41 50 41 46 20 55 44 10 26 3B 15 32 00 83 A5 .APAF UD.&;.2...



Parsing SD CID Register

Manufacturer ID    :0x9

OEM/Application ID :AP

Product Name       :AF UD

Product HwRev      :1

Product SwRev      :0

Serial Number      :0x263B1532

DateCode.Month     :3

DateCode.Year      :2008



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 02 00 00 00 03 03 90 00 08 05 00 00 ................

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 00 00 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :0

SD Spec Version 4  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V2.00!

Detected as SDHC Card!

速度も文句なし！

●ATP MicroSDHC4GB SLC (AF4GUDI-5ABXX)

そして同じATPの工業用のMicroSDHCです！！！！！
もちろんSLCなのですよぅ！実力やいかに！？

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Mar 22 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 16330 kB/sec.

>ds 0

rc=0

Drive size: 7892992 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5B 59 00 00 1E 1B 7F 80 0A 40 00 B1 @..2[Y.......@..

CID:

00000000  09 41 50 41 46 20 55 44 10 12 60 75 7A 00 F2 39 .APAF UD..`uz..9



Parsing SD CID Register

Manufacturer ID    :0x9

OEM/Application ID :AP

Product Name       :AF UD

Product HwRev      :1

Product SwRev      :0

Serial Number      :0x1260757A

DateCode.Month     :2

DateCode.Year      :2015



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 02 00 00 00 03 03 90 00 08 05 00 00 ................

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 00 00 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :0

SD Spec Version 4  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V2.00!

Detected as SDHC Card!

ぁ･･･あれ･･･？ま、まぁ工業用ですからピーキーな
性能よりも安定性を強化しているのでしょう(脂汗)
大事な事なので二度言いました。

●Sandisk Ultra8GB MicroSDHC

トリはSanDiskのSDカードたちです！
偽者が乱舞するSandisk製ですがねむいさんいちおうちゃんとしたお店で
買っているので偽者には引っかかっておりません･･･はず･･･

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr  3 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 16421 kB/sec.

>ds 0

rc=0

Drive size: 15523840 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5B 59 00 00 3B 37 7F 80 0A 40 40 AF @..2[Y..;7...@@.

CID:

00000000  03 53 44 53 55 30 38 47 80 02 37 95 01 00 C6 87 .SDSU08G..7.....



Parsing SD CID Register

Manufacturer ID    :0x3

OEM/Application ID :SD

Product Name       :SU08G

Product HwRev      :8

Product SwRev      :0

Serial Number      :0x02379501

DateCode.Month     :6

DateCode.Year      :2012



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 03 00 00 00 04 00 90 00 14 05 1A 00 ................

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 80 01 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDHC Card!

ふつー･･･

●Sandisk UltraⅡ 8GB SDHC

このカードはお尻にUSBの端子が付いていてUSBメモリとしても機能します。

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Apr  3 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 14268 kB/sec.

>ds 0

rc=0

Drive size: 15954944 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5B 59 00 00 3C DC 7F 80 0A 40 40 C5 @..2[Y..<....@@.

CID:

00000000  03 53 44 53 44 30 38 47 80 01 9C 01 36 00 84 65 .SDSD08G....6..e



Parsing SD CID Register

Manufacturer ID    :0x3

OEM/Application ID :SD

Product Name       :SD08G

Product HwRev      :8

Product SwRev      :0

Serial Number      :0x019C0136

DateCode.Month     :4

DateCode.Year      :2008



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 03 00 00 00 02 02 90 00 0B 05 00 00 ................

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 00 00 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :0

SD Spec Version 4  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V2.00!

Detected as SDHC Card!

機能盛り込みすぎてちょっと速度が遅いですがしかたは無いです。

●Sandisk ExtremePRO SDXC64GB(FAT32フォーマット)

そして！現在TG-3用の記憶媒体としてバリバリに使っていますExtremePROの
64GBのカードです！！！

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Mar 25 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 16448 kB/sec.

>ds 0

rc=0

Drive size: 124735488 sectors

Erase block size: 32768 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5B 59 00 01 DB D3 7F 80 0A 40 40 DF @..2[Y.......@@.

CID:

00000000  03 53 44 53 50 36 34 47 80 F2 D6 14 07 01 01 D5 .SDSP64G........



Parsing SD CID Register

Manufacturer ID    :0x3

OEM/Application ID :SD

Product Name       :SP64G

Product HwRev      :8

Product SwRev      :0

Serial Number      :0xF2D61407

DateCode.Month     :1

DateCode.Year      :2016



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 08 00 00 00 04 00 C0 00 0F 05 3A 00 ..............:.

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 45 84 03 00 00 00 00 .E......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :1

SD Security        :4

SD Bus Width       :5



SD_Spec V4.xx!

Detected as SDXC Card!

ありゃりゃ･･･
ま･･まぁ･･･FAT32で無理糞フォーマットしてますしそのせいでしょう(脂汗)
カードのﾓﾉとしてはSDのバージョンも4の最新のやつです。
今回の評価でSDバージョンが4の奴はこれと並行輸入版EXCERIAだけでした。
どうでもいいですけどeraseblocksizeが32768セクタもあります。

●I/ODataのClass4 SDHC4GB

ねむいさんのおとうちゃんから｢お前が山に行った時の写真分けてくれ｣と
頼まれ手渡されたどっかの家電量販店で買ってきたかのようなデータ保存用の
やっすいカードです。どうせゴミみたいな性能だろうから哂ってやるつもりで
半ば冷やかしにベンチとってみたのですが･･･

FatFs module test terminal for STM32F427IIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Mar 25 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 19063 kB/sec.

>ds 0

rc=0

Drive size: 7878656 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

SpeedMode: HighSpeedMode(51.43MHz)

DataBusWidth: 4bit



CSD:

00000000  40 0E 00 32 5B 59 00 00 1E 0D 7F 80 0A 40 00 A5 @..2[Y.......@..

CID:

00000000  1D 41 44 53 44 20 20 20 10 A0 90 08 0A 00 02 E3 .ADSD   ........



Parsing SD CID Register

Manufacturer ID    :0x1D

OEM/Application ID :AD

Product Name       :SD   

Product HwRev      :1

Product SwRev      :0

Serial Number      :0xA090080A

DateCode.Month     :2

DateCode.Year      :2000



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 02 00 00 00 02 02 90 00 08 11 00 00 ................

00000010  00 00 00 00 00 00 00 00 00 53 4D 49 00 00 00 00 .........SMI....

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 51 00 00 00 00 32 00 00 00 00 00 00 00 ...Q....2.......

SCR:

00000000  02 35 80 00 00 00 00 00 .5......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Security        :3

SD Bus Width       :5



SD_Spec V3.0x!

Detected as SDHC Card!

>132949600 bytes read with 19063 kB/sec.
なん･･･だと･･･！？

･･･
こ、こう言うベンチマークの結果は特に気にせず皆様はそれぞれが納得し信頼できる
メーカのSDカードを選んで使用していただければよいと思いますよ(脂汗)

STM32F7を使ってみる11 -最新のeMMCを動かす-

前回までは古き世代の遺産であるマルチメディアカードをSTM32F7で再び動作せしめる
までになりましたが、今回は新しい世代へと進化したeMMCモジュールの動作に
ついに、ついに挑みます！

eMMCは最早カードの形状ではなく、ごく一般的なICの形となっていますがそれが
故に使い慣れたSDカードコネクタとかで使うには少々骨が折れます。
市販のギャングプログラマ用のSDカード変換付きソケットは100$以上するのであんまし
手を出したくはないです…
簡単かつ確実に使う良い方法ないかといろいろ探ってみるとODROIDと言うLinux系の
ARMボード向けのオプションパーツとしてeMMC実装済みのMicroSDの変換基板が販売
されているのを発見しました！

SouthKorea製なのがほんの少し心配でしたが値段も送料込みで38USD
(2016年3月下旬時点)だったので早速注文してみました！！

で、発注後4日くらいで親父の家に届きました。一週間以上かかるかと思いましたが
予想以上に早かったです。Androidを意識した質素の箱の作りで"Do it yourself"
なるコメントがあります。

一応ぷちぷちにくるまれていましたがこの色って静電対策してないやｔ

これって静電対策してないやｔ
まぁでもうごけばいいのですよぅ動けば！！

ボードとしてはｺﾃｺﾃの南朝鮮製ですが実装されているeMMCは東芝製で容量8GB,
そして規格はeMMCv5の最新版です！！！

一応コリアンボードのmicroSDへの変換パタンもやっけつではなく信号のIntegrity
を考慮した配線をしてくれているようです。

eMMCは古いタイプのカードリーダーでは認識すらしない場合があります。
ねむいさんが昨年購入したUSB3.0のTranscend製のカードリーダーでは無事に
認識できました♥
もともとこのeMMCはODROIDのオプションパーツとして販売されているので、
こんな風に最初から何らかのOSが仕込んであります。

ねむいさんはそんなもん関係なくeMMCを使用すること自体が目的なので速攻
FAT32でフォーマットして更地にてやりました！！！

前回の最後でちょろっと漏らしているように実は公開したF7のサンプルでは
既にeMMC(とMMCのブロックアドレッシング)に対応しております。

ビルド時間は結構長いので暇つぶしがてらF7からeMMCのルーチンを移植中の
STM32F4の板に差して反応見てみるかと思ったらなんと普通に認識してしまった…。
拍子抜けするくらいあっさり読めちゃって感動もへったくれもない…
ぇっ！？黒澤ダイヤちゃんのお口がｲｹﾅｲことになってるって！？何のことやらﾊﾊ
虹裏メイドねむいさんは｢ラブライブ!サンシャイン!!｣を応援します。

さてビルドが終わってF7のプログラムの書き換えも終わったのでF4板から外すか
…と思ったら…

あ…あれ…？？？

･･･
案の定HELL朝鮮製ボードに罠がありました…微妙にサイズが大きいようで刺さる
には刺さるんですけど安易に抜けません(意味深)。
無理やり引き抜くと基板で擦れてMicroSDコネクタを壊してしまいます…

てわけで削ります。
いきなりF7-Discoveryで試さなくてよかった…

ｺﾞﾘｺﾞﾘ削ってこんな感じに…

うまいこと削れたのでF7-Discoveryのコネクタにスムーズに差さります。

F7でも無事に認識して画像や動画データも自由自在に読み出しできます♥

このeMMCは8GBの容量でSDHCと同じくブロックアドレッシングになります。
私の移植例ではMMCv4以降に新設されたブートパーティション等にアクセス
するための特別なコマンド群は使用しておらず、SDHC/SDXCと同じ感覚で読み
書きします。腕に自信がある人、私のコードを参考に拡張してください･･･(懇願)

そしていつも通りカード(？)の情報を読み出してみました。

>ds 0

rc=0

Drive size: 15269888 sectors

Erase block size: 1024 sectors

Default r/w block size: 512 bytes

Card type: MMC(Block)

CSD:

00000000  D0 5E 00 32 0F 59 03 FF FF FF FF EF 92 40 00 D3 .^.2.Y.......@..

CID:

00000000  11 01 00 30 30 38 47 45 30 00 5A DD 41 40 B2 0D ...008GE0.Z.A@..



Parsing MMC CID Register

Manufacturer ID    :0x11

OEM/Application ID :<0>

Product Name       :008GE0

Product Rev        :0.0

Serial Number      :0x5ADD4140

DateCode.Month     :11

DateCode.Year      :1999



Detected as MMCv5.0x Device!

OCR:

00000000  C0 FF 80 80 ....

前回述べたとおりMMCv4.xx以降はExtCSDレジスタを読み出すのは重要です。
MMCv4以降のバージョン判定はExtCSDREVフィールドを参照し解釈する必要
性があります。ちなみにこの東芝のeMMCはv5とのことですがですが読み出すと
ExtCSDREVは”7”となりちゃんとv5のデバイスであることが分かります。
ちなみにdatecodeが1999とあるのはCIDレジスタの年数を示すフィールドが4bit分
しかないので2012年を境に年数が一巡してしまっているからです。最新のMMCAの
データシートではExtCSDREVから2012年以降を判別せよというようになっていますので
~~次回リリースでこちらも修正します。~~差し替えました。
一方、SDカードでは年数を示すフィールドは6bit分あるのであと50年くらい安泰です。

FatFs module test terminal for STM32F746NGH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Mar 31 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 22000 kB/sec.

>

シーケンシャルライトも見てみました。F7のサンプルではSDIO_CLKはMAX48MHz
かつ4bitモードの設定がeMMCで可能ですがご覧のとおり理論値に近い読み出し
速度が出ました。やるじゃない！

FatFs module test terminal for STM32F746NGH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Mar 31 2016

>fg piano

rc=0 FR_OK

>fo 1 ftbt.mp3

rc=0 FR_OK

>fr 132949600

132949600 bytes read with 20753 kB/sec.

>

因みに前回紹介したMMCPLusも結構速いです。

と言うわけでユーザー領域のみですがeMMCでもSDHC/SDXCと同じく読み書きする
ことが出来るようになりました！今秋くらいに市場に出回るであろうSTM32F777等の
最強に強まったF7シリーズではSDMMCが二つに増えるので基板付け置きのeMMC
(とかMCP)が今後は発言力を増してくると思います！！

今回の成果はSTM32F4系やSTM32F1系、そしてLPC4088のMCIにも移植しています
のでどんどん試して下さい！ついでにバグもこっそり教えてもらえると助かります☆

STM32F7を使ってみる10 -いにしえのマルチメディアカードを動かす(うごかす編)-

ぇえええぇぇえええぇええ(どん引き)
↑イレギュラー化した部下に突如愛の告白されるシグマﾀｲﾁｮｳ風に

いったいいつからIF誌はねむいさんのお株を奪うようなシモネタを炸裂させる
ようになったのでしょうか…???今回はちょっと笑えたので許しますが。
ああプロテインってそういう･･･

そんなどうでもいいことは置いといてさっさと本題に掛かります！！！！！前回は
microSD->SDの変換アダプタ作っただけで力尽きましたが今回は実際に動かします。

先ずはebayで購入した2GBのMMCPlusカードです！

MMCPlusの規格なので8bitバスで転送もできます…がソケットの互換性を考えると、
4bitバスモードで動かした方が無難でしょう。
因みに妙に汚いように見えますがUSEDでした。MMC自体最早新規生産なんかしてない
ので致し方なしです。カードとして正しく動作すればOKです。

で、その前に問題のソフトウエアの方ですが…こちらでも紛糾してるように
STM32CubeHALライブラリにMMCのサポートは全く有りません。それどころかなんと
過去のSPLには対応していたSDv1.xx系カードのサポートすらもHALライブラリでは
おもいくそぶっちされておりました！！！F**K!!

とりあえずSDv1.xx系のサポートは復活させて動作確認したのですがMMCネイティブ
モードにおけるイニシャライズはどうしたらいいのか全く分からなかったので
暫くの間ネットの海にダイブして情報を沢山漁ってきました。

幸いにもJEDECのMMCの規格は2016年現在は一般人でも公式のJEDECのサイトから
容易に入手することが出来るようにになっていてさらに中華圏のサイトでは
動作するかどうかは不明ですがSTM32向けのeMMCドライバも入手出来たので
それを参考にMMC向けのドライバをF7のHALライブラリ向けに組み込みました。

当然最初は思った通りに動かなかったのですがSTM32のSDIO/SDMMCのハード
ウエア自身にかなりクセがあることが分かり、クセを理解して全種類のカードを
イニシャライズせしめるよう克服していきました。
以下にMMCPlus/MMCv3なカードを使い認識していく過程をデバッガで実動作を
追いながら解説していきます。

STM32のSDカードドライバは基本的にSDv2->SDv1->MMCの順に認識しようとして
いきます。これは現在のSDカードの規格においても推奨される初期化手順と
されています。カードをリセットするCMD0を除くと最初に放たれるのはCMD8です。

MMCとSDv1系ではSDHC用初期化CMD8:SEND_IF_CONDはタイムアウトエラーとなります。
過去のSTM32のSPLに収録されているsdカードのサンプルではその状態から
なぜかCMD55を単品で投げてから改めてCMD55+ACMD41を投げていました。

CMD8が撥ねられた後いきなりCMD55+ACMD41を撃つとSDIOモジュールがエラーで
コケる対策にCMD55を空撃ちしていた感じです(SPLではあったけどHALライブラリ
はそれすらない!)。これはCMD55を受け付けるSDカード系は問題ないのですが
MMCv3以前だとCMD8が撥ねられた後のCMD55の空撃ちがILLEGAL_COMMANDとなり
またまた撥ねられてしまい、先に進めません(※MMCv4以降はこのCMD55が通ります)。

と言うわけでCMD55の代わりにCMD0でカードをリセット状態にしてから改めて
CMD55+ACMD41を送るようにするとうまく先に進めました！勿論SDv1系でも
CMD55の空撃ちではなくCMD0で問題有りませんでした。

MMCではCMD55+ACMD41は当たり前ですがタイムアウトエラーとなります。

先ほどと同じくCMD0を送りMMCをリセットしますが、eMMC対応を考えて引数を
0xF0F0F0F0にしたCMD0の後0x0000000な引数のCMD0を送るようにしてみました。

ここまで来てようやく本来のMMCの初期化ができます。
CMD1を送ってSDカードの｢ACMD41｣と同じように初期化します。
が、ブロックアドレッシング必須のSDHCと同じくCCSビット(0x40000000)を
ORして引数に渡さないとブロックアドレッシングを必要とするMMCv4.x以降の
規格では初期化が完了できませんのでしっかりとおっ立てた状態で引数として
わたしましょう。ちなみにv3以前のカードにおいてはCCSビットが立っていても
影響は受けずスルーされて初期化がそのまま通るので問題ないです。

上手く初期化が出来たらOCRレジスタの0x80FF8080が読みだされます。
MMCPlusでDualVoltage対応なので上記の値となっています。
因みにv3以前のカードでは0x80FF8000,ブロックアドレッシングな
v4系のデバイスでは0xC0FF8080が帰ってきます。
ここまで認識が通ったらだいぶ気が楽になります。

所でMMCv4.x系のカードでは新たに追加されたExtCSDレジスタから512バイト分の
追加情報を取得可能です。実はこのExtCSDは4GB以上のeMMCの総容量計算では
必須のビットが存在しています。

212～215バイト目がそのSEC_COUNTフィールドなのですがここに総セクタ数が
記録されていて512を掛けると総バイト数が分かる仕組みになっています。
この2GBのMMCplusではSEC_COUNTフィールドからの算出方法でもCSDレジスタ
から算出する従来の容量計算方法(計算式はSDv1系と全く同じ)でも両方とも
可能です。

初期化を越えたらクロックを転送用の高速クロックに上げていきますが…
MMCv4系では最大52MHz,8bitバスモードまで動かせられます。当ぶろぐでは
4bitバスモードまでとします。MMC専用の呪文を投げる以外はSDカードの
4bit化やHighSpeedMode化と流れは同じです。そして…

無事ファイラーからディレクトリが読みだされました♥

サイズのでかい動画でもカクカクせずスムーズに動きます☆
(後でかなり早いカードなことが分かった)

お次はさらに古いMMCv3世代のカードです。容量はたったの128MB!
そしてもちろん中古品。

初期化を越えたらクロックを転送用の高速クロックに上げていきますが…
10年以上前のものですがちゃんと現在のPCカードリーダーからも認識できます。

MMCv3系のカードなので数が7ピンしかありません。MMCネイティブモードでも
当然バス数が1bitです。早速こちらも動きを追ってみましょう！

CMD1の初期化を終えるとOCRレジスタの0x80FF8000が読みだされました。

初期化を越えたらクロックを転送用の高速クロックに上げていきますが…
MMCv3系はクロック上限値が20MHzできっちり線引きされていてそれ以上はまず
動作しないので20MHz以下にクロックを落とす工夫が必要です。もちろんデータ
バス幅は1ビットのままです。

さすがに遅いですけど無事認識です♥

上記2つのカードの各レジスタをSDカードと同じようにパースしてみました。
CIDレジスタの扱いがSDカードと微妙に違うので注意です。
そんでもってMMCv4以上の細かいバージョン識別はExtCSDの"ExtCSDVER"
フィールドを読みだして解釈する必要があります。
eMMCの使用をにらんでこちらも正しく解釈できるようにしておきました。
●2GB MMCPlus

>ds 0

rc=0

Drive size: 3939328 sectors

Erase block size: 256 sectors

Default r/w block size: 1024 bytes

Card type: MMC(Byte)



CSD:

00000000  90 2F 00 2A 1F 5A 83 C1 B6 DB 9F FF 96 80 00 3F ./.*.Z.........?

CID:

00000000  37 FF FF 4D 4D 43 30 32 47 10 F3 02 67 50 2C F5 7..MMC02G...gP,.



Parsing MMC CID Register

Manufacturer ID    :0x37

OEM/Application ID :

Product Name       :MMC02G

Product Rev        :1.0

Serial Number      :0xF3026750

DateCode.Month     :2

DateCode.Year      :2009



Detected as MMCv4.0 Device!

OCR:

00000000  80 FF 80 80 ....

●128MB MMCv3

>ds 0

rc=0

Drive size: 250880 sectors

Erase block size: 32 sectors

Default r/w block size: 512 bytes

Card type: MMC(Byte)

CSD:

00000000  8C 26 01 2A 0F 59 81 E9 F6 DA 81 E3 9E 40 00 7D .&.*.Y.......@.}

CID:

00000000  11 00 00 30 31 32 38 4D 32 0A 05 80 FE CB 28 7D ...0128M2.....(}



Parsing MMC CID Register

Manufacturer ID    :0x11

OEM/Application ID :<0><0>

Product Name       :0128M2

Product Rev        :0.10

Serial Number      :0x0580FECB

DateCode.Month     :2

DateCode.Year      :2005



Detected as MMCv3.xx Device!

OCR:

00000000  80 FF 80 00 ....

>

いろいろありましたがMMCの動かし方も上手くモノにすることができるように
なりました！次はいよいよMMCから進化したeMMCの動作に挑みます！！

今回の更新はすでにおきぱに上げてあります。eMMCのSD変換アダプタを持ってるひとは
いいことあるかも･･･！？

●おまけ
前回言及したCubeF7のバグですが、｢とりあえずuint64_tでキャストしときゃ
いいだろ｣が祟って出てしまったカルマなのですが実際どうなるかをSTM32上で
確かめて見ました。

先ず使用する変数/定数は以下とします。
#define SECTOR_SIZE 512
uint64_t unk0;
uint32_t tnk = 8388612; /*512を掛けるとオーバーフロー*/

まずキャスト無しの場合…
unk0 = tnk * SECTOR_SIZE;
この場合は、普通にuint32_tの演算として扱われオーバーフローしたぶんは
そのまま頭が切られます。よって0x100000800ではなく0x800がunk0に代入
されました。

次に括弧でくくってuint64_tでキャストしてみます。今回フォーラムで指摘
されてたのがこのバグです。
unk0 = (uint64_t)(tnk * SECTOR_SIZE);
これもunk0に0x800が代入されてしまいました。*の演算を括弧でくくってしま
ったためにやっぱり0x800になっちゃいました。

正しいキャストの仕方がこちらです。
unk0 = (uint64_t)tnk * SECTOR_SIZE;
uint32_t変数のtnkをuint64_tにキャストしたうえでSECTOR_SIZEを掛けることで
0x100000800がunk0に正しく代入されます。

これ結構引っ掛かりやすいポイントなので私も気を付けるようにします。
フォーラムで指摘されるまで私も気づいて無くて同じミスしてましたがorz

因みにMMCv4.x系のSEC_COUNTの計算で
(代入先が64bit変数の場合)

(uint64_t)((uint64_t)(ext_csd.EXT_CSD.SEC_COUNT[3] << 24 | ¥

                       ext_csd.EXT_CSD.SEC_COUNT[2] << 16 | ¥

                       ext_csd.EXT_CSD.SEC_COUNT[1] << 8  | ¥

                       ext_csd.EXT_CSD.SEC_COUNT[0]));

もしくは

(uint64_t)((ext_csd.EXT_CSD.SEC_COUNT[3] << 24 |  ¥

                       ext_csd.EXT_CSD.SEC_COUNT[2] << 16 | ¥

                       ext_csd.EXT_CSD.SEC_COUNT[1] << 8  | ¥

                       ext_csd.EXT_CSD.SEC_COUNT[0]));

もしくは

((ext_csd.EXT_CSD.SEC_COUNT[3] << 24 | ¥

                       ext_csd.EXT_CSD.SEC_COUNT[2] << 16 | ¥

                       ext_csd.EXT_CSD.SEC_COUNT[1] << 8  | ¥

                       ext_csd.EXT_CSD.SEC_COUNT[0]));

と誤った式にしてしまうとext_csd.EXT_CSD.SEC_COUNT[3]の最上位ビットに1が立つ
ような値がSDカード/eMMCから得られた場合、uint64だろうがint64だろうが負の値と
みなされた状態で整数拡張されて上位32bitが0xFFFFFFFFでパディングされた状態で
64bit変数にキャストされてしまい、結果として意図しない値がストアされてしまいます。

ですので、

(uint64_t)((uint32_t)(ext_csd.EXT_CSD.SEC_COUNT[3] << 24 | ?

                       ext_csd.EXT_CSD.SEC_COUNT[2] << 16 | ¥

                       ext_csd.EXT_CSD.SEC_COUNT[1] << 8  | ¥

                       ext_csd.EXT_CSD.SEC_COUNT[0]));

もしくは

(uint32_t)((ext_csd.EXT_CSD.SEC_COUNT[3] << 24 | ?

                       ext_csd.EXT_CSD.SEC_COUNT[2] << 16 | ¥

                       ext_csd.EXT_CSD.SEC_COUNT[1] << 8  | ¥

                       ext_csd.EXT_CSD.SEC_COUNT[0]));

として頭をきっちり削っておけば問題ありません。

ってわけで型の合わない変数に何も考えずキャストとか代入したらこうなります
なったorz

STM32F7を使ってみる9 -いにしえのマルチメディアカードを動かす(準備編)-

またバグ
…
ｹﾞﾌﾝﾌｹﾞﾌﾌﾝ…失礼
例の副業先のトラブルは技術的なものから対人関係というさらに深刻な問題に
シフトしてしまい現在も継続中ですが意地でもこのぶろぐ更新してやります！！

さて、記憶メディアとして現在確固たる地位を築いたSDカードが世に出る少し
前にマルチメディアカード(MMC)という物が存在しておりました。可搬性に
優れるという最大の特徴を持っておりましたが後出してきたSDカードにその
役目を委ねて現在はe-MMC(エンベデッドMMC)と言う形で活躍しております。

今回はeMMCの使用を見据えて先ずは古のMMCを理解しSDカードと同様に動作
せしめる事を目的とします。

SDカードはMMCを基に物理的/電気的に互換性を持たせて作られたため、現行の
フルサイズのSDカードスロットはMMCも勿論使用可能です！

…
しかし軽薄短小を求めた今はmicroSDカードスロットが当たり前になりでっかい
MMCなんて挿せない！！

と言うわけでマイクロSD->SDカード変換アダプタを購入することにしました。
因みにこれ、登場した当初、電子工作でSDカードを利用した方々から総突込み
のキワモノ扱いされていたブツです。理由は言わずもがな。

なんか箱からして怪しいです。ハングルが書いてあるのに電話番号が大阪っぽい
んですけぉ･･･

中身はこんな感じです。マイクロSDカードスロットに差してなんと65cmも延長で
きます★車のダッシュボードの手の届く場所につけられます★…ですって！

なんというか｢信号の反射！？波形の品質！？そんなものは見えやしねー！！
俺の眼に映るものはただひとつ！(※認識エラー※)｣って感じですが日本国内で
販売してるサイトとかではひっそりとSDカード(notSDHC・SDXC)で動作させて
くださいとか気弱なこと書いてありましたそりゃそうですよねこんなに引き延
ばして動くわけが…

動…いた…！？ぇええええぇえええ･･･

sandiskのextremeマイクロSDHC8GBをわざわざSDカード変換にかまして不利な
条件で動かしてみましたが動画もこけずに再生できました…！！
すごいぞSandiskの高いやつ！

でも各信号波形が汚いダメダメな安っすいカードとかだと何やってもダメです…。
SuperTalentのSDカードがとにかくﾀﾞﾒﾀﾞﾒ

と、言うわけで引き延ばす線が長すぎて使い勝手も安定性も悪いので長さを
詰める事にしました。

SDカードスロット側のカバーを開けてみました。
チップタンタルと抵抗が乗っかっています。パタンを追って調べてみると抵抗は
SDカードのCLKラインに330ohmでVCCにプルアップしておりそしてチップタンタル
は+側がSDスロットの外部に繋がっているだけで他はどこにもつながっていない
宙ぶらりん状態でした…ﾅﾝﾀﾞｺﾚ

CLKラインを330ohmの抵抗値でVCCに無理糞繋げてもドライブ能力そこまでない
でしょうからGNDレベル引き切れなくなって益々安定性がわるくなるとおもうん
ですけぉ…ググってもそういう終端例はなかったです。

と言うわけで長さ詰めたついでに330ohmとチップタンタルは取っ払い、SDカード
スロット外郭のシールドはGNDに落としました。

長さ詰めてちょっとは認識するカードが出てきましたが認識しないへそ曲がりな
SDカードがまだ沢山いましたorz
計算上15cm以上引き延ばしてることになるので当たり前ですが…

今度は銅箔テープでフルシールド作戦だ！！！！！

まだあかん…

今度はCLKラインに直列にフェライトビードを投入しました！！
計算上配線路のど真ん中に置くことになり最悪逆効果になる可能性も
ありますが…！？
(※普通は直列終端はMCUのSDIO-CLK端子の最近傍に置き最大の効果を発揮させます)

最後まで粘っていた奴もようやく読めた…(もちろんHighSpeedモードです)

最終的にこんな外形になってしまいました…

でも貴重なマイクロSDスロット->SDカードスロット変換なので大事に大事に
使っていこうと思います。こういうの一個持ってると何かと便利ですものね～

と言うわけで変換アダプタハーネスの改造だけでもう力尽きたので実際に
MMCを動かすのは次回にします…。

STM32F7を使ってみる8 -CubeF7のHALライブラリにバグ-

クリスマス前に副業先で超F**Kな出来事が立て続けに起こったおかげで土日も
それの対応に追われホント超F**Kな気分でしたがやっと自体が収まりつつある
のでぶろぐ更新してみました。あと本業(虹裏メイド)のほうもステキなクリプレ
完成しましたからとしあき君たち替えのぱんつ用意して待ってなさい！！
以上業務連絡終り。

●STM32F7Cubeが更新
少し前にCubeF7ライブラリがV1.3.0に更新しておりました。前回指摘されていたHAL
ライブラリ中のSDカードの容量を正しく取得できないバグは直っておりました。
容量計算のための変数をuint32_tで取っていたので32GByte以上の容量のカードだと
値がおかしくなっちゃうという昨今の大容量化では良くある光景です。

どうやらCubeF7に収録されているデモとかでは影響が無かった為かユーザーに
指摘されるまで気付かなかったようです。Cube系ライブラリに移行してから
ずっとこんな調子ですがねむいさんも新たなバグを見つけてしまいました。

●おっと新バグ発見伝
今回の更新にあたり、fatfsのsdmmcドライバで今まで適当に作りこんでいた
SDカードの内部レジスタを読み出す部分のルーチンを見直して正しく取得できる
ようにし、更にCIDレジスタをパースする機能を追加してみたのですが何でか
いくつかの値がちゃんと読み出せず、ちょっと困っていました。
デバッガで追って調べるとなんとHALライブラリ側にバグがありました。

HAL_SD_GetCardStatus()という関数の冒頭でステータスレジスタを取得する
内部変数のバッファをuint32_tで宣言しているのですが、取得後pCardStatusの
各構造体要素に代入する際にuint8_tの配列と勘違いして処理して代入してました。

↑HAL_SD_SendSDStatus()の2つ目の引数がuint32_t*なのでそれに合わせて
　しまった模様

実は過去のSTM32F4などの標準ペリフェラルライブラリ(SPL)では
HAL_SD_GetCardStatus()に相当する関数内で最初からuint8_tとして宣言して
いたのでこの問題は出なかったのですが･･･完全にエンバグですね･･･
(SPLのほうも微妙にバグってますが)というわけで対策はSPLの真似して配列を
uint8_tで64バイト分宣言すれば終りです。

このバグはSDカード使う人は結構踏んでると思うのでSTマイクロの公式のフォーラム
にも報告しておきました。bugって文字が乱舞するようになったフォーラム
ですが新たなbugがまたひとつ。

そんなわけで上記のバグを潰してUARTから操作するChaN氏のFatFsのデモでds
コマンドを打った時のSDカードの各レジスタのダンプに加えてCIDレジスタを
パースする機能を無事追加できました。SandiskのExtremePRO microSDHC 8GBを読み出した
際の表示は↓こんな感じになりました。
してます★



>ds 0

rc=0

Drive size: 15523840 sectors

Erase block size: 8192 sectors

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 5B 59 00 00 3B 37 7F 80 0A 40 40 AF @..2[Y..;7...@@.

CID:

00000000  03 53 44 53 55 30 38 47 80 1B B8 C2 F6 00 C8 2F .SDSU08G......./



Parsing CID Register

Manufacturer ID    :0x3

OEM/Application ID :SD

Product Name       :SU08G

Product HwRev      :8

Product SwRev      :0

Serial Number      :0x1BB8C2F6

DateCode.Month     :8

DateCode.Year      :2012



OCR:

00000000  C0 FF 80 00 ....

SD Status:

00000000  80 00 00 00 03 00 00 00 04 00 90 00 14 05 1A 00 ................

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

SCR:

00000000  02 35 80 03 00 00 00 00 .5......



Parsing SCR Register

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :0

SD Security        :3

SD Bus Width       :5

おきぱのF7向けFatFs動作サンプルには今回得られた成果を収録して更新しました。
ねむいさんからのくりぷれです！

STM32も進化を重ねF7になった今でもやってることは相変わらず、SDカードから
読み出した画像データや動画を表示せしめることしかできませんがねむいさんは
F10とかになってもきっと同じことしてるでしょう。いいか我々にはこれしか道はない！
~~私はロリ↓コン↑ではない！~~
↑ねむいさんの好きなゼEROのキャラはカーネルやジェネラルのレプリフォース勢

ついでに初期F4シリーズ向け、LPC1788そしてLPC4088のFatFsサンプルも
SDカードの内部レジスタを正しく表示/パースできるよう更新しました。
そいえば今回の改修の際に気付いたのですがSTM32F4向けのCubeF4以前の
SPLがなんと今年秋にアップデートしていました･･･しかもDSI使える最新の
STM32F469/479にも対応してます。こちらももちろん反映してあります！

さらにGitHUBにあるSTM32Primer2 GPSTr@ckerもプログラム中では直接使用
してはいませんが別のプロジェクトに流用した時すぐ使えるようにSDIO
ドライバを更新してます。
じわじわと外人さんからの需要が出てきているようでうれしい限りです★

CIDレジスタのパース機能を付けたおかげもあって他のSDカードだとどうなって
いるのかも興味が出てきましたのでいろいろ読み出して試してみようと思います。

STM32F7を使ってみる7 -秋月さんよりF7Discovery販売記念-

※とある大切な方の訃報を受けて霊場めぐりをしていたため更新が一週間以上遅れて
　ます。すみません。

先々週末、秋月さんよりSTM32F7-Discoveryが販売されました。
入手しやすくなった事によって皆さんもF7に触れるチャンスができたと思います。
ねむいさんもF7ネタで一つ記事を書きたかったのですがいまいち"ぱんち"が弱く
更新に躊躇していたので今回の販売開始は渡りに舟でした。しかももう一つ嬉しい
ニュースも同時にでてきました。

●OpenOCDがSTM32F7の内蔵フラッシュ書き込みに正式対応
7月上旬、私が最初にいじりだしたころからF2/F4系と別系統のSTM32F7のテスト用
ドライバは存在していたのですが秋月さんの販売と時を同じくしてOpenOCDにF7系の
フラッシュ書き込みサポートがF2/F4ドライバに正式にようやく追加されました。

Corex-M7はL1キャッシュを持つのでフラッシュ書き込みルーチンを呼び出すとき
にメモリバリア命令を張って意図した手順で書き込みのための命令を実行させる
ようにしないといけませんでした。
最初にコミットされた時はそんな理由でF7専用のフラッシュになっていましたが
同じMPUを持つF2/F4系でも問題が無かったため結局stm32f2x.cに統合されています。

> "C:¥Devz¥Coreutils¥bin¥make.exe" program

openocd  -s C:/Devz/ARM/OCD/tcl -f target/stm32f7discovery_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.10.0-dev-00104-gf3be0f6-dirty (2015-11-13-09:52)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.org/doc/doxygen/bugs.html

Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD

adapter speed: 2000 kHz

adapter_nsrst_delay: 100

srst_only separate srst_nogate srst_open_drain connect_deassert_srst

Info : Unable to match requested speed 2000 kHz, using 1800 kHz

Info : Unable to match requested speed 2000 kHz, using 1800 kHz

Info : clock speed 1800 kHz

Info : STLINK v2 JTAG v24 API v2 SWIM v11 VID 0x0483 PID 0x374B

Info : using stlink api v2

Info : Target voltage: 3.219974

Info : stm32f7x.cpu: hardware has 8 breakpoints, 4 watchpoints

stm32f7x.cpu: target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0x01000000 pc: 0x0803276c msp: 0x20010000

auto erase enabled

Info : device id = 0x10016449

Info : flash size = 1024kbytes

stm32f7x.cpu: target state: halted

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x20000046 msp: 0x20010000

wrote 786432 bytes from file main.elf in 18.501879s (41.509 KiB/s)

stm32f7x.cpu: target state: halted

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20010000

stm32f7x.cpu: target state: halted

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20010000

stm32f7x.cpu: target state: halted

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20010000

verified 600552 bytes in 2.451303s (239.251 KiB/s)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:21

書き込みはこんな感じです。以前と全く変わってませんね～。
私が提供しているバイナリはもちろんSTM32F7-Discoveryに対応しています★
また、以前も伝えましたがSTLink/V2-1のファームは2.24.11以降にアップデートして
おいてください。古い番だとmbedのMSCの方のインターフェースと干渉して書き
込みが必ず失敗してしまいます。秋月さんで購入できる奴はさすがに最新版に
なってるはずですのでたぶん問題ないでしょうけど。

●MPUとSDRAMのキャッシュ設定
過去にも少し触れたMPUの事ですが、F2/F4系ではほとんど出番がなかった代物ですが
L1キャッシュが実装されたF7系では極めて重要な意味を持ちます。しっかり考えて設定
しないとパフォーマンスに大きな影響が出てしまいます。

書くいう私もキャッシュの概念をよく理解してなくてDMAで無駄に苦戦したり
してましたが新たにFMCを使ったSDRAMで手落ちを見つけてしまいましたorz

↑AN4667より引用
通常はFMCはD-Cacheを通じてアクセス速度の向上が行われているのですが、それが
有効なアドレス領域はCortex-M7のコア上で制限があります。
SDARAMが割り当てられるアドレス(0xC0000000~)ではご覧のとおりキャッシュ
メモリの恩恵にあやかることができません。

↑AN4667より引用
FMCのSDRAMのアドレスをリマップしてキャッシュが効くアドレス領域に変える
方法もありますがMPUでキャッシュ可の領域に設定してしまう方が簡単です。

MPUの設定はこんな感じです。キャッシュ有効の時に"MPU_ACCESS_NOT_BUFFERABLE"
とするとライトスルーとなります。
ライトバックは"MPU_ACCESS_BUFFERABLE"です。

なお、FMCやSDRAMを有効にしてなくてもMPUはそれらと完全に分離しているので、
設定した瞬間にいきなりHardFaultとかになることはありません。
また、QSPIの領域については前途のとおり元からキャッシュ可になっていますので
特にMPUを設定する必要はないです。

てわけで早速いつものjpegファイルのデコード時間で比較してみましょう。
その１．フラッシュインターフェースはAXIM

↑MPUは何も設定してないSDRAMのD-Cache無効状態です。
　最適化スイッチは-Ofast、FONTX2ドライバは内蔵フラッシュからです。

↑MPUを使ってSDRAMのD-Cache有効、ライトスルーです。
　最適化スイッチは-Ofast、FONTX2ドライバは内蔵フラッシュからです。

↑MPUを使ってSDRAMのD-Cache有効、ライトバックです。
　最適化スイッチは-Ofast、FONTX2ドライバは内蔵フラッシュからです。

予想通りキャッシュ無効のデフォルト状態の方が断然はやi...
…
？？？
？？？どういうことなんだ？？？(←C.V.櫻井のイケボで)

キャッシュ無効が一番早いじゃないですかー！？たぶんAXIMバス経由でプログラムを
実行してるからバスのトランザクションとかキャッシュラインが干渉しまくって
逆にパフォーマンスが低下してしまったのでしょうね。
･･･すみません適当な考察で…てわけでAXIマトリクスの影響を受けないITCMから
プログラムを実行してみますか。

その２．フラッシュインターフェースはITCM

↑MPUは何も設定してないSDRAMのD-Cache無効状態です。
　最適化スイッチは-Ofast、FONTX2ドライバは内蔵フラッシュからです。

↑MPUを使ってSDRAMのD-Cache有効、ライトスルーです。
　最適化スイッチは-Ofast、FONTX2ドライバは内蔵フラッシュからです。

↑MPUを使ってSDRAMのD-Cache有効、ライトバックです。
　最適化スイッチは-Ofast、FONTX2ドライバは内蔵フラッシュからです。

ITCM経由だとバスの競合が減りますので確かにキャッシュが効いているのが
分かりますね★
所で本来ならライトスルーよりライトバックの方が早くなるはずなのですが、
ライトスルーの方がほんの少し早い結果になりました。キャッシュを効かせて
いるとキャッシュヒットとミスの時のブレ幅がかなり大きく出てくるので
そっちの方が気になるくらいですけど。

おきぱのF7のサンプルではAXIM/ITCMの両方でSDRAM領域のMPU有効・ライト
スルーキャッシュ設定にして更新しております。
以前はQSPI-ROMにFONTX2ドライバを置いていた場合文字の表示で崩れる
ことがあったのですがSDRAM領域もMPU・キャッシュ有効にするとそれが
一切発生しなくなったという副次的効果が見られましたのでAXIMだと
若干パフォーマンスが落ちますが敢えてMPUを効かせています。

もちろんキャッシュを経由するとDMAの問題がまた持ち上がってきますが
私のサンプルではDMA2Dをそうなる使い方はしてないのが分かったので
DMA対策は特に行わず様子見としております。

さらについでですがCubeF7もV1.2.0になってHALライブラリもV1.0.2に
アップデートしておりますので差し替えてあります。
でもSDMMCのuint64_tで処理しなきゃならない処理がuint32_tのままで
まだ治ってないので私自らHALライブラリに修正を加えておきましたｸｿｧ！

STM32F7を使ってみる6 -タッチパネル入力とQSPIの追加-

もう気づいた方もいるかもしれませんがSTM32F7向けのいつものを9月1日版に
更新しております。
変更点は細かいバグ潰しと容量性タッチパネル入力、そしてQSPIの対応です。

●CTP(容量性タッチパネル入力)対応
STM32F7Discoveryには上記のタッチパネル付きのTFT-LCDモジュールが搭載
されています。型番でググっても出てこないのでおそらく特注品なのでしょう。
CTPコントローラにはFT5336GQQなる物が使用されております。

さて、以前はもっとも単純なADS7843系、ちょっとインテリジェンスな
機能をもつSTMPE811等の抵抗膜式のものを扱ってきました。
容量性の場合はメカニズムが全く違い複雑になるので専用ICに頼らざるを
得ないのですがそれの使い方を把握するのでもこれまた複雑で正攻法で
行くととても時間がかかってしまいます。

そんなわけでSTマイクロ提供のCubeF7ライブラリ群にはBSPとして
FT5336GQQ用のアクセス用関数がちゃんと用意されています。
しかもF7-Discovery用にI/Oの設定も御誂えております。

実装は拍子抜けするくらい容易でした。私の過去のタッチパネル入力の
処理と結合させてGPIOのエッジ割り込みの処理を追加するだけで済みました。
F7-Discoveryのデモではタッチした状態が変わらないと割り込み処理を
抜けられない構造になっていてデッドロックの危険性があったので、
そこだけは省いています。

他の上位のレベルの処理は一切変えていないので過去の抵抗膜式のものと同じ
ような感覚で操作できるようになっています。

本来ならばFT5336GQQのBSPがやってる処理を分解・再構築して自分独自の
タッチパネル入力処理とすべきところなのですが残念ながら私の技術力はそこまで
及ばずあえなく安易な方法、"出来合いの処理"を提示されたライセンスに従って
利用させてもらうことにしました。F7になってからは複雑化も相まってそういう
場面が多数出てきています。
私も巨人の肩の上に乗る小人のうちの一人にすぎないのです…!

前向きに考えるとソースコードを公式のものと互換性を持たせて問題を切り分け
易くするなんてことも言えますがゆくゆくはSeggerのSTemWinとかも使ってみたい
ので何でもかんでも自作にとらわれず柔軟にやってこうと思います。
もなかさんもこう言ってますしでも素のEclipseなんて絶対に使いませんよぅ！！
ｹﾞﾎｹﾞﾎ･･･ﾊｧﾊｧ失礼･･･次に進みましょう･･･

●QSPI-ROMをメモリマップドモードで使う
こちらはLPC4330の時にも紹介した奴と同じですね。SPI-ROMのメモリ領域が
特別な関数を経由せずにリニアにアクセスできるという便利な機構です。

ことSTM32F7に限ってはD-Cacheを挟むので従来のSPI-ROMではどうしようも
なかった速度的なボトルネックはある程度解消されるようです。

F7のHALライブラリにはQSPIの関数/BSPが用意されていますがメモリマップドモード
で使用する場合は一度イニシャライズしさえすれば後は普通の内蔵フラッシュ
メモリと全くおんなじです。

今回もBSPを最大限に利用させてもらっていますが、QSPIのメモリマップドモードでは
読み出し専用で使う場合は割り込み処理は全く不要なので初期化時のNVICの設定
を省いておくこともできます。

私はQSPI-ROMをFONTX2のデータ置場として利用しました。
F746DiscoveryではN25Q128Aが搭載されています。N25Q128Aは一セクタあたり
64kByteずつ分かれていますのでFONTX2ファイルを書き込むアドレスは半角を
0x90000000、全角は0x90010000に配置してみました。

あとQSPI-ROMにデータを書き込む方法ですがSTLinkUtilityのVer3.7からF7Discovery
用の外部フラッシュローダに対応しています。これを利用して書き込みます。

先ずは半角

お次は全角。
なんでか拡張子はbin,elf,hexしか駄目なのでFONTX2ファイル書き込む際は
拡張子をbinに変えて書き込んでください。

こうやってQSPI-ROMに書き込んだデータは上記のようにして参照します。
メモリマップドモードだからできる技ですね～

無事に起動しました。S-JIS形式のtxt文書もごらんの通りです。
ビルド時に巨大なFONTX2ファイルを組み込む必要がなくなり、フラッシュ書き込み
に掛かる時間も節約できてテンポよくデバッグできるようになると思います。

デバッガからQSPIのメモリを参照するとこんな感じに見えます。
もちろん参照時はメモリマップドモードになっている必要があります。
これは半角のFONTX2です。

こちらは全角です。

現在はまだ限定的かつ実験的な使用にとどまっていますがQSPI-ROMの有効な
活用法が新たに見つかったら紹介していきたいと思います。

●おまけ
いつもののmakefileみたら何をどうすればわかるとは思いますが、デフォルトでは
以下の"ひとまず確実に動く設定"になっています。

1:内蔵フラッシュインターフェース
　->AXIM
2:SDRAM
　->有効
3:タッチパネル
　->有効
4:FONTX2
　->内蔵フラッシュから参照かつQSPIは無効

"4:"のFONTX2のドライバでQSPI-ROMを参照したい場合は当たり前ですが、
あらかじめ半角/全角それぞれのFONTX2ファイルを上で紹介した手順で
QSPI-ROMの適切なアドレスにSTLinkUtilを使用して書き込んでおく必要があります。

STM32F7を使ってみる5 -AXIMとITCM-

STM32F7の内蔵フラッシュメモリは以下に示す2系統のインターフェースで命令
コードを読み出し実行することが可能です。

The AXI-Master (AXIM) interface

TCM Interface

Embedded Workbenchマニアのページさんの記事を参考にして私なりに両者の
性能の違いを確かめてみました。また、各モードで上手く使いこなすための
コツも紹介します。

●AXIM経由のフラッシュ
こちらはCubeF7の各種サンプルプログラムでデフォルトで使用されているスタン
ダードなものです。フラッシュメモリのアドレスは0x08000000に配置されており
過去のSTM32シリーズと同様の感覚で使用できます。
フェッチされた命令はCortex-M7コア内のI-Cacheを有効にしていればフラッシュ
のアクセス速度の遅さを補うことができますのでフラッシュの素のアクセス速度
の遅さを気にせず過去のSTM32シリーズとほぼ同様に使用することができます。

そんなわけで早速表示です。SDRAMのタイミングを正しい値に修正したこと以外は
前回お見せした対策その１と同じ構成です。

●ITCM経由のフラッシュ
ITCMバスにはF2/F4シリーズでおなじみのARTアクセラレータが乗っかっています。
I-Cacheは経由しませんがアクセラレータのおかげでフラッシュの素の(ry
ちなみにITCM経由のフラッシュアクセスの場合、アドレスは0x00200000に配置され
ている事になります。ITCM経由で動かしたい場合はリンカスクリプトの開始アドレスを
0x00200000にしましょう。

なんとこちらの方が高速です！Embedded Workbenchマニアのページさんでも述べられ
ているとおりAXIM経由の場合はフラッシュの命令の他に様々なペリフェラルが行き
かっているので命令はITCMに押しやるのが本来取るべきスジなのでしょう。

●ITCMるコツ
上記の結果だけ見るとAXIMのメリットないじゃんてお思いの方が多いと思います。
残念ながらITCMも結構ピーキーな性質でスムーズに開発を行うために知っておかな
ければならないいくつかのコツがあります。

1.ITCMのアドレスではDMA出来ない
　RMを読む限りではバスがDMAコントローラのどこにもつながってないのでこの
　アドレスではDMAが一切出来ないと思います。DMA元にconstを決め打ちする
　ような転送ではHardFaultになって失敗するでしょう。
　もちろんITCMバスにぶら下がっているITCM-RAMもDMA不可能です。
　このへんF4のCCMと同じ位置づけですね。
2.フラッシュは0x08000000に焼く
　ITCMから見えるフラッシュのアドレスは0x00200000ですがそのアドレスには
　フラッシュメモリの実体はなく、過去のSTM32シリーズと同じ0x08000000に
　あります。0x00200000に無理やり書こうとしても弾かれます。
　
　↑こんな風にエラー出て駄目です。
　したがってOpenOCDではhexやelf形式のフラッシュ書き込みは100%失敗しますので
　binファイルを0x08000000に向かって書き込むようにしましょう。
　
　makefile上ではこんな感じです。9/Sにリリースする新版のいつものではフラッシュに
　ITCMを選択すると必ずbin形式で書き込むようにmakefileをいじって置きますので
　ねむいさんと同じ開発スタイルの人は特に気にせず快適に書き込み＆デバッグが
　できると思います★

　おまけです。
　
　↑AXIMで動かしてる時のデバッグ画面。
　
　↑ITCMで動かしているときのデバッグ画面。PCの値に注目。

　F7シリーズはBOOT0の状態で起動できるアドレスの番地が可変になりましたが、
　デフォルトではフラッシュメモリからブートする場合、ITCMインターフェースの先頭
　0x00200000から開始になっています。AXIMでもきちんとスタートアップを記述
　していれば0x08000000の番地にすぐに飛んでくれるので問題ありません。

･･･徐々に、そして確実にSTM32F7の真の力が明らかになってきています。
今までの私の使ってきたワンチップマイコンの概念のままでは到底その力を引き出す
ことはできないでしょう。しかし私はそれに臆さずどんどん新しい概念に切り込んで
いきたいと思います！！

STM32F7を使ってみる4 -CPUキャッシュとDMAを考慮する-

前回DMA転送がうまくいかなかったと抜かしていましたが原因は至って単純な
もので私にCPUキャッシュについての知識が無かっただけでした！！！！！
めでたしめでたし♥

20231123追:
古いCortex-M7コアにはキャッシュ周りにバグがあります！！
こちらのエントリも必ず見てください！！１！！１！！
20231123追:

今回は上の三行で終わる内容ですが前回の記事そのものがCortex-M7アーキテク
チャを全く理解してないおまぬけなねむいさんのままで終わってしまう(あたしはまだ
終わってはない！）のでもう少し突っ込んで解説したいと思います。

STM32F7にはI-CacheとD-Cacheの2つのレベル1キャッシュメモリがありこれらを
有効化させることによりリアルタイム性が落ちる代わりに全体の処理の高速化を
図っています。今回はデータ用キャッシュメモリD-Cacheに着目します。
今回の記事を書くにあたってユークエストのビリー様のサイトを参考にさせていただきました。

私のいつものではプログラム開始時にI-CacheとD-Cacheを有効にし、さらにMPUで
SRAM1,2領域(256kByte分)のWriteThroughを有効にしています。CPUからのこの
SRAM領域(以下本メモリ)への読み書きはWriteThroughによって常に本メモリと
D-Cacheの一貫性(Cache Coherency)が保たれています。WriteBackよりも多少は
処理速度は落ちますがそれでもD-Cacheの恩恵に与かれるので確実で強力です。

しかしながらこの関係が破れるのがDMA転送をする時です。

DMAコントローラはキャッシュメモリを介さないのでD-Cacheと本メモリの一貫性を
保てなくなりDMA転送後に本メモリから読みだしたはずの本当のデータはD-Cache
に残った古いデータで正常に読みだせない&転送がコケる(ように見えた)という事に
なります。以下にlibjpegで画像をデコードした際の実例を示します。

こちらは虹裏的美少女画像をSDMMCのデータ転送にDMAを一切使わずFIFOのポーリ
ングで読みだした所の写真です。右下に表示にデコード完了に掛かった時間を表示して
います。I/D-Cacheは有効です。

無対策でDMAで読みだした時の写真です。途中でデータがおかしくなってひでぶ
しているのが分かります。上記のとおりD-Cacheに残った古いデータのせいでめちゃ
くちゃになってる訳ですが、当たり前ですが表示にすら至らないケースもあります。

その前に脇道にそれますがlibjpegとFatFsを結合している関数について、この関数
内ではlibjpeg側で先にmallocで取得したデータ読み出し用バッファをDMAの読み出し
先にしてしまいます。

つまり私のいつもので使うFatFsのデータ転送用汎用バッファBuff(上記画像参照)が
どのメモリ領域にいるかは関係がなく、リンカスクリプトでHEAP領域にD-Cacheの影響
を受けるSRAM1,2を割り当てているとDMA転送時の上記の問題に思い切り引っ掛かる
ことになります。それを踏まえたうえで本題の比較に入ります。

プログラム開始時の時点でD-Cacheそのものを無効にすると当たり前ですがデータ
の齟齬が発生する余地が全く無くなりますので表示がおかしくなることはありません。
しかしながらパフォーマンスはガタ落ちになります。これじゃF7使う価値がないです。

対策その1です。
FatFsの汎用バッファをキャッシュの影響を受けないDTCM領域に配置し、さらにDMAの
4バイトアライメント対策もDTCMの1セクタバッファでフォローする作戦です！
CPUコアと同速度で動くDTCMでキャッシュの影響とレイテンシの不確実性を最小限に
でき、確実な転送が可能です！！

しかしこの方法は以下の制約を受けるのでご留意願います。
1.リンカスクリプトでDATA,BSS,STACK領域を必ずDTCMに割り当てるべし。
2.mallocで引っ張ってきたメモリドレスがDTCMのアドレスじゃなかった場合の
　対処を講じる必要がある。実際は読み書き元のアドレスを検知してDTCMの1セクタ
　事の読み書きに変えるかキャッシュコントロール関数を使用するかです。

私のSTM32F7向けのいつものはこの対策1を施しておあります。

対策その2です。
DMA転送する前にD-Cacheの無効(Invalidate)だけを行います。CMSISのヘッダライ
ブラリでは上記の無効にする関数が用意されています。STM32F7のキャッシュサイズ
は4kByteでlibjpegの一度に読みだすサイズもデフォルトでは4kByteとなってます。
(注:Cortex-M7のキャッシュは1ライン32byte*128本で合計4096Byte)
D-Cacheの1ラインごとにInvalidateする関数もありますが今回は読み出しサイズが
キャッシュサイズと同じなので全部Invalidateする関数を呼び出してます。
SDMMCのDMA転送を行う関数の頭にSCB_InvalidateDCache()を置いて実行してい
ますが対策その1よりも若干遅くなっています。

そういえば･･･Disableも無効って意味なんですがあちらさんではどう
使いわけてるんでしょ…

対策その3です。
DMA転送する前にD-CacheのInvalidateとCleanを行います。
SCB_CleanInvalidateDCache()を呼び出しますが必然的に対策その2よりもさらに
遅くなっています。

対策その2と3は単純にCMSISヘッダライブラリの関数を実行すればいいという訳では
なく、DMA元/先として使うバッファのアライメントとサイズに制約があります。
D-Cacheのキャッシュラインのサイズにアライメントを合わせ、なおかつそのサイズの
整数倍にしないとやっぱりデータの齟齬が起こってしまいます。
特に読み出し時はDMA用に確保したバッファの近辺のアドレスに配置されている変数
までしっかり破壊してくれやがります。STM32F7の場合は1キャッシュライン当たり
32Byteの固定値となっているので32バイトのアラインメント且つデータサイズが32の
倍数になる必要があります。

もしバッファ用のメモリ領域が上の条件を満たさない場合はアライメントとデータサイズ
の丸め込みを行う必要性があり更にオーバヘッドが増えます。RTOS向けのデバイス
ドライバを作成される際はこの点も考慮する必要があります。

以上の点を踏まえると別に無理してDMAしなくてもいいんじゃないかと思われるかも
しれませんがそれではロマンが無いので是が非でもDMAらせていただきます！

そんなわけでD-Cacheを考慮した修正版のいつものをあげておきます･･･

おまけ
libpngやlibjpegは無対策でも平気だったのですが何故ひでぶしないで平気だったのかも
調べてみました。

giflibはSDMMCのブロック転送時にfptrがクラスタの境界になく、その際の一時
転送先がDTCM領域のFatFsオブジェクト内(のwin配列)に確保されています。
つまり対策その1とほぼ同じ事をFatFsライブラリ内でやってくれているわけです。

libpngもgiflibと同様になっています。

STM32F7を使ってみる3 -FatFsとLCDコントローラを動かす-

前回ねむいさんはUARTとFatFsをデモを参考にSDカード向けに組み替えて動作
せしめるところまで来ました。調子に乗ってDMA化しようと試みたのですが
なんでか正しく転送出来ませんでした。

ねむいさん真っ先に悪名高いHALライブラリにバグがあると思って調べまくり
ました。SPLで組んだF4のSDIOの転送するルーチンやDMAの処理の部分などを
穴の開くほど見比べたのですがこれと言って悪い箇所が見当たらず、まさか
エラッタかと思ってエラッタシートやフォーラムもしらみつぶしに見たのですが
そもそもまだF7が広まってない段階なので手がかりすら見つかりませんでした。

20150807追:
ここまで読んで｢あ、こいつキャッシュのこと理解して無い馬鹿野郎だ｣と思った
方はさっさと次のエントリに進んでくだち
20150807追:

DMA転送用のバッファメモリをDTCMやSRAM2や外部SDRAMとかにおいてもﾀﾞﾒﾀﾞﾒ
で困り果てていたのですがF7のデモがDTCMを含めた複雑な構成のSRAMを単純に
320kbyteのでかいSRAMとして扱っていたのを思い出し、ねむいさんも細かい
RAMの割り振りをやめてデモと同じようにしてみました。

するとDMAでもちゃんと転送できた。

ぇえ～～～何が違うのよ！とぶちぶち言いながら何が足を引っ張っているのかの
切り分けを進めていくと最終的にFatFsの構造体をDTCMに配置していないと、
DMAがコケることが分かりました。デモではリンカスクリプトでDTCMの領域の
0x02000000から各種変数が割り当てられるため、問題だったSRAM1領域以降の
RAMまでは使用されていないことが分かりました。

データ用バッファとか話が分かるのですがなんでFatFsの構造体がDTCM領域に
無いと何故DMA転送できないのか理由が全く分かりません。F7はまだ世に出た
ばっかでエラッタも未知のものがたくさんあるでしょうから今は深追いは止め
てその先の作業に専念することにしました(しかしこのあとさらなる罠が)。
20150805追:
単にD-Cacheの取り扱いがわかってなかっただけでしたすみません。

と言う訳でFIFOポーリング版とDMA版の読み取り速度の比較を行ってみました。
ポーリング版でも効率化されてますのでDMAと遜色なくなってますね～。ていうか早い
勿論条件は過去と同じ、スピードは双方ともSDHighSpeedModeにしております。
20150807追:
上の結果ですがPLLSAIの設定間違っていて実際はSDIO_CLK=44MHzくらいで測定
してましたすみません！！

↑ＰＬＬＳＡＩの設定を正しく行ってSDIO_CLK=48MHzで読み出したときの
　真の速度です。

SDRAMを使用するとSTM32F7の最大クロック周波数は200MHzまでとなってしまい、
この時のSDMMCのクロックはSYSCLKから供給していると単純計算で48MHzよりも
若干低下してしまうのですがSAI用のPLLをSDMMCのクロック源とすることで48MHz
きっちり動作させることができます。

ひとまずFatFsはめどがついたのでお次はLCDコントローラ(LTDC)です。こちらも
以前STM32F429Discoveryで予習していたはずなのですがSPLとまっっったく構造が
代わっていたので難儀しました。

LTDCについては各種設定を行った後フレームバッファとするSRAM及びSDRAMの
ポインタを参照すれば何とかいつも通りに色を出せたのですが問題はDMA2Dでした。
ああでもないこうでもないを重ねてようやくF429で出来たのと同じように動作させる
ことができるようになりました。結局元のF4のSPLのコードを穴の開くほど読み込んで
CubeF7とどう違うのかの地道な切り分けです。

以下にDMA2D版のDisplay_wr_block_if()のF4版SPLとCubeF7の違いを示します。
両者とも色深度はRGB565の16bppです。



inline void Display_wr_block_if(uint8_t *p,unsigned int cnt)

{

	/* Set Display Pointer */

	lcd_c_buf_ptr = lcd_f_buf_ptr + 2*(lcdc.x + MAX_X*lcdc.y);



	/* configure DMA2D */

	DMA2D_DeInit();

	DMA2D_InitStruct.DMA2D_Mode 			= DMA2D_M2M_PFC;

	DMA2D_InitStruct.DMA2D_OutputMemoryAdd	= (uint32_t)lcd_c_buf_ptr;

	DMA2D_InitStruct.DMA2D_OutputOffset		= (MAX_X - ((lcdc.width+1) - lcdc.x));

	DMA2D_InitStruct.DMA2D_NumberOfLine 	= (lcdc.height+1) -lcdc.y;

	DMA2D_InitStruct.DMA2D_PixelPerLine 	= (lcdc.width+1)  -lcdc.x;

	DMA2D_Init(&DMA2D_InitStruct);



	/* Configure default values for foreground */

	DMA2D_FG_StructInit(&DMA2D_FG_InitStruct);

	DMA2D_FG_InitStruct.DMA2D_FGMA 			= (uint32_t)p;

	DMA2D_FGConfig(&DMA2D_FG_InitStruct);



	/* Start Transfer */ 

	DMA2D_StartTransfer();

	

	/* Wait for CTC Flag activation */

	while(DMA2D_GetFlagStatus(DMA2D_FLAG_TC) == RESET){}

}

↑F429の



inline void Display_wr_block_if(uint8_t *p,unsigned int cnt)

{

	/* Set Display Pointer */

	lcd_c_buf_ptr = lcd_f_buf_ptr + 2*(lcdc.x + MAX_X*lcdc.y);



	/* configure DMA2D */

	Dma2dHandle.Init.Mode         = DMA2D_M2M_PFC; 		/* memory to memory with PFC */

	Dma2dHandle.Init.OutputOffset = (MAX_X - ((lcdc.width+1) - lcdc.x));

	/* DMA2D Initialisation */

	if(HAL_DMA2D_Init(&Dma2dHandle) != HAL_OK) 

	{

		/* Initialization Error */

		while(1); 

	}



	/*　Start DMA2D transfer */  

	if(HAL_DMA2D_Start_IT(&Dma2dHandle, 

					/* Source Buffer */

					(uint32_t)p,

					/* Dist Buffer */

					(uint32_t)lcd_c_buf_ptr,

					/* width in pixels  */

					((lcdc.width+1)  -lcdc.x),

					/* height in pixels */

					((lcdc.height+1) -lcdc.y))

	!= HAL_OK)

	{

		/* Initialization Error */

		while(1);

	}

}

↑F7の

DMA2Dを利用したレクタングルの塗りつぶし等の図形表現も無事再現できました。
F429で出来てたことをF7で再び出来るようになるまで1週間以上かかりやがりま
したがCubeF7が抽象化しすぎて逆にプログラムの流れが分かりづらいとかそも
そも作りこみが甘くbuggyとか公式のフォーラムでも未だに非難GOGOでF7版SPL
くだちとかいろいろ言いたいのですがまぁそれは置いといて…。

UART,FatFs,ディスプレイまで出来たら既にねむいさんのいつものができたと言っても
過言ではありません。ChaNさんの2009年作のLPC2388向けのデモをベースに足かけ
6年…もう６ねｎ…ｎ…グハッ！！！

失礼、ちょっとむせました。

画像はpngないないさん♥
libjpeg,giflib,libpng3つの画像ライブラリを用いたデコードも紆余曲折ありましたが
いつも通り出来るようになりました♥
こちらについては話が長くなるのでDMAする時のD-Cacheの取り扱いと合わせて
次回解説させていただきます。

そういうわけでSDMMCのDMA転送でだいぶ足止め喰らいましたがようやく形になって
来ましたのでここでいつものの公開をさせていただきます。残るは容量性タッチパネル
の処理の実装ですがこちらも初めての分野なのでじっっっくりと取り組んでいこうと
思います。

STM32F746G-Discoveryのいつものはこちら

STM32F7を使ってみる2 -STM32CubeF7移植への道-

STM32F7シリーズは今年から量産開始した新しいマイコンです。つまり昔から
STM32を昔から弄ってる人にとってはおなじみだったStandard Peripheral Library
(=SPL)のF7版なぞ影も形もなく、STM32CubeF7ライブラリ通称HALライブラリ
しか存在いたしません！

ChaNさんクラスの実力がある人ならリファレンスマニュアルからレジスタ構成を
引っ張ってきて自前のペリフェラルライブラリこさえるのでしょうけどねむいさんに
そんな力があるはずもなくなすすべもなくSTマイクロのエコシステムの一部に
とりこまれてしま…ぅ･･･

まだまだだぁ！！！

幸いにもCubeF7ライブラリの中にはSW4STM32(System Workbench for STM32)
なるEclipseベースのフリーのIDEがあり、コンパイラはGCCを使用していますので
これを分析することによって私のコマンドライン&makeの環境移植へのとっかかり
を見つけることが出来ました。
ところでなんでEclipse使ってるのに全身から血を吹き出して死なないのかこの
嘘吐きめと突っ込みたいでしょうが私はメーカーお仕着せの各種設定完了済の
Eclipseのカスタム版IDEでは無傷です。あくまで死ぬのは未設定の素のEclipseで
攻撃された時だけです。あといないさんがスカートをたくし上げて下着を見せてるイラストを
見せられただけでも死ぬので絶対に見せないでください
絶対にですよぅ！！！！

それはおいといてSTM32F7-Discoveryを使ってF7版のいつものの構築に移ります。
昨年の時点でNucleo系の板はSPLからHALライブラリに引っ越ししておりました。
しかしあくまでUARTやI2Cと言った基本のライブラリを動かす程度に留まって
いたのですが今回はSDRAMやFatFsなどを動かすところまで行きます。

STM32F7になってメモリ構成がF4よりもはるかに複雑になりましたが基本は
全く変わっていません。恐れずにF4と同じようにプランを練っていきました。

TCMのうちユーザーが触ることができるDTCMはF4ではできなかったDMAができる
ようになったので細かいことは気にせずスタック/Auto変数領域に割り振る
ことができます。CubeF7のExampleではDTCMの初めからメインSRAMの終わりまで
をまるまる一本の巨大SRAMとして使っていますので細かいこと気にするなと
言うことなのでしょう。実際DTCM～SRAM2までリニアに繋がってますし。
↑実はこれが伏線だった…

そんなわけでいつものGCCのビルド環境のひな形が出来ました

先ずは基本の"き"LED点滅とUARTから。
LEDはF7-Disacovery上ではArduinoUNOライクなコネクタピンのSCKに
相当するPI1です。

なお、昨年くらいのCubeF4のアップデートで気づいたのですがGPIOのビット
単位でセット/リセットが可能なレジスタSBRR/BRRと言うのが昔はおなじみ
だったと思いますがそれが廃止され32bitのSBRRのみとなってやがります###
ビット単位でI/Oをやり取りする際にこれは超不便且つビットアクセスのための
新しくできたHALライブラリのオーバヘッドがでかすぎるので旧来のGPIOの
構造体を作って昔と同じように16bit幅のSBRR/BRRレジスタをアクセス
できるようにしました。

UARTはSTLink/V2-1のVCP入出力が繋がるUSART1ポートのPA9(TX)、そして
GPIOB7(RX)です。RXピンはおなじみのPA10じゃないのでご注意を！

と言うわけでこの2つはF4版NUCELOを参考にF7用にあてはめるだけでOKでした。

もちろんprintf関数などのnewlibの関数群との結合も余裕です★

ここでちょっと注意ですがSTLink/V2-1でVCPを使う際に特定のUSB3.0
ホストに差すとSTLink/V2-1側から送信するUARTの信号が正常に出力
されない場合があることを発見しました。
その特定のUSBホストと言うのはFL1100なのですが上記の画像のように
めちゃくちゃな信号が出力されてSTM32F7側と正常に通信ができません。
もしUSB3.0ポートで上手くいかない場合はUSB2.0ポートに差し直して
試してみてください。

お次はSDRAMです、F7-Discoveryには128MbitのSDRAMが搭載されています。
こちらもBSPの初期化コードを参考にねむいさんの環境に嵌めて行って危なげなく
動作せしめることが出来ました。このボードにおいてはSDRAMBank1に配置されて
いて0xC0000000が開始アドレスとなっています。

STM32F7でFMCを使ってSDRAMを使用する場合、F7側はデータバスが16bit分
しかないので32bitの変数のアクセスはAHBバスで16*2bitに分割転送されます。
そんなわけでこのボード上では上位16bit分のデータバスを男らしくバッサリ
捨てており容量は128MBitありますが実質64MBit分しか使えませんorz
また、Example曰く実装されたSDRAMが安定動作するシステムクロックの
上限は200MHz、その時のSDRAMCLKの上限は100MHzになるので、
(↑根拠としてSTM32F7のデータシートに下記の記述がありました。
　For 3.0 V≤ VDD≤ 3.6 V, maximum FMC_SDCLK = 100 MHz at CL=20 pF (on FMC_SDCLK).)
単純計算で100MHz*16=1600MBps
が理論値となります。なんかちょっともったいない使い方ですね…。

前回の記事でたけさんと言う方からリクエスト貰いましたのでSDRAMのR/W
性能を測定してみました。4MByte分(下述)を16bit変数単位で読み書きした値です。
D/I-Cacheは有効にしていますが妙に数値が低いのは私のコーディングが悪い
せいでしょうか･･･

最後にFatFsです。CubeF7謹製のFatFsのローレベルドライバはやたら凝っていて
USB-OTGのUSB-MSCの接続も想定したつくりになっています。FatFSで必須な
関数群はFATFS_LinkDriverなる関数で結合する仕組みとなっています。
今回からはSTのスタイルに倣ってそれを積極的に使うようにしました。
といっても私のプロジェクト向けにほんの少しの変更をしただけですが。

まだTFT-LCDのドライブまでは進めてないのでUARTからのコマンドでFatFsの
動作を確認しました。F7-DiscoveryではSDIO改めSDMMCインターフェースが
出ていてSDカードからのデータを高速にやり取りできます。

いつものごとく読み出し速度を調べてみました。CubeF7のExampleではSDMMCの
クロックは潰しの効くNomalMode(25MHz以下)に抑えられているのでF4の25MHzと
さほど変わりませんね。

CubeF7のライブラリを調べているとDMAは全く使用してないFIFOポーリングで
読み書きを行っていることが分かりましたがHALライブラリにはDMAを使用する
関数も用意されていてほんの少しの改修でDMA化できるので試してみました

が…！

なん…だと…！？

つづく！

STM32F7はぢめました

昨年秋にプレスリリースで発表されたSTM32F7ですが私がESP-ROOM-02弄りに
夢中になってる間にひっそりと市場に流通しておりました。
ﾋを見てたら国内外問わず既に入手してOpenOCDでバリバリ使い倒してる人たちもいて
STM32好きの私としてはすっかり流れに取り残された感じですがDigiKeyで大量に在庫
していたので私も一つ購入してみました。

目の前に現れたSTM32F7-Discoveryは私の知ってるDiscovery系のキットの想像を
超えた液晶もSDカードスロットも外部SDRAMもQSPI-ROMもついた夢の全部載せでした！
ちなみに液晶のタッチパネルは抵抗膜式ではなくなんと静電容量式です！
なんてゴージャスな…

Cortex-M7コアを持つSTM32F746NGH6が搭載されています。スペックについては昨年
秋も触れましたが量産開始後に最大動作周波数が200->216MHzにパワーアップして
ます。デバッガはSTLinkV2-1が搭載されています。

当然のごとくSDRAMが搭載されています。Micronの128MBitのSDRAMです。

同じくSTM32F7シリーズの目玉の一つQ(uad)SPI-ROMです。LPC4000シリーズの
SPIFIと同じくリニアなアクセスができるのが特徴です。FontX2ファイル等の
大規模データは一切合財ここにぶち込みましょう！

また、Ethernet用のPHYも搭載です。接続するピン数が少ないRMII方式で
STM32F7と接続されています。

さらにUSB-HighSpeed用のPHYまでついています！！こちらはULPIで接続されます。
後で触れますがUSBメモリを接続するのにちょうど良いですね。

さらにさらにI2S-Codecも搭載されています！！！STM32F4でも搭載されていましたが
同じように"いつもの"が出来そうです。SAIインターフェースで接続されています。

そしてこれだけそろってお値段はなななんと$50ですよ奥さん！！(DigiKeyより)
こんな時代になったのですね…2009年のころは全く考えられなかったのですが…
しみじみ

しみじみするのはその辺にして早速いじってみました。
STLink側のUSB-miniBケーブルをPCと接続するとドライバを読み込んだ後STM32F7
側にも電源が供給されてプログラムが走り出します。
すぐにナウいロゴが出てきます。

すぐにメニュー画面になり、タップでいくつかのアプリケーションが選べるように
なっています。しかもCPUの負荷率もリアルタイムで表示されます。

200MHzで動いているので結構発熱します。F4シリーズと違ってΔTは10度以上あると
思ってください。それでも他の品種の同周波数のものと比べると低いほうですが。

静電容量式タッチパネル(CTP)なので物理で押してもだめです。指で操作しましょ。

先ずは"audioplayer"です。USBメモリに仕込んだwaveファイルを読み込んで再生し
ます。デモはHS側のUSB-OTGだけしか反応しませんのでご注意ください。USB-FSや
SDカードは未実装のようです。

再生してる所です。音量調節が狭くて音量を上げようとすると指がメニューに
あたってしまって最初の画面に戻ってしまいがちです。どうでもいいですが。

infoメニューでは現在の動作周波数やファームウエアのバージョンが表示されます、
ファームウェアとやらは勿論STM32CubeF7の事です…。
どうでもいいことですがたまに異様にCPU負荷が100%になって動作が異様にもっさり
したり固まったりするのですが私の操作が早すぎるせいなのでしょうか？？？

さて、デモプログラムを触るのはこの辺にしてねむいさんのいつものの準備を、
GCCのコマンドラインビルドできる環境を固めて行こうと思います。OpenOCDはまだ
レビュー段階ですがSTM32F7フラッシュ書き込み用パッチが公開されています。

糞ややこしいのですがパッチはCortex-M7用とSTM32F7用の2種類か必要でした
http://openocd.zylin.com/#/c/2786/
http://openocd.zylin.com/#/c/2784/
http://openocd.zylin.com/#/c/2753/4
http://openocd.zylin.com/#/c/2753/5
2753は要注意です。#5のパッチだけあててもF7対応になりません！

まぁやり方さえわかればビルドはいつもどおりなのでらくちんです★
バイナリは既にSTM32F7対応に更新してあります♥
cfgファイル群も更新しましたのでどうぞ。

STLink/V2-1もファームがM11に更新されていますので事前にアップデートして
おきましょう。STLink-Utilityも3.6に更新しておいてください。
20150714追:
M11に更新しないとOpenOCDで書き込むことができませんのでご注意！！！！

まだF7向けのGCCプロジェクトはこさえていないので記事を書く2日前に1.0.1に
アップデートしたばっかリのCubeF7のF7Discovery向けのデモプログラムの
ビルド済みhexファイルをOpenOCDから焼いてみます。その前にSTLink-Utilityで
接続し、デモプログラムのhexを読み込ませてみました

このhexファイル、19MByteも有るのですがフォントと画像データがあるQSPIの領域も
含まれているようです(0x90000000以降の領域)。まだ外付けのQSPIの読み書きには
対応していないので内蔵フラッシュしか書き込むことができませんがQSPIに仕込んで
あるデータはシカトして内蔵フラッシュのだけ無理やり更新できます。

STLink-UtilityのExternalFlashLoaderにF7Discovery向けのQSPIドライバ無いんです
けぉ･･･###それはおいといてOpenOCDに話を移します！！！！

案の定QSPIの領域ではエラーが出ますが何とかフラッシュは書き込みできてます。

無事ファームウエアをV1.0.1に変更することができました。

そんなわけでSTM32F7をほんとに触りだけでしたが触れてみました。
これからいつものビルド環境に合わせたプロジェクト作りを進めて行きたいと思います。
F4の時にCubeF4向けにペリフェラルドライバの移植を試みましたが結局UARTまでしか
実装できなかったので今度こそ本気出します！！
(2年ぶり4度目)

STM32F4シリーズを使ってみる14 - FatFsとSDカード再考その3(SDIOでDMAした時の不具合対策編) -

サブタイトルがどんどん長くなる･･･それはおいといて
前回の解説でまぐろ様と言う方より最初に4Byteの倍数以外の数のデータを
書き込んだ際に書いたデータがずれると言う不具合報告をいただきました。
結局原因はDMAする際にメモリアドレスがWORD(4バイト)のアライメントの境界に
そろっておらずずれた状態でDMAしていたことだったのですが、私自身も勘違い
したまま使っていたのでこの場で情報を整理して根本的にどう対処すれば
よいのかを記しておきます。
その前にどうでもいいですが"Alignment"はアラインメントでもアライメント
でも発音は正しいそうですが以後はアライメントで統一します。

●ズレる
たとえばファイル"mankoi.txt"を書き込みモードで開き、ヘッダとデータの塊を
f_sync()を挟んで書き込むコードを実行するとします。ここで"sakisan","gff"は
共に書き込む予定のバイト数を満たす十分な大きさをもち4バイトの境界に揃った
const charの配列のポインタとします。
またf_系の返り値のチェックは下では解説のために省略していますが
実コードでは付与しております。

f_open(&File[0], "mankoi.txt", FA_OPEN_ALWAYS | FA_WRITE);

f_write(&File[0], sakisan, 37, &s2);	/* 4の倍数でないバイト数 */

f_sync(&File[0]);

f_write(&File[0], gff, 4096, &s2);		/* マルチブロックで一気に書き込む予定 */

f_sync(&File[0]);

f_close(&File[0]);

期待される動作はsakisanで示された37バイトのデータを書き込んだ後gffで
示された4096バイトデータを書き込みファイルをクローズして無事終了
…のはずです。

SDIOでDMAを使用しないFIFOポーリングによる書き込みではちゃんと期待
される動作となります。しかしDMAを使用した場合最初のブロック(=512バイト)を
書き込んだ次のブロックの最初の書き込もうとするデータが1～3バイトずれて
しまいます。
このずれ方は転送予定だった最初のバイト数を4で割った余りと等しくなります。

STM32F4のマニュアルではDMAをする際のメモリアドレスの境界はFIFOバースト
長さ/INC値に合わせよと明記があります。STのサンプルでは送り元メモリ及び
送り先ペリフェラルはそれぞれ4バイトとしていたのでそれに倣って4バイトの
境界にメモリアドレスを合わせる必要があります(私のサンプルのSPI版の
場合はDMAの転送サイズはByteのため今回の影響はありません)。
ねむいさんはてっきりFatFsのデータのやり取りに使用する為に静的に確保した
バッファの配列を4バイトアライメントにしておけばそれで問題なかろう･･･
という致命的な勘違いをしておりました。

上記f_writeからはSDIOドライバと結合したdisk_writeが呼ばれますがこのとき
渡される内部バッファのポインタアドレスが4バイトの境界にそろっているとは
限りません。しかしながらdisk_write内のSD_WriteBlock及びSD_WriteMultiBlock
はDMAで転送する際は送付元メモリアドレスが4バイト境界(4で割り切れる数)に
なっている必要があります。ズレる状況で実際にどういうことが起こっているか
デバッガで追いかけてみましょう。

最初にシングルブロック転送で37バイト分書き込む時です。最初なので
当然メモリのアドレスも4バイトの境界にいます。

f_sync()の処理を終えてから次の4096バイト(実際は最初の512-37バイトを
引かれた値)をマルチブロック転送で書き込んだ時です。ご覧のように渡された
ポインタbuffのアドレス値が4で割り切れない数になってます。

当然のことながらmankoi.txtに書き込まれた文字列はズレます。

●対策
前回も述べましたがSTM32F2/F4は対策はとても容易でDMAの設定でメモリ側の
データサイズを1バイトの"Byte",FIFOバッファのメモリ側バースト長をSingleにすれば
1バイトごとの転送となり効率は落ちますがアライメントは関係なくなり問題は
解決します。

しかしSTM32F1系はSDIOはF2/F4系と違いAHBバスにぶら下がっていてなおかつ
AHBバスに直接ぶら下がったペリフェラルへのDMA転送は常にWORD(4Byte)単位
でなければならないという制約があり、F2/F4みたいな技が不可能です。
したがって下記に示す根本的な対策を行う必要性があります。

/* If unligned memory address situation,copy dmabuf to aligned by 4-Byte. */

/* SECTOR_SIZE = 512 (Byte) */

uint8_t dmabuf[SECTOR_SIZE] __attribute__ ((aligned (4)));

if((uint32_t)buff & 3)	/* Check 4-Byte Alignment */

{	/* Unaligned Buffer Address Case (Slower) */

	for (unsigned int secNum = 0; secNum < count && Status == SD_OK; secNum++){

		/* Use optimized memcpy for ARMv7-M, std memcpy was override by optimized one. */

		memcpy(dmabuf, buff+SECTOR_SIZE*secNum, SECTOR_SIZE);

		Status = SD_WriteBlock(dmabuf,

					  (uint64_t)(sector+secNum)*SECTOR_SIZE, 

					  (uint8_t)SECTOR_SIZE);

	}

} else {

	/* Aligned Buffer Address Case (Faster) */

	if(count==1){

		Status = SD_WriteBlock((uint8_t*)(buff), 

							  ((uint64_t)(sector)*SECTOR_SIZE),

							  SECTOR_SIZE);

	}

	else{

		Status = SD_WriteMultiBlocks((uint8_t*)(buff), 

									((uint64_t)(sector)*SECTOR_SIZE),

									SECTOR_SIZE

									,count);

	}

}

f_writeから渡されるbuffのアドレスの下位2ビットを比較して4Byteの境界に
ない物は整列された配列にコピーし直しシングルブロック転送を行うものです。
このアライメント補正したシングルブロック転送を行っていくとブロックサイズ
の境界(512Byte=128*4Byte)に揃い改めて高速なマルチブロック転送が可能と
なるので効率をなるべく落とさないような仕組みにしてあります。
勿論Readの際もﾁﾏﾁﾏ読み込みの際は同じような対策でズレを防止できます。

これの対策の元ネタはSTマイクロのフォーラムにあったやり取りです。
かれこれ3年以上経ってましたがねむいさんずっと勘違いしてたせいでこの
対策の意味が今更分かったorzそれにしてもClive1...貴方は何者なんだ…！

そしてChaNさんのページでもズレるから各自対策してね★ってしっかりと
注意書きがしてありました…orz見落としてただけジャン私orz

で、でも現行のSTM32F4Cubeとかのサンプルって1.4.0になってもアライメントの事ガン無視
ですし、ま、まぁこれに気づく人のほうがたぶんす、少ないですってﾊﾊ♥

･･･と言うわけでおきぱにあるSTM32F2/F4のサンプルは上記の根本対策を
講じております。好みに合わせてDMAの設定だけで逃げるお手軽対策も
できるようにしてあります。

またF1系,LPC1788/LPC4088のFatFsでも根本対策を施していますので
ご利用ください。ちなみにLPC2388に関してはChaNさん謹製のMCIドライバを
使用していますがちゃんとアラインド/アンアラインド化をしているため
もともと大丈夫です。

●そういえばFatFsの設定で･･･
FatFsの設定のためのffconf.hには_WORD_ACCESSなる定義があり、1にすると
ポインタの参照が32bit単位になり高速化ができる･･･はずですが32bitマイコンの
場合はCPUコアのアライメントの制約で1にすると上で述べたDMAみたく
CPU例外が起こってしまいます。
しかしながらCortex-M3/M4ではアンアラインドなアクセスが一部の命令で可能なため
1にする事ができます。"一部"なのでChaNさんは0を推奨しています。

ねむいさんが試したところではff.cではまだDWORD(8Byte)やそれ以上の
マルチバイトにアクセスする状況が発生していないのでアンアラインド転送の
制約に引っかかるSTRD,STM,LDRD,LDMの命令は現状のコンパイラではff.c内
では一切使用されず例外も発生しないので1で問題はないと言い切れます！
もちろんアンアラインドなアクセスではペナルティが発生してその時の速度は
低下しますがそれでも全体的にはバイトアクセスの時より速度もコードサイズ
でも優れているので積極的に１にしていきましょう！
さらにGCCのコンパイラ・オプションで”-munaligned-access"を有効にすると
アンアラインドアクセスを承知でコードの効率化が図れます。

20160620追：
FatFs0.12ではこのオプションは廃止されました。
コンパイル時に必ずアラインド状態のアクセスになるようコードが変わっています。
20160620追：

ちなみにアンアラインドなアクセスが起こった事を知るための機能もあります。

SCB->CCR |= SCB_CCR_UNALIGN_TRP_Msk;

SCBのCCRレジスタにはアンアラインドなアクセスの発生をトラップするビットが
あります。これを立てるとアンアラインド転送が起こった時にHardFaultに
させることができます。

一方Cortex-M0,M0+ではコアのアーキテクチャが違うのでアンアラインドな
データアクセスは許されず、問答無用でHardFaultになりますので常にバイト
アクセスかもしくはアライメントがそろった転送をしましょう。

そういうわけで不具合もしっかりと修正されたので今度こそ実際に
パフォーマンス比較をやっていきたいと思います！

STM32F4シリーズを使ってみる13 - FatFsとSDカード再考その2(SDIO基本編) -

※今回の記事の内容は時勢/判明した事実に即して逐次変更していきます。
　この記事ではDMAでよくある間違いをやらかしています。
　次回の記事も必ず参照してください！

STM32にはSDIOというSD/MMCカードと高速でデータをやり取りができる機能が
あります。今回は前回触れたハードウエアの接続の内容を踏まえ、ソフト的な話を
展開していきます。さらにSTM32F4に限らず他品種のSDIO相当の機能を
使用できるマイコンについても考察を重ねていきます。

●STM32のSDIOでFatFsる
SDカードとSDIOは簡易な解説がSDアソシエーションのサイトで
公開されております。この"簡易な解説"が曲者で本当に知りたい細かい部分の事柄を
知るためには会費を払って会員になる必要があります。そんなわけで
ねむいさんみたいな金も地位も技術もないホビイストにとってはMCUベンダから
提供されたSDIOモジュールアクセス用のコードさんぷるをありがたく
頂いて自分のプロジェクトに適した形に組み込んでいくことになります。

話は少しFatFsのほうに戻りますが、FatFsとMCU固有コードを結合させる
ためにはFatFs自身が必要とする下部レイヤと呼ばれる関数群をこさえて
やる必要があります。
このうちdisk_ioctl(),fat_gettime(),disk_write()はFatFsのオプション設定で
無効状態にできるのでdisk_initialize(),disk_status(),disk_read()の3つの関数は
最低限作りこんであげないといけません。

かつてSTマイクロより提供されていたSTM32F4xx_DSP_StdPeriph_Libには
FatFsと親和性が良いSDIOのSD/MMCカードW/Rサンプルライブラリがあり、
私はこれをベースにSDIOドライバを実装していきました(現在配布されている
STM32F4Cube通称"HALライブラリ"のFatFsドライバもこのサンプルライブラリと
ほぼ同じ実装です)。
私のSDIOドライバはリソース使用状況に応じてDMAとFIFOのポーリングと
両方使い分けることが可能です。以下に実際に私のSDIOドライバで使用している
要点、特に初期化時のSDIO_CK(=実際にSDカードに掛かるクロック)の設定を
重点的にかいつまんで解説していきます。
以下おきぱのSTM32F4向けのFatFs実装例内にあるsdio_stm32f4.c,sdio_stm32f4.h
を見ながら読み進んでください。



SD_Error SD_Init(void)

{

	GPIO_InitTypeDef  GPIO_InitStructure;

	NVIC_InitTypeDef  NVIC_InitStructure;

	SD_Error errorstatus = SD_OK;



	/* SDIO Peripheral Low Level Init */

	/* GPIOC and GPIOD Periph clock enable */

	RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOC | RCC_AHB1Periph_GPIOD | SD_DETECT_GPIO_CLK, ENABLE);



	GPIO_PinAFConfig(GPIOC, GPIO_PinSource8, GPIO_AF_SDIO);

	GPIO_PinAFConfig(GPIOC, GPIO_PinSource9, GPIO_AF_SDIO);

	GPIO_PinAFConfig(GPIOC, GPIO_PinSource10, GPIO_AF_SDIO);

	GPIO_PinAFConfig(GPIOC, GPIO_PinSource11, GPIO_AF_SDIO);

	GPIO_PinAFConfig(GPIOC, GPIO_PinSource12, GPIO_AF_SDIO);

	GPIO_PinAFConfig(GPIOD, GPIO_PinSource2, GPIO_AF_SDIO);



	/* Configure PC.08, PC.09, PC.10, PC.11 pins: D0, D1, D2, D3 pins */

	GPIO_InitStructure.GPIO_Pin = GPIO_Pin_8 | GPIO_Pin_9 | GPIO_Pin_10 | GPIO_Pin_11;

	GPIO_InitStructure.GPIO_Speed = GPIO_Speed_100MHz;

	GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;

	GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;

	GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_UP;

	GPIO_Init(GPIOC, &GPIO_InitStructure);



	/* Configure PD.02 CMD line */

	GPIO_InitStructure.GPIO_Pin = GPIO_Pin_2;

	GPIO_Init(GPIOD, &GPIO_InitStructure);



	/* Configure PC.12 pin: CLK pin */

	GPIO_InitStructure.GPIO_Pin = GPIO_Pin_12;

	GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;

	GPIO_Init(GPIOC, &GPIO_InitStructure);



	/*!< Configure SD_SPI_DETECT_PIN pin: SD Card detect pin */

#ifdef SDIO_INS_DETECT

	GPIO_InitStructure.GPIO_Pin = SD_DETECT_PIN;

	GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN;

	GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_UP;

	GPIO_Init(SD_DETECT_GPIO_PORT, &GPIO_InitStructure);

#endif



	/*

	 *NVIC_PriorityGroup_0: 0 Pre-emption priorities, 16 Sub-priorities

	 *NVIC_PriorityGroup_1: 2 Pre-emption priorities, 8 Sub-priorities

	 *NVIC_PriorityGroup_2: 4 Pre-emption priorities, 4 Sub-priorities

	 *NVIC_PriorityGroup_3: 8 Pre-emption priorities, 2 Sub-priorities

	 *NVIC_PriorityGroup_4: 16 Pre-emption priorities, 0 Sub-priorities

	 */

	NVIC_PriorityGroupConfig(NVIC_PriorityGroup_1);



	/* Enable the SDIO Interrupt */

	NVIC_InitStructure.NVIC_IRQChannel = SDIO_IRQn;

	NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0;

	NVIC_InitStructure.NVIC_IRQChannelSubPriority = 1;

	NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;

	NVIC_Init(&NVIC_InitStructure);

	NVIC_InitStructure.NVIC_IRQChannel = SD_SDIO_DMA_IRQn;

	NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0;

	NVIC_InitStructure.NVIC_IRQChannelSubPriority = 2;

	NVIC_Init(&NVIC_InitStructure);  



	/* Enable the SDIO APB2 Clock */

	RCC_APB2PeriphClockCmd(RCC_APB2Periph_SDIO, ENABLE);



#if defined(SD_DMA_MODE)

	/* Enable the DMA Clock */

	RCC_AHB1PeriphClockCmd(SD_SDIO_DMA_CLK, ENABLE);

	/* Initialize SDDMA Structure */

	SDDMA_InitStructure.DMA_Channel 			= SD_SDIO_DMA_CHANNEL;

	SDDMA_InitStructure.DMA_PeripheralBaseAddr 	= (uint32_t)SDIO_FIFO_ADDRESS;

	SDDMA_InitStructure.DMA_Memory0BaseAddr 	= 0;

	SDDMA_InitStructure.DMA_DIR 				= DMA_DIR_PeripheralToMemory;

	SDDMA_InitStructure.DMA_BufferSize 			= 0;

	SDDMA_InitStructure.DMA_PeripheralInc 		= DMA_PeripheralInc_Disable;

	SDDMA_InitStructure.DMA_MemoryInc 			= DMA_MemoryInc_Enable;

	SDDMA_InitStructure.DMA_PeripheralDataSize 	= DMA_PeripheralDataSize_Word;

	SDDMA_InitStructure.DMA_MemoryDataSize 		= DMA_MemoryDataSize_Word;

	SDDMA_InitStructure.DMA_Mode 				= DMA_Mode_Normal;

	SDDMA_InitStructure.DMA_Priority 			= DMA_Priority_VeryHigh;

	SDDMA_InitStructure.DMA_FIFOMode 			= DMA_FIFOMode_Enable;

	SDDMA_InitStructure.DMA_FIFOThreshold 		= DMA_FIFOThreshold_Full;

	SDDMA_InitStructure.DMA_MemoryBurst 		= DMA_MemoryBurst_INC4;

	SDDMA_InitStructure.DMA_PeripheralBurst 	= DMA_PeripheralBurst_INC4;

#endif

	/* End of LowLevel Init */





	SDIO_DeInit();



	errorstatus = SD_PowerON();



	if (errorstatus != SD_OK)

	{

		/*!< CMD Response TimeOut (wait for CMDSENT flag) */

		return(errorstatus);

	}



	errorstatus = SD_InitializeCards();



	if (errorstatus != SD_OK)

	{

		/*!< CMD Response TimeOut (wait for CMDSENT flag) */

		return(errorstatus);

	}



	/*!< Configure the SDIO peripheral */

	/*!< SDIOCLK = HCLK, SDIO_CK = HCLK/(2 + SDIO_TRANSFER_CLK_DIV) */

	/*!< on STM32F4xx devices, SDIOCLK is fixed to 48MHz */  

	SDIO_InitStructure.SDIO_ClockDiv = SDIO_TRANSFER_CLK_DIV; 

	SDIO_InitStructure.SDIO_ClockEdge = SDIO_ClockEdge_Rising;

	SDIO_InitStructure.SDIO_ClockBypass = SDIO_ClockBypass_Disable;

	SDIO_InitStructure.SDIO_ClockPowerSave = SDIO_ClockPowerSave_Disable;

	SDIO_InitStructure.SDIO_BusWide = SDIO_BusWide_1b;

	SDIO_InitStructure.SDIO_HardwareFlowControl = SDIO_HardwareFlowControl_Disable;

	SDIO_Init(&SDIO_InitStructure);



	/*----------------- Read CSD/CID MSD registers ------------------*/

	if (errorstatus == SD_OK)

	{

		errorstatus = SD_GetCardInfo(&SDCardInfo);

	}



	/*----------------- Select Card --------------------------------*/

	if (errorstatus == SD_OK)

	{

		errorstatus = SD_SelectDeselect((uint32_t) (SDCardInfo.RCA << 16));

	}



	/*----------------- Enable SDC 4BitMode --------------------------------*/

	if (errorstatus == SD_OK)

	{

		errorstatus = SD_EnableWideBusOperation(SDIO_BusWide_4b);

	}



#ifdef SD_HS_MODE

 	/*----------------- Enable HighSpeedMode --------------------------------*/

	#warning "Enable SD High Speed mode!"

	if (errorstatus == SD_OK)

	{

		errorstatus = SD_HighSpeed();

	}

#endif



	return(errorstatus);

}

最初の要となるSD_Init内の関数です。DMAを使用するモードでもFIFOポーリング
でも割り込みは使用します。CLK以外のGPIOは一応プルアップしていますが
これに頼らず必ず外付け抵抗でプルアップをしてください(前回参照)。
DMAモードの場合はここでDMA用の構造体の設定も完了させておきます。
構造体変数はグローバル化してDMAをキックする際に最低限の変数の設定に
とどめるようにして少しでもオーバーヘッドを減らすようにしております。

また、構造体変数の保持用にCCM領域を積極的に使用するようにして速度向上に
努めています。ここで注意点ですがCCM領域に置いた変数はdata領域のように
スタートアップで初期化しておくようにはしていないのでプログラム内で
明示的に初期化するようにしましょう。

その後はSTマイクロ提供のサンプルのとおりにSDカード初期化のための関数を
実行していきます。デフォルトでは先ずSDIOCLKから作られるSDIO_CKを
400kHz以下、データ幅は1-bitモードでカードの初期化を実行し、成功が
返ってきたらクロックをSDNomalModeがサポートする上限付近まで上げて
データ幅も4-bitに拡張するコマンドを発行して高速なデータのやり取りの
準備を行います。

現在流通しているSDカードはほぼすべての品種でSDNomalModeの最高値25MHzを
サポートしていますので上げる場合はその周波数近辺まで一気にあげられます。
このときのクロックですが、STM32F4ではUSB,RNG,そしてSDIO用の固定値
クロック生成用のPLLが存在して柔軟に対応可能となっています。
F4系で一般的な168MHz動作の時はUSBで必須の48MHzが生成され、同じくこれは
SDIOでも都合よい値となっています。

そしてSDNomalModeの時は規格上SDIO_CKの値は25MHzが上限値なので上記の
コードのようにSDIOモジュール内にあるクロックディバイダを通して48MHzを
2分周した24MHzを生成するような設定にします。過去に私はこの時点で
クロックディバイダを通さず48MHzをモロに引き出して無理やり動作させて
おりましたがこのやり方は完全に誤りで本当はSDカードの規格に存在する
SDHighSpeedModeに切り替えたうえでクロックを48MHzに上げてやる必要が
あることを知りました。



SD_Error SD_HighSpeed (void)

{

	SD_Error errorstatus = SD_OK;

	uint32_t scr[2] = {0, 0};

	uint32_t SD_SPEC = 0 ;

	uint8_t hs[64] = {0} ;

	uint32_t  count = 0, *tempbuff = (uint32_t *)hs;

	TransferError = SD_OK;

	TransferEnd = 0;

	StopCondition = 0;



	SDIO->DCTRL = 0x0;



	/*!< Get SCR Register */

	errorstatus = FindSCR(RCA, scr);



	if (errorstatus != SD_OK)

	{

	return(errorstatus);

	}



	/* Test the Version supported by the card*/ 

	SD_SPEC = (scr[1]  & 0x01000000)||(scr[1]  & 0x02000000);



	if (SD_SPEC != SD_ALLZERO)

	{

		/* Set Block Size for Card */

		SDIO_CmdInitStructure.SDIO_Argument = (uint32_t)64;

		SDIO_CmdInitStructure.SDIO_CmdIndex = SD_CMD_SET_BLOCKLEN;

		SDIO_CmdInitStructure.SDIO_Response = SDIO_Response_Short;

		SDIO_CmdInitStructure.SDIO_Wait = SDIO_Wait_No;

		SDIO_CmdInitStructure.SDIO_CPSM = SDIO_CPSM_Enable;

		SDIO_SendCommand(&SDIO_CmdInitStructure);

		errorstatus = CmdResp1Error(SD_CMD_SET_BLOCKLEN);

		if (errorstatus != SD_OK)

		{

			return(errorstatus);

		}

		SDIO_DataInitStructure.SDIO_DataTimeOut = SD_DATATIMEOUT;

		SDIO_DataInitStructure.SDIO_DataLength = 64;

		SDIO_DataInitStructure.SDIO_DataBlockSize = SDIO_DataBlockSize_64b ;

		SDIO_DataInitStructure.SDIO_TransferDir = SDIO_TransferDir_ToSDIO;

		SDIO_DataInitStructure.SDIO_TransferMode = SDIO_TransferMode_Block;

		SDIO_DataInitStructure.SDIO_DPSM = SDIO_DPSM_Enable;

		SDIO_DataConfig(&SDIO_DataInitStructure);



		/*!< Send CMD6 switch mode */

		SDIO_CmdInitStructure.SDIO_Argument = 0x80FFFF01;

		SDIO_CmdInitStructure.SDIO_CmdIndex = SD_CMD_HS_SWITCH;

		SDIO_CmdInitStructure.SDIO_Response = SDIO_Response_Short;

		SDIO_CmdInitStructure.SDIO_Wait = SDIO_Wait_No;

		SDIO_CmdInitStructure.SDIO_CPSM = SDIO_CPSM_Enable;

		SDIO_SendCommand(&SDIO_CmdInitStructure); 

		errorstatus = CmdResp1Error(SD_CMD_HS_SWITCH);



		if (errorstatus != SD_OK)

		{

			return(errorstatus);

		}

		while (!(SDIO->STA &(SDIO_FLAG_RXOVERR | SDIO_FLAG_DCRCFAIL | SDIO_FLAG_DTIMEOUT | SDIO_FLAG_DBCKEND | SDIO_FLAG_STBITERR)))

		{

			if (SDIO_GetFlagStatus(SDIO_FLAG_RXFIFOHF) != RESET)

			{

				for (count = 0; count < 8; count++)

				{

					*(tempbuff + count) = SDIO_ReadData();

				}

				tempbuff += 8;

			}	

		}



		if (SDIO_GetFlagStatus(SDIO_FLAG_DTIMEOUT) != RESET)

		{

			SDIO_ClearFlag(SDIO_FLAG_DTIMEOUT);

			errorstatus = SD_DATA_TIMEOUT;

			return(errorstatus);

		}

		else if (SDIO_GetFlagStatus(SDIO_FLAG_DCRCFAIL) != RESET)

		{

			SDIO_ClearFlag(SDIO_FLAG_DCRCFAIL);

			errorstatus = SD_DATA_CRC_FAIL;

			return(errorstatus);

		}

		else if (SDIO_GetFlagStatus(SDIO_FLAG_RXOVERR) != RESET)

		{

			SDIO_ClearFlag(SDIO_FLAG_RXOVERR);

			errorstatus = SD_RX_OVERRUN;

			return(errorstatus);

		}

		else if (SDIO_GetFlagStatus(SDIO_FLAG_STBITERR) != RESET)

		{

			SDIO_ClearFlag(SDIO_FLAG_STBITERR);

			errorstatus = SD_START_BIT_ERR;

			return(errorstatus);

		}

		count = SD_DATATIMEOUT;

		while ((SDIO_GetFlagStatus(SDIO_FLAG_RXDAVL) != RESET) && (count > 0))

		{

			*tempbuff = SDIO_ReadData();

			tempbuff++;

			count--;

		}



		/*!< Clear all the static flags */

		SDIO_ClearFlag(SDIO_STATIC_FLAGS);



		/* Test if the switch mode HS is ok */

		if ((hs[13]& 0x2)==0x2)

		{

			/*!< Configure the SDIO peripheral */

			SDIO_InitStructure.SDIO_ClockDiv = SDIO_TRANSFER_CLK_DIV; 

		#if defined (STM32F40_41xxx)

			SDIO_InitStructure.SDIO_ClockEdge = SDIO_ClockEdge_Falling;		/* This is a baddest work around for STM32F40x and STM32F41x */

		#else

			SDIO_InitStructure.SDIO_ClockEdge = SDIO_ClockEdge_Rising;

		#endif

			SDIO_InitStructure.SDIO_ClockBypass = SDIO_ClockBypass_Enable;	/* Set Direct Clock(48MHz) */

			SDIO_InitStructure.SDIO_ClockPowerSave = SDIO_ClockPowerSave_Disable;

			SDIO_InitStructure.SDIO_BusWide = SDIO_BusWide_4b;

			SDIO_InitStructure.SDIO_HardwareFlowControl = SDIO_HardwareFlowControl_Disable;

			SDIO_Init(&SDIO_InitStructure);

			errorstatus=SD_OK;	/* Enter SDHighSpeedMode */

		}

		else

		{

			errorstatus=SD_OK;	/* Still SDNomalMode */

			/*errorstatus=SD_UNSUPPORTED_FEATURE ;*/

		}  

	}

	return(errorstatus);

}

STマイクロのサンプルにはどこからも参照されていないSD_HighSpeed()なる
関数がとあるバージョンから唐突に追加されてフルの規格を入手しないと
わからなかったSDHighSpeedModeへの切り替え方が判明しております。
そんなわけでこの関数を利用して正規にSDIOのクロックを48MHzでドライブ
したい　と　こ　ろ　で　す　が　！

残念ながらSTM32F405/7系のSDIOモジュールには上記のエラッタが存在し、
上記の関数を実行してもハードウエア的に48MHzで安定動作せしめることは
できません。

実際にRev.AのSTM32F407が乗った紅牛板で実験してみたのですがクロック
ディバイダを無効にして48MHz直結の場合は動作しないカードが殆どで動作する
カードは極めて限定的なものでした。しかもreadはかろうじて成功するものの
writeは殆ど失敗してディレクトリまで破壊されることが判明したので一時は
お蔵入りにしていました(このエラッタが明記されたのは2012年の秋以降で、
2011年当時はまだ判明していませんでした)。

てわけでワークアラウンドを講じるとSTM32F405/7系では動作が保証された
クロック上限値は37.5MHzとなり、しかもPLLの分周値を変えてこの周波数に
設定すると今度はUSBで必要な48MHzが作られなくなってしまうので利用が
限定的になってしまいます。
したがって潰しが効くようにコーディングするとSDNomalModeのまま、
SDIO_CKも24MHzのままで使用するべしとなってしまうのです。一応STM32F2/F4
にはGPIOの高速動作を安定化させる"compensation cell"なるものがあり
(こちらのテクニカルノートの75pに解説があります)、有効にしてみたのですが
改善はありませんでした。

一方STM32F42x/43x系では動作周波数が180MHzまで拡張されたせいかGPIOの
絶対的速度も強化され、168MHz動作時クロックバイパスをEnableにして
48MHzのクロックで動かしてもRead,Writeとも安定して動作可能です。
180MHzの時はSDIO_CKは52MHzまで増加しますがこの状態でも全く問題は
ありません。そんなわけで後で紹介する裏ワザを使わずどうしても48MHzの
SDHighSpeedModeで動かしたい場合は405/407系から42x/43x系にお引越し
する必要があります。
ほぼピン互換なのでボードの改造は不要で単純な交換でパワーアップできます！

…と言いたい　と　こ　ろ　で　す　が(こんなんばっかだ)
このSTM32F42x/43x系も1MB以上のフラッシュ領域を使っている時PA12の
電圧レベルが変化すると動作がおかしくなるという意味不明かつかなり
致命的な不具合が存在しますorz。このやばい不具合、rev3でFMCとともに
ようやく修正されたようですがPA12はUSBのD+に相当するためエラッタ
持ちのチップはUSB機能を殺すかもしくはフラッシュの1MB以上の領域を
使用しないという2択を迫られることになりますorz



			/*!< Configure the SDIO peripheral */

			SDIO_InitStructure.SDIO_ClockDiv = SDIO_TRANSFER_CLK_DIV; 

		#if defined (STM32F40_41xxx)

			SDIO_InitStructure.SDIO_ClockEdge = SDIO_ClockEdge_Falling;		/* This is a baddest work around for STM32F40x and STM32F41x */

		#else

			SDIO_InitStructure.SDIO_ClockEdge = SDIO_ClockEdge_Rising;

		#endif

			SDIO_InitStructure.SDIO_ClockBypass = SDIO_ClockBypass_Enable;	/* Set Direct Clock(48MHz) */

			SDIO_InitStructure.SDIO_ClockPowerSave = SDIO_ClockPowerSave_Disable;

			SDIO_InitStructure.SDIO_BusWide = SDIO_BusWide_4b;

			SDIO_InitStructure.SDIO_HardwareFlowControl = SDIO_HardwareFlowControl_Disable;

			SDIO_Init(&SDIO_InitStructure);

			errorstatus=SD_OK;	/* Enter SDHighSpeedMode */

すみません話がそれましたがSTM32F405/407系でどうしても48MHzでSDIOを
安定して使用したい場合の裏技があります。そもそも安定しない理由がI/Oの
変化速度が規定に追い付けずデータが1ビットシフトして取り込まれている
せいなのです。ここでSDIO_CKのクロック送出エッジをNegativeに変えることに
よってクロックは遅れて送出されるがデータの取り込みタイミングは変わらない
状態となるためビットシフトせずうまい具合に取り込んでくれるようになります。
これはクロックバイパスEnable時の直結でも有効(実際はディバイダを噛まさ
ないでもSDIOCLKがそのまま出ているのではなくゲーティングされてSDIO_CKが
生成されている事を示している)で安定して読み書きができるようになります。

この送出エッジをNegativeにすることはデータの破損を招く事になるとして
errataとして設定が禁じられています。ですが48MHz動作だとこの構成の方が
都合がよくなります。おきぱにあるSTM32F4のSDIOドライバは405/407系向け
限定でSDHighSpeedModeを使う際は敢えてこの技を行っています。
もちろん禁を破った動かし方ですので物好きな人だけ試してみてください。



DRESULT disk_read(uint8_t drv,uint8_t *buff,uint32_t sector,unsigned int count)

{

	switch (drv) 

	{

		case SDIO_DRIVE:

		{     

			Status = SD_OK;



			if(count==1){

				Status = SD_ReadBlock((uint8_t*)(buff), 

									  ((uint64_t)(sector)*SECTOR_SIZE),

									  SECTOR_SIZE);

			}

			else{

				Status = SD_ReadMultiBlocks((uint8_t*)(buff), 

											((uint64_t)(sector)*SECTOR_SIZE),

											SECTOR_SIZE

											,count);

			}



			if (Status == SD_OK)	return RES_OK;

			else					return RES_ERROR;

		}

	}

	return RES_PARERR;

}

だらだらとクロック設定の話ばっかり続けてしまいましたがdisk_read()は
かなり単純明快です。SD_ReadBlock()及びSD_ReadMultiBlock()をセクタ数に
応じて呼び出すだけです。SD_ReadMultiBlock()単体だけでも動作には問題
ないですがセクタ数1の時はオーバーヘッドの方が大きくなるので分けた方が
いいです。



DRESULT disk_write(uint8_t drv,const uint8_t *buff,uint32_t sector,unsigned int count)

{

	switch (drv) 

	{

		case SDIO_DRIVE:

		{     

			Status = SD_OK;



			if(count==1){

				Status = SD_WriteBlock((uint8_t*)(buff), 

									  ((uint64_t)(sector)*SECTOR_SIZE),

									  SECTOR_SIZE);

			}

			else{

				Status = SD_WriteMultiBlocks((uint8_t*)(buff), 

											((uint64_t)(sector)*SECTOR_SIZE),

											SECTOR_SIZE

											,count);

			}



			if (Status == SD_OK)	return RES_OK;

			else					return RES_ERROR;

		}

	}

	return RES_PARERR;

}

ちなみにWriteの時も同じような感じで上記のようになります。



SD_Error SD_ReadBlock(uint8_t *readbuff, uint64_t ReadAddr, uint16_t BlockSize)

{

	SD_Error errorstatus = SD_OK;

#if defined (SD_POLLING_MODE)

	uint32_t count = 0, *tempbuff = (uint32_t *)readbuff;

#endif



	TransferError = SD_OK;

	TransferEnd = 0;

	StopCondition = 0;



	SDIO->DCTRL = 0x0;



#if defined(SD_DMA_MODE)

	/* Ready to DMA Before Any SDIO Commands! */

	SDIO_ITConfig(SDIO_IT_DCRCFAIL | SDIO_IT_DTIMEOUT | SDIO_IT_DATAEND | SDIO_IT_RXOVERR | SDIO_IT_STBITERR, ENABLE);

	SD_LowLevel_DMA_RxConfig((uint32_t *)readbuff, BlockSize);

	SDIO_DMACmd(ENABLE);

#endif



	if (CardType == SDIO_HIGH_CAPACITY_SD_CARD)

	{

		BlockSize = 512;

		ReadAddr /= 512;

	}



	/* Set Block Size for Card */ 

	SDIO_CmdInitStructure.SDIO_Argument = (uint32_t) BlockSize;

	SDIO_CmdInitStructure.SDIO_CmdIndex = SD_CMD_SET_BLOCKLEN;

	SDIO_CmdInitStructure.SDIO_Response = SDIO_Response_Short;

	SDIO_CmdInitStructure.SDIO_Wait = SDIO_Wait_No;

	SDIO_CmdInitStructure.SDIO_CPSM = SDIO_CPSM_Enable;

	SDIO_SendCommand(&SDIO_CmdInitStructure);



	errorstatus = CmdResp1Error(SD_CMD_SET_BLOCKLEN);



	if (SD_OK != errorstatus)

	{

		return(errorstatus);

	}



	SDIO_DataInitStructure.SDIO_DataTimeOut = SD_DATATIMEOUT;

	SDIO_DataInitStructure.SDIO_DataLength = BlockSize;

	SDIO_DataInitStructure.SDIO_DataBlockSize = (uint32_t) 9 << 4;

	SDIO_DataInitStructure.SDIO_TransferDir = SDIO_TransferDir_ToSDIO;

	SDIO_DataInitStructure.SDIO_TransferMode = SDIO_TransferMode_Block;

	SDIO_DataInitStructure.SDIO_DPSM = SDIO_DPSM_Enable;

	SDIO_DataConfig(&SDIO_DataInitStructure);



	/*!< Send CMD17 READ_SINGLE_BLOCK */

	SDIO_CmdInitStructure.SDIO_Argument = (uint32_t)ReadAddr;

	SDIO_CmdInitStructure.SDIO_CmdIndex = SD_CMD_READ_SINGLE_BLOCK;

	SDIO_CmdInitStructure.SDIO_Response = SDIO_Response_Short;

	SDIO_CmdInitStructure.SDIO_Wait = SDIO_Wait_No;

	SDIO_CmdInitStructure.SDIO_CPSM = SDIO_CPSM_Enable;

	SDIO_SendCommand(&SDIO_CmdInitStructure);



	errorstatus = CmdResp1Error(SD_CMD_READ_SINGLE_BLOCK);



	if (errorstatus != SD_OK)

	{

		return(errorstatus);

	}



#if defined (SD_POLLING_MODE)  

	/*!< In case of single block transfer, no need of stop transfer at all.*/

	/*!< Polling mode */

	while (!(SDIO->STA &(SDIO_FLAG_RXOVERR | SDIO_FLAG_DCRCFAIL | SDIO_FLAG_DTIMEOUT | SDIO_FLAG_DBCKEND | SDIO_FLAG_STBITERR)))

	{

		if (SDIO_GetFlagStatus(SDIO_FLAG_RXFIFOHF) != RESET)

		{

			for (count = 0; count < 8; count++)

			{

				*(tempbuff + count) = SDIO_ReadData();

			}

			tempbuff += 8;

		}

	}



	if (SDIO_GetFlagStatus(SDIO_FLAG_DTIMEOUT) != RESET)

	{

		SDIO_ClearFlag(SDIO_FLAG_DTIMEOUT);

		errorstatus = SD_DATA_TIMEOUT;

		return(errorstatus);

	}

	else if (SDIO_GetFlagStatus(SDIO_FLAG_DCRCFAIL) != RESET)

	{

		SDIO_ClearFlag(SDIO_FLAG_DCRCFAIL);

		errorstatus = SD_DATA_CRC_FAIL;

		return(errorstatus);

	}

	else if (SDIO_GetFlagStatus(SDIO_FLAG_RXOVERR) != RESET)

	{

		SDIO_ClearFlag(SDIO_FLAG_RXOVERR);

		errorstatus = SD_RX_OVERRUN;

		return(errorstatus);

	}

	else if (SDIO_GetFlagStatus(SDIO_FLAG_STBITERR) != RESET)

	{

		SDIO_ClearFlag(SDIO_FLAG_STBITERR);

		errorstatus = SD_START_BIT_ERR;

		return(errorstatus);

	}

	count = SD_DATATIMEOUT;

	while ((SDIO_GetFlagStatus(SDIO_FLAG_RXDAVL) != RESET) && (count > 0))

	{

		*tempbuff = SDIO_ReadData();

		tempbuff++;

		count--;

	}



	/*!< Clear all the static flags */

	SDIO_ClearFlag(SDIO_STATIC_FLAGS);



#elif defined(SD_DMA_MODE)

	/* Check if the Transfer is finished */

	Status = SD_WaitReadOperation();



	/* Wait until end of DMA transfer */

	while(SD_GetStatus() != SD_TRANSFER_OK);

	if (TransferError != SD_OK)

	{

		return(TransferError);

	}

#endif



	return(errorstatus);

}

SD_ReadBlock()及びSD_ReadMultiBlock()の関数は#defineの設定によってDMAか
ポーリングかを分けています。上記コードはSD_ReadBlock()の例ですがブロック/
マルチブロック転送にDMAを使う場合はDMAのキックを関数の冒頭、SDIOコマンド
送出前に行っておかないとラスト数バイトの転送漏れが生じてしまいますので必ず
ここで行ってください。
これはSTM32F1のSDIOモジュールのころに議論にあった問題でSTマイクロの
フォーラムで指摘され講じられた対策がその後のF2/F4の公式のドライバにも
反映されています。コメントでも述べましたがDMAを行う際は転送に使用する
メモリのアドレスを4で割り切れる数、つまり4バイトの境界に合わせてください。
GCCにおいては静的にメモリを確保する際に" __attribute__ ((aligned (4)))"の
修飾子を付けます。これをやっておかないと転送がコケて失敗します。
さらにブロック転送の際の転送するサイズを512バイト単位で行ってください。
これらをちゃんとやっておかないと(ry
ちなみにDMAを使用しない場合のFIFOのポーリング版でも転送速度の低下は
ほとんどありません。使用するリソース/ペリフェラルの優先度と相談して
DMAを使うか否かを決めてください。

また、Writeの際も同(ry



DSTATUS disk_status(uint8_t drv)

{

	switch (drv) 

	{

		case SDIO_DRIVE:

		{

			Status = SD_GetCardInfo(&SDCardInfo);



			if (Status != SD_OK)

				return STA_NOINIT;

			else

				return 0x00;

		}

	}

  

	return STA_NOINIT;

}

disk_status()の実装は一番シンプルです。
SD_GetCardInfo()を実行するだけです。

さて、LPC4088などの多品種のマイコンにも触れたかったのですがそろそろこの
ぶろぐの一記事の文字制限に引っかかりそうなので実際に動かしてみたところは
次回に紹介させていただきます
･･･なんか内容をまとめるどころかどんどん内容が発散していくorz

20150227追：
まぐろ様よりコメントにてSDIOでDMAで4の倍数のバイト数でない数をf_write()で
書き込んだ際にデータが１～３バイトずれて記録されるという不具合報告を
受けました。いただいた情報を元にこちらでも再現したのでさらに追ってみると
DMA初期化時のメモリ側インクリメント設定が4(バイト)となっていたためか4で
割り切れない数を書きこんだ際に次の転送でずれてしまうと最終的に推測しました。

というわけで対策ですが一番手っ取り早いのは細かいデータを記録していく際は
ポーリングモードで使用することです。どうしてもDMAしたい！場合について私も
もうちょっと調べてみました。するとChaN氏のページからも紹介されている
STM32F4のプロジェクトを専門に取り扱っているtilz0R氏のサイト中のコメントにてTassilo(田代･･！？)という方が同じ問題に
直面した際の解決策を提示してくれました。
私のプロジェクトでいうとsdio_stm32f4.cの291行目以降を以下のように変更します。
変更前：
SDDMA_InitStructure.DMA_PeripheralDataSize = DMA_PeripheralDataSize_Word;
SDDMA_InitStructure.DMA_MemoryDataSize = DMA_MemoryDataSize_Word;
SDDMA_InitStructure.DMA_Mode = DMA_Mode_Normal;
SDDMA_InitStructure.DMA_Priority = DMA_Priority_VeryHigh;
SDDMA_InitStructure.DMA_FIFOMode = DMA_FIFOMode_Enable;
SDDMA_InitStructure.DMA_FIFOThreshold = DMA_FIFOThreshold_Full;
SDDMA_InitStructure.DMA_MemoryBurst = DMA_MemoryBurst_INC4;
SDDMA_InitStructure.DMA_PeripheralBurst = DMA_PeripheralBurst_INC4;

変更後：
SDDMA_InitStructure.DMA_PeripheralDataSize = DMA_PeripheralDataSize_Word;
SDDMA_InitStructure.DMA_MemoryDataSize = DMA_MemoryDataSize_Byte;
SDDMA_InitStructure.DMA_Mode = DMA_Mode_Normal;
SDDMA_InitStructure.DMA_Priority = DMA_Priority_VeryHigh;
SDDMA_InitStructure.DMA_FIFOMode = DMA_FIFOMode_Enable;
SDDMA_InitStructure.DMA_FIFOThreshold = DMA_FIFOThreshold_HalfFull;
SDDMA_InitStructure.DMA_MemoryBurst = DMA_MemoryBurst_Single;
SDDMA_InitStructure.DMA_PeripheralBurst = DMA_PeripheralBurst_INC4;

上記の対策で不具合は発生しなくなることを確認しました。
太字の部分が変更点です。ねむいさんてっきりメモリアドレスもサイズも
32bit(=4Byte)であるべきと思い込んでいましたのでこんな罠があったの
知らなかったとはちょっと恥ずかしいですorz
しかしながらメモリアクセスを4Byteから1Byte区切りにしたことによる
転送速度の低下や何かしらの弊害あるかもなので次回にみっちり動作検証
して考察してみましょう。

また、STM32F4/F2だけではなく、STM32F1系のSDIOや、はたまた
LPC1788/4088等のMCIでも4バイト区切りでDMA転送を行うものは同じ
不具合がでますのでこっちも同じく検証してできれば対策まで待っていきたい
ところです。
20150409追：
全ての品種で効果がある根本対策を講じました!

STM32F4シリーズを使ってみる12 - FatFsとSDカード再考その1 -

このぶろぐを始めてから今に至るまで｢FatFsがうごきません＞＜｣という漠然としすぎて
すごく返答しづらい内容の質問をコンスタントに頂くのですがその9割が単なる配線ミス
でしたと言うオチだったのですが、残る1割にSTM32に潜んでいた未知のエラッタや
評価ボードの設計不備、および私の不備というｸﾘﾁｶﾙな問題が潜んでいたのが
分かっています。

STM32F4が世に出て早数年、いろんな情報やノウハウも出そろってきましたので
ここで基本に還ってF4中心にSTM32とSDカードを接続せしめる手法について今一度
考察していきたいと思います。まず予習としてChaN氏のFatFsとMMCの解説のページ
は必ず目を通しておいてください。

●STM32F4との接続・ハードウエア編
STM32F4とSDカードを実用的に繋げるためにはSTM32F4の周辺機能であるSPI
若しくはSDIOを用いて接続可能です。SPIはデータ線が1bitのシリアルですが
SDIOは4bit(8bitまで)可能だが8bitバスが利用できるカードは限られている)
まで可能でSDIOの方が高速にデータをやり取り可能です。
その代りSDIOの場合はその機能を最大限に引き出すため使用するI/Oポートは
固定化されていてSDIOを使うときは重複する他の周辺機能は使用不可能に
なります。一方でSPIは柔軟に割り当てが可能なためピン数がすくない品種で
速度をそれほど要しない場面でSDカードを使う際に重宝します。

おさらいですがSPIを使用するときはSD/MMCのSPI互換モード、SDIOを
使用する時はSD/MMCのネイティブモードとして接続します。
当ぶろぐではSDIOを使用するSD/MMCネイティブモードに特に焦点を
当てていきます。

私のおきぱのSTM32F4向けのサンプルではSTM32F4Discovery,STM32F429IDiscovery
ではSPIを、その他のボードに関してはSDIOをそれぞれ使用するようにしております。

↑STM32F4Discoveryとの接続(SPI)

↑紅牛/ECH_BOARD改造基板との接続(SDIO 4bitmode)

SDIO,SPIのいずれの場合においてもSDカード/MMCの電源投入後の初期化時は
オープンコレクタで動作することが前提のため、CLKを除く全てのデータ線は必ず
外付け抵抗でプルアップしてください。
プルアップ抵抗値についてはNexperia(元NxP)のアプリケーションノートAN10911に
極めて詳しい解説があります。私はそれらを吟味した上で10kohmよりちょっと上の
22kohmを常用しております。メーカ製評価ボードでは入手の容易なSDHCカードを想定
しているのか下限値の10kohmで吊っているのが非常に多かったです。また、今日びの
マイコンは内蔵プルアップを有する物が多いですがそれに絶対に頼ってはいけません。
面倒臭がらず必ず外付け抵抗を用いてプルアップしてください。

以前MCIを動作させるのに難儀していた中華LPC1788基板ですがEA互換のはずなのに
EA向けのFatFsのサンプルがそのままでは動かないもんで回路図をよく見たら…

SDIOの信号線にプルアップが無かったorzちゃんとつけましょう！
このブログ記事を書く際に久しぶりに動かしてようやく気づいたorz

CLKは基本宙ぶらりんです。リセット直後のI/Oの挙動が不安な場合は100kohm程度で
Loレベルに弱く固定すれば良いです。私が見た限りではEAのボードは｢宙ぶらりん
(ダンピング抵抗有)｣、ST系のボードも｢宙ぶらりん｣、中華系のは適当で他のI/Oと
一緒にまとめてCLKもプルアップしてたりそもそも基板の設計不良でCLK以外の必須
の信号線すらプルアップしてなかったりしますがCLKに関しては基本｢宙ぶらりん｣で
良いと思います。と言いたいところですが！！
STM32のSDIO_CLKは非常に高速なクロックが走り、パタンの引き回しによっては
信号の反射によって猛烈なリンギングを発生させるため信号の信頼性が著しく低下して
しまいます。よってSDIO_CLKの出力端のごくごく近くに純抵抗成分を配置して
伝送経路のインピーダンスのマッチングを図り信号の反射を抑える必要があります。
最適な抵抗値は回路構成や回路パタンの引き回しに大きく左右されるため0~47ohmを
目安にオシロとにらめっこしながら切った貼ったをして決めましょう。繰り返しますが
直列終端は信号源のすぐ近くに配置しないと後で述べるフェライトビードの配置と
同じく全く効果がないどころか最悪パワーアップさせてしまいますので基板設計の
段階から考慮しておくべきです。

20160110追：
直列抵抗入れてもダメならフェライトビーズも足してください。

プルアップの他に注意すべき点は3つあります。
１．ブレッドボードの使用は避ける
　ブレッドボードの使用は｢SDカードが繋がらない｣の諸悪の根源です。結線ミスが
　原因のトラブルでブレッドボードで実験していたという証言が非常に多かったです。
　ブレッドボードは確かに便利ですが、SDカードに限らず接触不良や接点抵抗の増大
　によるさまざまなトラブルのもとに繋がります。面倒でも半田付けを行う癖をつけ
　ましょう。とは言え何でもかんでも半田付けもだめです。丸端を圧着せず半田付け
　とかもってのほかです＃
　
　同じ理由でSDカードソケットに接触圧が弱く金メッキの薄い中華製の安物を使うと
　接触不良につながります。注意しましょう。接触不良の問題は状態が変わりやすく
　不具合を特定しずらいので厄介です。

　ぇ？お前ブレッドボードより酷いやっけつな使い方してるじゃんですって！？
　わ…ゎたしは理解した上でやってるからいいんですよぅ！

２．結線はなるべく短く
　これもSDカードに限らず基本中の基本ですね。SDIOの場合はMAX52MHz、通常使い
　でも25MHzもの高速クロックが走ります。クロストークが起こらないような配線を
　考慮しなければなりません。
　
　
　とはいえ利便性も考えないといけません。私の場合はSTM32F4Discoveryで使う
　場合はトレードオフでカードコネクタに対してこんな配置にしております。
　配線長が10cmを超えてしまうとTCK=21MHzだと"あうち"です。なるべく太く短くを
　目指しましょう。ちなみに~~S¥パワーメッシュ基板~~を使うと配線もしやすくGNDも
　安定していろいろ楽ができるのでオススメです。

３．電源
　電源は出来合いのボードを使う際の意外な落とし穴になります。SDカードの仕様と
　STM32F4で使用できる全てのSDカードのモードを考慮すると最大200mA必要と
　します。
　STM32F4Discoveryの3.3V(はショットキDi経由してるので3Vくらいに落ちる)
　から無理に引っ張ってきても"何とか"動きますが高速で信号のやり取りを
　していると特に書き込み動作の際に不安定になってきます。
　こんな場合は、フェライトビードを無暗に挟むよりもSDカード電源供給専用LDOを
　用意してあげると効果的です。このとき使うLDOはSDカードの高速アクセス時の
　大電流の吸い込み吐き出しに対応するためにセラミックコンデンサ対応の負荷の
　過渡応答性に優れたものを選んでください。
　STM32でSPI限定で使用する場合、仕様上最大で100mAあればよいので秋月さんの
　ラインナップでいうとXC6202P332PR-GやTAR5SB33で十分です。勿論LDOの電圧
　供給源(ほとんどの場合はUSBの+5V)は評価ボートと同じ系統にしてください。

　
　ねむさいんは当然のごとく攻守ともに優れたLT1963Aです♥
　↑秋月さんも私が指摘してた'A'付きにようやく気づいたようでMLCC対応と明記してます。

全然考を察していない内容になっちゃいましたが次回は既存のライブラリを駆使
してMMC/SDIOドライバを組んで実際に動かすソフト編をご紹介します。

STM32F7が発表になってCMSISヘッダファイルもようやくV4.00になった

20150717追
STM32F7はぢめました
20150717追

少し前にCortex-M4をさらに進化させたCortex-M7が発表され、ねむいさんを含む
一部の方の間で騒然としておりました。同時にSTMicroさんからも同コアが搭載された
STM32F7シリーズが発表され、既にBGA品がサンプルとして
出荷されているそうです。

既にSTM32F7用のサイトもあってデータシートも
公開されております(RMはまだです）。
Cortex-M7コアではAXI+AHBのマトリクスになり、密結合メモリ(TCM)も
インストラクションとデータ専用に用意されさらに外部メモリ用にI/Dとも
4kByteずつL1キャッシュも搭載されております。
ねむいさんがSTM32F7で着目したのはLPC4300シリーズではおなじみのクアッド
SPI-ROMの対応です。
これによりリニアなアドレスに配置されて内蔵フラッシュと同じ感覚で
使用できることになるためFONTX2のような大容量のデータを扱うプログラムも
組み易くなりますね♥
内蔵フラッシュが1MBに抑えられているのもデータの塊はSPI-ROMに押し込めよ
という意図があると思います。

あとCortex-M7では浮動小数点演算ユニット(FPv5)が倍精度まで対応して
います…が、STM32F7ではSTM32F4と同じ単精度のみの対応となるそうでF**K!
発表された当初はデータシートよく読み込んでおらず、ついに倍精度に
対応かー！と思い込んでたのでぬか喜びでしたorz

アーキテクチャとしてはCortex-M4Fと同じARMv7E-Mとなるのでバイナリは
互換出来るそうです。STM32F4ではTCMではなくCCMがありましたがそれが
配置されていたアドレスはTCMとは全く異なりますので凝った使い方されて
いる方は結局リンカスクリプトから組み直しになりますのでご注意ください。
しかしながらCCMではできなかったDMA転送がDTCMでは可能になっていますので
かなり素直にプログラムを組むことができるようになるでしょう。

さて、発表されたばっかで商用はともかくGCCコンパイラもこれから対応開始となる
ようですのでSTM32F7を実際に入手して遊べるようになるのは半年くらい先に
なるかなと思います。
STM32F2の時見たES品が中華から流れてきてくれたらもっと早いかも。
20141001追：
LauchpadのARM-GCCがアップデートされましたがなんとCortex-M7の対応が
ギリギリで突っ込まれたようです！
STM32F7対応にする場合はSTM32F4からは以下のようにオプションを変えることに
より可能です。

STM32F4:

-mthumb -mcpu=cortex-m4 -march=armv7e-m -mtune=cortex-m4 -mfloat-abi=hard  -mfpu=fpv4-sp-d16

STM32F7:

-mthumb -mcpu=cortex-m7 -march=armv7e-m -mtune=cortex-m7 -mfloat-abi=hard  -mfpu=fpv5-sp-d16

そしてCMSISのサポートの方ですがこちらの方は発表と同時にCMSISもアップデート
してヘッダライブラリもやっとこ3.30->4.00に更新されています。
もちろんCortex-M7コアのヘッダも追加されております。ようやくメジャーナンバの
更新になりましたが私が試したところでは全く影響はなかったのでそのまま差し替えて
使用が可能かと思います。
おきぱのプログラムも10月度の更新から順次V4.00版CMSISヘッダファイルに
差し替えて更新していきますのでよろしくおねがいします。

おまけ

STM32F411RE-Nucleoが夏前に手に入りました。STM32F411シリーズはF401の
機能拡張版の位置づけのようです。PCM1723氏が非常に詳しく考察されています。
PCM1723氏もCubeMXのバグに言及されてますね…
なお、おきぱのF401-Nucleo向けのバイナリはそのままSTM32F411版でも
使用可能です♥

OpenOCDはSTM32F411シリーズは未対応だったので対応させております。
本来はOpenOCD小ネタ行きの案件ですが小ネタ過ぎて載せられなかったので
こちらで告知させていただきます。
次回は大物の更新が控えていますのでご期待下さい♥
おきぱにあるWindows用バイナリもすでに対応済ですのでご利用ください。

おまけのおまけ

ああああああああああああ！！
RTC用のチップコンデンサは位置的に物が当たり易い位置にあってすぐ欠けるorz

STM32Cube系ライブラリ移植への道

と
いうわけでSTマイクロの苦情隔離場でbugという文字が乱舞するいわくつきのSTM32Cube系
ライブラリへの移行を順次開始しました！
NUCLEO-F030板
 NUCLEO-F401板
 NUCLEO-F334板
おしまい。ぁー憑かれた…

すみません冗談です冗談！春先にも少し触れてすでにこれちょっと微妙だと
判断を下したSTM32CubeF4をはじめとするCube系ライブラリは今までの
"標準ペリフェラルライブラリ"とは互換性が全くなく、バグも多数報告されて
いたのでねむいさんも移植に難色を示していました。
が、
最近発売されたNucleo系のボードに搭載された新しいMCUはもはや過去の
ライブラリには未対応となっており、事態を重く見たねむいさんもようやく
重い腰を上げたわけでございます。
早く座らせてくれ。
(※以下、縮めて"HALライブラリ"と呼称します)

実はここ数か月でHALライブラリへの移行準備自体は着々と進めていて、
その第一歩として手持ちのNucleo板のプロジェクトのライブラリを一気に
移行していました。現在手持ちは写真のとおり(って見た目同じですが)
F030,F401,そしてF334の3つです。
それらのプロジェクトはごくごく基本的な動作のみを網羅した小規模な
プログラムにとどめていたのでまだ難易度は低く、移植の感触をつかむのには
うってつけでした。
私の公開しているプロジェクトは全てこちらの手順に準拠しているので
移行後も不自由なく同じようにビルドできるものを目指しました。

移行にあたってねむいさん的ポリシーは以下の要素に。
1.プロジェクトのディレクトリ構造は従来の物から崩さない
　まぁ鉄則ですね。ケアレスミス防止目的でもあります。
　互換性を重視しすぎて不便になるのも本末転倒なので変えるべきところは変えます。

2.HALライブラリに依存する箇所をなるべく作らない
　これも鉄則ですね～。またライブラリ大変更されたら目にも当てられないですし。
　抽象化のためにサイズが激増する冗長なコードがやたらと多いので分解・
　簡略化して別途作ったほうがいいです。一方でHALライブラリ使った方が分かり
　やすい周辺機器の初期化の箇所は割り切って利用していきます。
　
　ぇ？それじゃHALライブラリ使ってる意味無いだろですって！？
　無いですよ。そんなもん最初っから(キレ気味)

3.STM32CubeMXで生成されたひな形は利用しない
　STM32CubeMXは各開発環境ごとにHCLK/PCLKの初期化コードを含むひな形を
　自動作成するJAVAで作成されたプログラムを指します。ねむいさんの環境は
　GCCのコマンドラインビルドに属する極めて原始的なものなのでひな形を
　そのまま利用できません。

　CubeFxのアーカイブにサンプルコードが収録されてるのでCubeMX使わずとも
　それ見たら殆ど事が足ります。おまけに生成されたコードが現状バグだらけで
　まったく信用出来ないので100000000000000000000歩譲ってHCLKやI2C/I2S
　クロック周波数の初期設定に軽く参考にする程度です。

4.メモリリソースはなるべくていうか絶対に許さ浪費しない！
　HALライブラリでは抽象化を上げるためインスタンスという概念が
　追加されています。それに付随する構造体が馬鹿でかいサイズなので
　F0系ではSRAM領域を圧迫されすごく苦しくなります…
　なるべくグローバル変数で確保はしないように心がけましょう。

上記の点を念頭に入れて再構成したプロジェクトと従来のプロジェクトでビルドした
バイナリファイルのサイズの比較してみました。比較対象基板はF030板のです。
*STM32 StdPeriphDriver(STM32F030R8T6_NUCLEO_20140326.7z)

Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	   7216	      0	   7216	   1c30	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

   7096	    120	    328	   7544	   1d78	main.elf

*STM32 HAL Driver(STM32F030R8T6_NUCLEO_20140702.7z)

Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	   7916	      0	   7916	   1eec	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

   7796	    120	    412	   8328	   2088	main.elf

orz
フラッシュもSRAMも使用領域ががっつり増えてやがるorz

HAL Driverのスタートアップは"__libc_init_array"のリンクがあるのでC++の対応を
すててこれを取っ払ってみました

Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	   7828	      0	   7828	   1e94	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

   7708	    120	    412	   8240	   2030	main.elf

焼け石に水orz
SRAMを減らさなければ…

HALのSysTick関数"HAL_GetTick"は_weakで切られていて
オミットできるのでやってみた

Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	   7820	      0	   7820	   1e8c	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

   7700	    120	    408	   8228	   2024	main.elf

フラッシュメモリで8バイト、SRAMは4バイト減りましたが焼け石に(ry

bss領域がインスタンスの確保で100byteも増えやがるのはF0系で
かなり痛いんですよね～。こいつを追い出してみました。

Built Object Informations:

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	   7776	      0	   7776	   1e60	main.hex

=== Verbose ELF Size ===

   text	   data	    bss	    dec	    hex	filename

   7656	    120	    300	   8076	   1f8c	main.elf

雄々ッッ！！BSS領域が元より減りましたよ♥
もぅいいわこれで…もちろんスリムになってもちゃんと動作してます♥
※最初に取り除いた"__libc_init_array"はC++な人のためにリンクを復活させてリリースしてます。

今回の検証に当ってHALライブラリを使用したexampleの中で構造体の一部の要素が
未設定により起こる不具合がみつかりましたがまぁライブラリ自身の不具合じゃない
のでスルーで…(ねむいさんのプロジェクトでは明示的に初期化してます！)
そして話が冒頭の文章に戻るわけです。

ひとまずNUCLEO系板はすべて移行して最適化完了ですが残るDiscovery系の
板のはどうしようか考え中です。特にSTM32F4のいつものは多数の
ペリフェラルを使用しているので移植は本当に腰据えて一気に攻め上げないと
バグを生んでしまいますからね…
しかしいずれは通らなければならない道だと思います。
FATFSのSDIOとDMAの処理の移植が峠になりそうです。

2014.07.15 Tuesday
23:40
ネムイ・トリノミアス
ARM/STM32
-
-

STM32F4版Nucleo(Nucleo F401RE)を使ってドットマトリクスI2C液晶を動かす

買ってしまった…
でもこのぶろぐの運営上F4版Nucleoは避けては通れないので新しい時代
(mbed全盛)の幕開けには必然であったと思うのですよ！

STマイクロからリリースされたNucleo一族はmbedが利用できるという売り文句の
他に価格が異常なくらい安いという点も注目を集めていますね。これについては
いろんな方がいろんな考察をしておりますが、ねむいさん的にはこれは中華製
ぱちもん基板の駆逐も目的としてるんじゃないかなとにらんでます。STM32って
中国大陸の方の中華圏では日本市場とは比べ物にならないほど大人気なんです。
それにあやかり安かろう悪かろうのとんでもないブツがあふれてますのでST自ら
超安価に基板をばらまいて巨大な中華市場をさらにコントロールしようという
思惑が考えられます。

視点を日本に戻すと日本ではハードウエアレベルを隠ぺいした抽象化を強化した
プログラミングがArduinoや前途のmbedを中心に大流行していますので日本に
おいてもこの基板を用いたことによりSTM32の利用者も急激に増加していく
ことになると思います。
で、ねむいさんってmbedとか使ってないから全然関係ないじゃんとか突っ込まれ
そうなのですが別に便乗とかそういう意味合いでは全くなく単にSTM32F401
シリーズを使ってみたかっただけです！！！！

ｹﾞﾌﾝｹﾞﾌﾌﾝ…というわけでSTM32F401シリーズは従来のF4シリーズの廉価版に
位置付けられていて下記の機能が削られています。
・CCM(Core-Coupled Memory=密結合メモリ)
・DMA転送用SRAM領域
・BackupSRAM領域(バックアップ"レジスタ"は健在)
・クロックがF40x系の半分(MAX84MHz)
・PB11(Vcapになった/一部パッケージのみ使用可能)
・FSMC
・ETHERNET
・その他ペリフェラル色々

引っ掛かりやすいのはPB11でしょうか。GPIOでPB11を使用している場合に
F401系に載せ替えるような時は注意が必要です。

STM32F401系のメモリ構成は大雑把にするとこのような感じになります。
画像はF4版Nucleoに乗っているSTM32F401RET6のものです。ごくごく一般の
ARMマイコンと変わらなくなってますので特に小難しいことは必要ないです。

てわけで実践です！緑色のLEDが点滅します。
(注：右上は某ｸﾚｲｼﾞｰｻｲｺﾚｽﾞではなく見滝原中学校の制服を着たいないさんです)
先ずはLチカ!mbedだとハードを越えてほぼ同じコードでLチカせしめることが出来ます
がねむいさんの環境も同じくmain.cはほぼコピペで同じようなことが可能です！！！
水面を優雅に泳ぐ白鳥も水面下ではせわしなく足を動かしているのと同じく抽象化さ
れたコードの下では頑張って下駄履かせてきた人たちの汗と涙が詰まっていることを
少しでもおもいだしてくれれるとうれしいでｓ

そういうことはどうでもいいのでさっさと先に進みます。お次は前回と同じI2Cデバイス
です。こちらもいつものの奴で汎用化したシンプルなI2Cライブラリを作りこんでいて
そのまま転用出来るようにしてあるのではっきり言って前回のF0系より楽勝でした。

所でこのi2c液晶、私が使い方公開しましたがaitendoさんで全く数が減ってません…
規模の大きいマイコンで使う限りでは圧倒的に使い勝手が良いのですが…
消費電流もST7032iとかに比べて少ないのでお勧めです★
大事なことなので前回に引き続き二度言いました。

というわけで今回動作させたF4版NucleoのLED点滅とI2Cデバイスのサンプルはおきぱに
公開しております。一旦ベースをこさえてしまえばあとはどんどん作りこんでいけるので
オフラインコンパイラフリークな方にも安心してNucleoを利用できると思います。

また忘れるところでした、私のOpenOCDのバイナリは今回のF4版Nucleoに
すでに対応してますのでどしどしご利用ください。

STM32F0版Nucleo(Nucleo F030R8)を使ってドットマトリクスI2C液晶を動かすその2

かなり間が開いてしまいましたがねむいさんが膝の治療をしてるうちに
世間はまた大きく変わり、秋月さんからついにF4版Nucleoが発売される
運びになりました。ねむいさんの狙いはF073系のボードなので手元の
ボードを消化しつつ様子見です。

さて、今回の記事は前回の続きです。以前はF0版Nucleoを使って
GPIOによるソフトウエアI2C制御にて某I2C液晶を動かし茶を濁していました。
が、今回はSTM32F0のハードウエアI2C機能を使用して同じことを行います。

しかしながら前回述べたとおりF0,F3系の物はI2Cモジュールの世代が進んでいて
以前と同じソフトウエアは利用できなくなっています。大きな違いはスタート/
ストップコンディションが自動で発行できるようになったこと、SDA,SCLに
アナログ+デジタルフィルタが追加されたことそしてSCLの周波数が直感的に
設定できなくなったことです。
SCLのクロック設定はSTのサイトから落とせるI2C_Timing_Configuration
なる物を使用して得られた謎の16進数をtimingsレジスタに書き込まないと
いけなくなりました。~~余計なことするなー!~~

とはいえ一度設定すると後から変えるような場所ではないですから…まあ
許容できる範囲だと私は思います。どうせ潰しが効く100kHzでしか
使わないですし！

20230905追:
STM32F0~H5まで使える汎用のI2C計算作りました！
20230905追:

F1/F4系のソフトとあわせるために結構苦労しましたが最終的にうまく動く
組み合わせを見つけて無事F0系でもハードウエアI2Cをしようできるように
なりました♥(写真ではハード/ソフトの見分けはつきませんが･･･)

おきぱのI2Cドットマトリクス液晶動作サンプルはすでに
差し替えてあります。実は4月頭にすでにハードウエアI2C版を作りこんでました。
もちろん液晶だけではなく前回動作させたI2C温度計もばっちり動きます♥

ちなみに私のサンプルを見て変なことやってるのに気づいた人も居ると思います。
わざとドットマトリクス液晶とI2C温度計ほかI2CデバイスのHALの部分を分けて
います。こんなことやった理由は今回使用したI2C接続の液晶以外にSPI接続の
ドットマトリクス液晶を接続せしめることを見据えているためです。TFT-LCDでは
すでに実践している手法ですがこちらも次回以降に紹介して行く予定です。

ついでの話ですがOpenOCDもついにV0.8.0が正式にリリースとなりました！
公式のページには新たに追加された主な機能の紹介があります。その中で私も
フラッシュドライバ周りでいくつか貢献しました。下の画像で黄色で
強調している箇所が私が手がけた部分になります♥

特にKinetis系のサポートは今後のFreeScale公式のツールにもとりこまれる
程の影響力でねむいさんも顔のパーツを真ん中に寄せて地獄のミサワみたいに
得意げになりたい･･･ところ　で　す　が　！上の画像に赤で注釈書いて
あるように、以前ねむいさんが実装したNuvotonのCortex-M0向けのフラッシュ
ドライバがtfreakﾘﾝｻﾝの勘違いにより無関係のNUC910系のサポートと記されて
しまい、V0.9.0リリースに向けて早くも釈明と大変更のプランを練っている
次第でございますorz
これ以前からずっと言及してきましたがマジでどうしましょうね･･･
幸いにもOpenOCDのNuvotonドライバ自身が全世界探しても私しか使ってない
状態なのでまだ被害が一切出てないのが救いですが(呑気)

あ、すみません最後までブログ書いてて気づきましたがNucleoの話に戻りますが
同ボード上に搭載されているST-Link/V2-1用のファームウェアが
更新されています。デバッガとVCP同時使用やそのほかの安定性がかなり
改善されていますので必ず更新してください。以前のSTLink/V2系の
ファームアップも同じアップデータで可能です。

STM32F4シリーズを使ってみる11 - STM32F429I-Discovery発動編 -

ぇー…前回のSTM32の記事の最後で新しいコードスニペットと称するどことなく
卑猥な名称のふれこみで発表されたSTM32CubeMXとそのF4シリーズのサポートを
行うCubeF4という新たなファームウエアライブラリに触れましたが…
私も移植を目指して頑張ってたのですが…

私の従来のいつものに当てはめようと思うと改造個所が多岐に及び、さらにコード
サイズとオーバーヘッドも増加してしまったので移植は見送りにして新規に作る
プロジェクトからCubeF4を使用する方針に逃げ変えました。

STM32CubeF4には抽象化がさら進められ、インスタンスという概念が追加され
ています。これがかなりの曲者で従来のF4シリーズで言うDSP_StdPeriph_Driver
ライブラリに相当する"STM32F4xx_HAL_Driver"はすべてこれの
使用を前提としていてさらにサイズが大きい構造体と併用しなければならない
のが分かりました。
これSRAMやFLASHのリソースが膨大にあるF4シリーズだからよいものをF1やF0
にも当てはめるのはかなりヤバいと思います。
私も過度の抽象化は良いとは思っていません。移植性を重視しすぎてせっかくの
マイコンの性能を引き出せないのであれば本末転倒です。

あんまし考えたくないのですが無理くそ全CPUの格差を埋めるべく抽象化を
目指し、そして失敗して結局ライブラリのバージョンが多岐に分かれて
しまったLPCOpenと同じ道を歩んでいる感じがします。
おそらくCube系のライブラリに遷移していくあたって大混乱が起こると
思いますね。無理にCubeへの遷移を煽る中途半端に発言力が持ってる人が
湧くのは容易に予測されます。学生さんなんかは自分のボスの"せんせい"
にまたCubeライブラリの使い方をwikiにまとめさせられると思います。
そういうこと言ってくる人らには"こんなことしてること自体が時間の無駄。
したけりゃ自分でやれ！"とはっきりNOを突き付けるべきです。
とはいえ私のぶろぐを見られている方は私よりも技術力がはるかに上の方
ばっかなので~~そもそもこんなとこ見てない~~私が注意しなくても各自しっかり
対処出来することができるでしょうからぐだぐだ言いましたがやっぱし
私の杞憂かな～と思います。

さて、前置きが長くなってしまいましたが以前から触れてきた
STM32F429I-DiscoveryのTFT-LCDをSPIではなくRGBインターフェースで
動かすことに成功しました。
前回は低速なSPIインターフェースでお茶を濁していました。
しかしSTM32F429シリーズにTFT-LCDに特化したグラフィックコント
ローラ(LTDC)とグラフィックに特化したDMAである(Chrom-ART Accelerator)
が搭載されているのでこれらの機能を使っていつものの再現を目指し
ようやく完成したわけです。

●STM32F429Iにあるグラフィック機能
私が説明するよりもこちらのPDFを見たら一目瞭然です。
LTDCに関してはフレームバッファとして確保したメモリアドレスにRGBの
データを書き込むだけで色の表示が可能です。また、STM32F429系では
SDRAMがサポートされているので容量を喰う画像データでも余裕で
取り扱うことができます。

Chrom-ART Acceleratorに関しては別名DMA2Dと称されていて文字通り
2Dグラフィック特化型DMAです。しかもデータ形式を変換してメモリ間
転送したり単一データを指定して転送する(レクタングルフィルに効果を
発揮)ことができます。

STM32F429I-Discoveryでは上記二つの機能を体験可能です。同ボードに
搭載されたTFTLCDの解像度は工作物ではメジャーな240x320となっています。
STM32のLTDC単体ではレクタングルを指定して書き込み時にアドレスを
自動インクリメントしながら連続で書き込める機能はない(DMA2Dで
解説します)ためアドレス計算は必須です。

具体的にいうとたとえば座標x,yにドットを打ちたい場合は基本的には先ず
以下のように座標を指定します
(RGB=565,1ドットあたり2Byteのデータを想定)。



lcd_c_buf_ptr = lcd_f_buf_ptr + 2*(x + (MAX_X*y));

lcd_c_buf_ptr :ドットデータを実際に書き込むメモリのアドレス
lcd_f_buf_ptr :フレームバッファとして確保したメモリ領域のベースアドレス
MAX_X :TFT-LCDのX軸の最大ドット数(F429I-Discoveryでは240と定義)

次にRGBデータcolourを書き込みます。



*(volatile uint16_t*)(lcd_c_buf_ptr) = colour;

lcd_c_buf_ptr +=2;

より具体的な実装はいつものの./lib/display/mcu_depend/src/lcdc_if_basis.cを
ご覧下さい。FONTX2等の描画ルーチンは完全にドット単位で行っていますが
MCUバスと外部LCDコントローラとの通信オーバーヘッドがなくなるので
ドット単位でも十分に早くなります。また、LTDCは2枚のレイヤーを使用可能で
さらにアルファブレンディングの透過効果も使用可能です。現状では単一の
レイヤとしてしか使用していませんがこちらも学習を重ねてモノにしていきます！

次にもう一つの目玉機能Chrom-ART Accelerator(以下DMA2D)です。
私のいつものではFillRect系のレクタングル指定塗りつぶしやレクタングル
指定の動画データ転送に使用しています。

基本的には通常のDMAと同じですがグラフィック特化なのでRGBデータを
格納するレジスタもあります。単一色描画では以下のように設定します。
※RGB565,黒色,全画面(240x320)塗りつぶしの場合



	/* configure DMA2D */

	DMA2D_DeInit();

	DMA2D_InitStruct.DMA2D_Mode				= DMA2D_R2M;

	DMA2D_InitStruct.DMA2D_CMode			= DMA2D_RGB565;

	DMA2D_InitStruct.DMA2D_OutputGreen		= (0x07E0 & COL_BLACK) >> 5;

	DMA2D_InitStruct.DMA2D_OutputBlue		=  0x001F & COL_BLACK;

	DMA2D_InitStruct.DMA2D_OutputRed		= (0xF800 & COL_BLACK) >> 11;

	DMA2D_InitStruct.DMA2D_OutputAlpha		= 0x0F;

	DMA2D_InitStruct.DMA2D_OutputMemoryAdd	= (uint32_t)lcd_f_buf_ptr;  

	DMA2D_InitStruct.DMA2D_OutputOffset		= (MAX_X - 1));   

	DMA2D_InitStruct.DMA2D_NumberOfLine		= MAX_X+1;

	DMA2D_InitStruct.DMA2D_PixelPerLine		= MAX_Y+1;

	DMA2D_Init(&DMA2D_InitStruct);

	/* Start Transfer */ 

	DMA2D_StartTransfer();

	/* Wait for CTC Flag activation */

	while(DMA2D_GetFlagStatus(DMA2D_FLAG_TC) == RESET){}

lcd_f_buf_ptr :フレームバッファとして確保したメモリ領域のベースアドレス
MAX_X :TFT-LCDのX軸の最大ドット数(F429I-Discoveryでは240と定義
MAX_Y :TFT-LCDのY軸の最大ドット数(F429I-Discoveryでは320と定義

フォアグラウンドのレイヤーへ画像データを転送したい場合は以下のように。



	/* configure DMA2D */

	DMA2D_DeInit();

	DMA2D_InitStruct.DMA2D_Mode 			= DMA2D_M2M;

	DMA2D_InitStruct.DMA2D_CMode			= DMA2D_RGB565;

	DMA2D_InitStruct.DMA2D_OutputGreen		= 0; /*　M2M系転送の場合は使わない */

	DMA2D_InitStruct.DMA2D_OutputBlue		= 0; /*　M2M系転送の場合は使わない */

	DMA2D_InitStruct.DMA2D_OutputRed		= 0; /*　M2M系転送の場合は使わない */

	DMA2D_InitStruct.DMA2D_OutputMemoryAdd	= (uint32_t)lcd_f_buf_ptr;

	DMA2D_InitStruct.DMA2D_OutputOffset		= 1;

	DMA2D_InitStruct.DMA2D_NumberOfLine		= MAX_X+1;

	DMA2D_InitStruct.DMA2D_PixelPerLine		= MAX_Y+1;

	DMA2D_Init(&DMA2D_InitStruct);



	/* Configure default values for foreground */

	DMA2D_FG_StructInit(&DMA2D_FG_InitStruct);

	DMA2D_FG_InitStruct.DMA2D_FGMA 			= (uint32_t)p;

	DMA2D_FGConfig(&DMA2D_FG_InitStruct);



	/* Start Transfer */ 

	DMA2D_StartTransfer();

	/* Wait for CTC Flag activation */

	while(DMA2D_GetFlagStatus(DMA2D_FLAG_TC) == RESET){}

lcd_f_buf_ptr :フレームバッファとして確保したメモリ領域のベースアドレス
MAX_X :TFT-LCDのX軸の最大ドット数(F429I-Discoveryでは240と定義
MAX_Y :TFT-LCDのY軸の最大ドット数(F429I-Discoveryでは320と定義
p :転送したい画像データのポインタ

と、従来のDMAと同じ感覚で使用が可能です。もっと汎用なDMA2Dの使用法は
同じくlcdc_if_basis.cをご参照ください。DMA2DはLTDCと組み合わせると
強力なレイヤー機能が使えるようになるでしょうね。
私のサンプルでは全く使いこなせてませんがー！

という訳でそれを踏まえたいつものをビルドして書き込み、
動作させたものが上の画像です。
静止画では違いが分からないと思いますが以前の8-bitSPIのみで動かしてた
ものとは描画速度がダンチですよ♥

惜しむらくはSTM32F429I-Discoveryに使用されているTFT-LCDが発色にちょっと
劣る点です。2014年現在では超高視野角液晶はすでにホビイストでも容易に
入手可能なのでそれに慣れた私にとってはあと一歩がほしいところと感じました
(多分最新の奴搭載したら値段跳ね上がるでしょうけど)。

●いつものFatFs+TFTLCD表示サンプルの細かい整備など

LTDC+DMA2Dに対応したついでに長らく放置していた全部載せSTM32F427IIT6基板の
プログラムも見直して安定化を図りました。いまさら気付いたのですが、新しい
STM32F4に存在するFMC(フレキシブル・メモリコントローラ)ではFSMCの
設定とは微妙に違っておりました…。

なんとFSMCでは存在しなかった変数が構造体に追加されていてこれを設定して
なかったせいで動作が不安定になっておりましたorzいまさら気付きましたが
まだFMC世代の新しいSTM32F4を使用されている方が少ないのか指摘されず
助かりましたうふふふふふふふｆ

また、この全部載せ基板はI2Cのコーデックも乗っていて音質は非常に悪い
ですがmp3やwaveファイルの再生も可能です。私のいつものプログラムでは
SDIO経由でSDカードのmp3ファイルなどを読みだして再生します
…がしかしビットレートが高いmp3の再生ではSDIOのデータ読みだしにDMAの
転送を行うとI2Sの方のサーキュラモードDMA転送と干渉しまくりあっと
いう間にオーバーフローになってエラーをはいて止まります。

という訳でこれを避けるためにSTM32F4でもFIFOのポーリングでの読み書きに
本格的に対応させることにしました。STマイクロ配布のSTM32F4のデモでは
ポーリングの読み書きはRead/WriteBlockしか対応しておらず非常に低速度
なのですがマルチブロック転送でもポーリングで読み書きできるように
改良しております。ポーリングでもDMAとほぼ同等の転送速度が得られたので
速度に関しては問題なしです。

…という訳でDMAあえてを使用せずポーリングによる読み出しだけで無事ビット
レートの高いmp3ファイルの再生も可能となりましためでたしめでたし！
(helixのフォルダにあるassembly.hのマクロが前回の機能追加で間違ってて
そもそもmp3ファイルが全く再生できなくなっていたのは見逃していただきたい)

●もいっこおまけ
私のいつものでは一部のmp3ファイルを再生したときにアーティスト/曲名情報
表示の際にゴミデータが表示されてしまっておりましたが、こちらも文字列ストア用の
バッファ(私のプログラムではCCM領域にあたる)を一旦ゼロクリアしてから
表示を行うようにしてバグを潰しております。

以前は変なゴミデータが表示されていましたが…、

修正後はこんな感じにすっきりです★

STM32F4シリーズを使ってみる10 -CMSISがバージョンアップした-

STマイクロさんから超安価なArduino用拡張ボード互換且つmbedサポートな
STM32 Nucleoなるボードが発表されすでに販売されております。
ねむいさんもSTM32F030シリーズが載ったタイプのnucleoボードを
mouserから購入しました。
…のはいいのですが一緒に購入したEFM32のCortex-M4バージョンWonder Geckoの
単品が輸出規制に見事に引っかかりてんやわんやがあったため今だ手元には
届いておりませんorz入手出来たらぶろぐに書きますのでしばしお待ちを。

ちなみに元凶のWonderGeckoにはハードウエアAESが搭載されています。
これが暗号に関する技術のため他社のマイコンでも暗号化機能を持つ品種は
しばしば輸出規制に引っ掛かります。ちなみに"ZeroGecko"にもばっちり
ついていたのですがマイコン単品ではなく評価キットという形で同時に
購入したので引っ掛からず素通り。なんといい加減な…#
…まぁ海外またぐ流通では非情にとてもよくある事柄ですねorz
EFM32の件については後日OpenOCDカテゴリでもご紹介します。

さて、前置きが長くなりましたが少し前にCMSISがバージョン4
(以下CMSIS-V4)に上がっております。但し"ARM,LTD.が提唱しているCMSIS
という規格全体"がバージョン4になったという意味ですのでcore_cm0.h等の
コアに関するヘッダファイル単体はV3.20->V3.30と
いうバージョン推移となっておりますのでご注意ください。
非常にややこしいですがV4.00ではありません。

あと以前も述べました気がしますがARM社がリリースしているCMSISのコアヘッダファイル
(本来はここまでがCMSISと呼べる範疇)とSTマイクロやNxP等各ベンダがリリースして
いるCMSIS"準拠"ペリフェラルライブラリまで全部ひっくるめて"CMSIS"と混同して呼称
される方が2014年の未だになっても非常に多いです。
ARM本家に日本語で概念が記されていますのでしっかり覚えておきましょう。ちゃんと
違いを理解しておかないと展示会とかイベントやセミナーで"CMSISって無駄にコード
サイズ増えるから使いづらいですね(地獄のミサワみたいな顔で)"と言ってしまい数か月
後に自分の言った言葉の意味を漸く理解して時間差で恥かきます。
かくいう私もえらそうなこと(地獄のミサワみたいな顔で)言ってますが最初にSTM32に
触れた時は思いくそ勘違いしておりましたがー！

…すみませんまた話が脱線しました。今回のCMSIS-V4からは前回の更新で
ヘッダファイルのみが付与されていたcmsis-osが全てのソースコードが
添付されCMSIS_RTXというフォルダに同梱されております。
ライセンス的にもBSDライクなのでむしろFreeRTOSよりも自由度が高いかも
しれません。GCCのコマンドラインでビルドできるようになったら爆発的に
普及すると思います。私もどのようにして実装するか試行中です。

そういう訳で私のいつものSTM32F4のプロジェクトは上記の最新のCMSIS
コアヘッダファイルに差し替えさらにChaN氏のFatFs0.10aのかなり
クリティカルな修正も反映済にしてあります。
Makefileやリンカスクリプトの記述も将来を見据えていくつか変更を加えて
いるので、私のサンプルをベースに何かを作成されている方はご注意ください。

そしてこの記事を書く少し前にSTマイクロよりまたまた新しいSTM32向け
フレームワークが提示されていました。STM32CubeMXと呼ばれるコード
テンプレート作成のためのツールを通してプロジェクトの土台作りの簡略化を
狙うとのこと。

このSTM32CubeMXには今回のCMSIS-V4の思想を反映したCMSIS-Driverなる
ハードウエアの抽象化を狙った規格に準じた新たなSTM32F4向けのペリフェラル
ライブラリが準備されております。
以前のSTM32F4向けCMSIS準拠ペリフェラルライブラリはすでにNRND(非推奨)
となっていますのでF4以外のSTM32品種も今後はこちらをベースとした
ライブラリ群に置き換わっていくことになると思います。

サラっとみた感じでは以前と同じCMSIS準拠なのですがマクロ定義や関数が
かなり違うので右を左にやる感覚で置き換えは不可能で実質全くの別物を
移植する感じで挑みたいと思います！
まずはおなじみのF4系から攻めていきますのでこうご期待！

ちなみにNxPのLPCOpenではSTM32に先駆けて再配布の規約をようやく明確化し、
そして体系化もしたライブラリ群を提供していましたが微妙にCMSISに
準拠していないのでChaN氏にまたDisられないように早急にCMSIS-Driverに
基づいたペリフェラルライブラリ群の整備を行うべきだと感じます。
出た当初は少ない品種だったためまだまとまっていましたが周辺レジスタの
構成が全く違うのに無理矢理LPC1xxx系でひとまとめで括ろうとしたせいで
逆に冗長な記述が増えてしまい結局各シリーズごとにLPCOpenが分かれだした
始末で混乱を極めている感がします。
はっきり言って開発のしやすさ/ライブラリ整備の点ではSTM32やEFM32に
大きく引き離されています。
ChaN氏も言ってましたがこれは非常にまずいです。使いやすいライブラリを
提供するというのはチップのerrataを出さないことと同じくらい非常に
大事なことだと思います。

と、
mbedのセミナーに絶対に行けなくなるような最後っ屁を放ち今日の日記を〆ます。
かしこ

STM32F4シリーズを使ってみる9 - STM32F429I-Discovery準備編 -

STM32F429I-Discovery(製品名:STM32F429I-DISCO)、ようやく一般市場でも入手
しやすくなってきましたね。twitterのタイムライン見てると既に手に入れられた方、
使用されている方々の写真もびしばし上がってます。

私の方はというと…少数の方は更新に気づいていたとは思いますが、東海自然歩道へと
向かう前日の11/29にすでに既存のSTM32F4向けFatFs実装例に対応ボードの
一つとして基本部分を組み入れたソースコードを公開しております。
尤も429I-DiscoveryからはぢめてF4シリーズに触る奇特な人もいるかもしれないので
これがどういう物で何ができるか今一度軽く解説をさせていただきます。
※注意※
　こことここを見て私のプロジェクトをビルド・デバッグ出来る環境拵えてることが
　前提です！"意味が分からない"という方はご縁がなかったということで…

私のFatFs実装例(通称いつもの)は、ChaNさんのFatFsを中心に各マイコンの極めて
基本的な機能を網羅しています。STM32F4においては下に述べる機能を抑えています。
STM32F429I-Discoveryでも勿論使用しております。

　1.GPIO操作
　　->LED点滅・SW入力
　2.UART
　　->割り込みを使用したバッファリングされた送受信・stdioのリダイレクト
　3.液晶モジュール
　　->MCUバスインターフェース(i8080,SPI,I2C)で駆動できる表示素子の操作
　　　STM32F429I-DiscoveryはRGBインターフェースを使わずともSPI単体でも画像
　　　データを送ることができます(遅いですが)。
　4.FatFsのローレベル部の実装
　　->SPIやSDIO等とMMC/SDカードとのインターフェース。STM32F429I-Discovery
　　　ではSPI4を使用しSPI互換モードでSD/MMCを動作させております。
　　　
　5.外部RAMの制御
　　->STM32F407系はFSMCでSRAMを、STM32F429I-DiscoveryではFMCで
　　　SDRAMを制御します。

んでもっていつものをSTM32F429I-Discoveryで動かしているところ

DMAの転送に使用される内蔵RAMが圧倒的に増加したので多少転送効率もよくなり、
その分ヒープ領域もたくさん取れるようになったのもうれしいです♥
画像はRAM馬鹿食いのgiflibを動かしてるところ

ファイラーの操作はタッチパネルより。STM32F429I-Discvoeryではコントローラに
内蔵のフィルタがあるSTMPE811が使用されているのでキャリブレーションも簡略化
しました。同基板ではVBATがVCC直結で外部にピンが出ておらずバックアップRAMが
機能しないので苦肉の策です…

タッチパネルからのファイラーの操作は上下でファイルポインタ移動、右で選択、
左でキャンセルと手抜ｋ直感的です！

前回述べていた基礎のとっかかりに関しては対応完了です。このプロジェクトではまだ
STM32F429I-Discoveryの機能のすべてを使いこなしてはいません。以下の項目は目下
実装中のSTM32F429にしか使えない機能です。

　1.LCDCを使用したRGBインターフェースによる高速な表示
　　->前回はやっけつで急ごしらえしましたが過去の資産をなんとか生かせるように
　　　作り変えてます…こちらはもうすぐ完了…。
　2.FatFsのファイル読み書き先をSDカードからUSBメモリに
　　->これ結構作業量ががが
　　　こちらに関しては先人の作例も数多くあるので参考にさせてもらってます。
　　　せっかくUSB-OTGがあるのにSDカードばっか使っててもったいないですから自身
　　　の学習がてらに実装がんばります！

そういうわけでSTM32F429I-Discoveryのフル機能を駆使した作例のほうは
もう少しお待ちください。過去のSTM32F407系の作例と完全に切り離して
STM32F429I-Discovery専用のプロジェクトとして公開する予定です。

おまけ

 1年以上前に購入した699元全部載せSTM32F407基板もSTM32F427IIT6に
換装してパワーアップさせました。
実はずーーーーっとF427系のチップが出るの待っていたのです！

こっちはこっちでF407系の資産生かしてなおかつ強化する方向で遊んでいきます。

PARTYHARD!(見えづらいですが左上)

もいっこおまけ

STM32F42xxx&STM32F43xxx系をJTAGから見た場合バウンダリスキャンのTAPIDが
40x系と違うものになってるのでOpenOCDで書き込もうとするとコけます。
この修正はgerritに投げてますのでOpenCOD0.9.0あたりで反映されるはずです。

STM32F4シリーズを使ってみる8 - STM32F429I-Discovery接触編 -

ﾃﾞﾝ！

ﾃﾞﾃﾞﾝ！
…ッツついに来ましたよ…！最強に強まったSTM32F4が…！
後ろに見えるSTM32F437IIT6も後日に…

STM32F429I-Discoveryは現時点のSTMマイコンの中で最強種のSTM32F429とそれが
サポートする64MbitのSDRAMとRGBインターフェースが利用できるTFT-LCDまで
搭載されたまさにねむいさんのために作られたようなボードです！
※正式名称は「STM32F429I-DISCO」だそうです。

STM32F429/439シリーズはRGBインターフェースのTFT-LCDドライバとSDRAMを
サポートするFMC(FSMCからSが取れた)を持ち、最高クロック180MHzで動作する
Cortex-M4Fのコアを持つマイコンです。

ついにSDRAMが…♥もうヒープサイズ気にしなくていいんじゃあんちゃん
ちなみにTFT-LCDドライバのフレームバッファ用にも使われるそうです。

とりあえず電源を入れてみるとSTLink/V2が認識してemWinと呼ばれる小洒落たGUIが
走ります。凄いもんだ…基板上に実装されたTFT-LCDの解像度は240x320です。
タッチするといろいろメニューが選択できます。本来はUSBメモリ等の記憶媒体を
挿しておくようになってるみたいですね。

今は168MHzで動いてるらしいです。

…で、
一通りデモプログラムを確認したのであとはおなじみOpenOCDで内蔵フラッシュメモリ
のバックアップをとり(2MBあるので5分くらいかかりましたよ！) 前もって予習して
いたLEDチカチカプログラムを書き込んで一発動作を確認♥
おきぱのSTM32F4向けサンプルの定義をほんの少し変えるだけで事は済みました…。

お次は目玉のTFT-LCDです。ねむいさんはこっちももちろん予習済です。
STM32F42x/43x系ではUSB用SRAMの容量拡張のほかSPIやI2C等の基本となる
ペリフェラルも数が大幅に増えていて更なる柔軟な回路構成が可能となって
います。

それではここらへんでいつものを…このTFT-LCDのコントローラICは定番の
ILI9341なのでRGBインターフェースへの応用も楽勝ですね♥
今回表示したのはねむいさんの頂き物のｲﾗｽ…ｲﾗｽﾄじゃなくて3D絵です。
あ○たご、抜錨しま～す♪ぐふふ♥
↑ねむいさんが何のキャラのコスしてるのか最近分かったです…鈍い…
↑ねむいさんて艦これ(ブラウザゲー)やらないの？とよく本職してる時に尋ねら
　れますが、6年前からずっとゴルロア続けてますし今もっともアツいブラゲに
　嵌ってる(作業的な意味で)のでさすがに他のにまで手を出す余裕がないです…。

なお、びぃぶろ君に確実に怒られると思われるえろすな個所はトリミング済みなので
安心してご鑑賞ください。

20131114追：

タッチパネルコントローラはi2cのSTMPE811です。
こちらも予習済なのですんなりいけました！

というわけで今回はSTM32F429I-Discoveryのファーストタッチをご報告させて
いただきました。基本的な部分は初期のSTM32F4とほとんど一緒なので、
F4Discoveryからの移植はそこまで難しくないと感じました。
まずはFatFsとChaNさんのファイラーを完全に移植させます。12月上旬には
私のおきぱに新しいラインアップが追加されると思います。

Discovery系基板を中心とした小ネタいろいろ

2013年7月現在、STM32とそれが搭載されたデバッガハードウエア付きの
超廉価なDiscovery系ボードはホビイストや学生さんにも今回は十分行き
渡っていると思います。今回はそれらを中心とした開発上の小ネタ…
…といっても結構重要なのをご紹介します。
故中島らも氏みたいに過去に書いたことをまた書いてるような箇所が
ありますが大事なことなので2度どころか何度も言います！！！！

●OpenOCDで使いたい！
太古の昔、STLink系のハードウエアはプロプラゆえに当ぶろぐでは
燃えないゴミとして扱われていましたがSTマイクロさんのご厚意により
V1,V2共にAPIが提供されてOpenOCDからも使用可能となりました。

尤も、対応最初期はLibUSB0.1系のAPIからでしか使用できず、メーカ製の
ドライバが(WinUSBが)使用できないのでちょっと不便な代物でした。
その後のlibusb1.0系の移行よってそれも解消され、現状商用andフリー共に
最も融通が利くデバッガハードウエアと言えます(但しSTLink/V1系は
MSCで繋がるので今でもちょっとめんどいです)。

STM32F3Discoveryを例にとると、基板上にビルドインされたSTLink/V2に
よってSWD接続にてターゲットのSTM32F303VCTに接続されています。
おきぱで公開しているOpenOCDバイナリにはねむいさん特製の書き込み
スクリプト込のcfgファイルも同梱しています。

上記のcfgファイル内ではさらにcfgファイルの入れ子構造になっていて
OpenOCD公式が配布しているcfgの内容が差し替わった時もこちらの変更は
ノータッチで継続使用可能なように管理しています。

具体的にこれを書き込みやデバッグにどう使うかは私のSTM32F3の
プロジェクトを用いて、こちらとこちらを参考にしてください。
STM32F3の場合はmakefile内でデフォでSTLink/V2を使う設定にしているので
初めての人でも非常に簡単にできます。
20230828追:
STM32F334-NUCLEO向けのプロジェクトを参照してください
20230828追:

それと最近よく頂くようになった質問で圧倒的に多いのがSTLink/V2でOpenOCD
との接続が上手くいかない繋がらないといった非常に曖昧なものなのですが…
ほぼ100%結線ミスが原因です。
特に気づきづらいのがDiscovery系の基板を使ってオンボード上のターゲット
MPUではなく外部のマイコンに書き込もうとした時なのですが、V2.J15以上の
ファームだとターゲットのVCCの電圧も監視しているため、Vtgtを繋げていないと
エラーでこけます。

しかも多くのDiscovery系基板ではVtgtを取り込む抵抗が未実装のため、
それに気づかずVtgt繋げてるのに上手くできない！といった事態になります。

↑STM32F3Discoveryでは上記の部分に100ohmを乗っけてバイパスする。
　同じこと以前も言いましたが大事なことなので何度でも言います
ついでに

↑STM32F3discoveryではSWOまで未接続なので画像の箇所をはんだブリッジ。
　これやっとかないと後述のSWVが使えません。

●STマイクロの公式ツールを使いたい！
現在STマイクロさんからSTLink-UtilityなるSTLink用のGUIツールが提供されています。
上で触れましたがOpenOCDがSTマイクロ公式のドライバでも使用可能になったので、
ドライバの差し替え無しにSTLink-Utilityも使用ができます！

フラッシュ書き込み・レジスタの参照など基本的な操作の他に3.0.0以降では
強力なシリアルワイヤビューアも使用可能です(後述)。

一部のサイトではLibUSB0.1系でやってたころの私が公開していた情報を基に公式の
ドライバを使わずzadigでインストールする指示をされている方もいます。
STLink/V2に限ってはそれは今ではもう無意味です。逆にそれをやってしまうと
STマイクロのSTLink-Utilityが使用不可能になりますのでご注意を。
なんでこんなことわざわざ何度も言ってるかというと情報が同期していない
せいで"動かないうまくできない"という質問が私の所にﾀﾞｲﾚｸﾂに飛んでくるからです…。

●セミホスティング考
セミホスティングとは思いくそかみ砕いていうとデバッガを通じてホストPCに
printf関数等の標準出力を吐き出させることができる仕組みです。
詳しい説明はARMのサイトにて。
かみきさんのサイトでも~~分かりやすい説明~~が記されております。

LPCXpressoを使用されている方はUARTを介さずprintfを実行する方式として
ご存知かと思います。しかしそれらのメーカーお仕着せのIDEを使わない環境でも
OpenOCDとGDBを組み合わせたり上記のSTLink-Utilityにより再現が可能です。
Cortex-M3系のマイコンでは2通りの方法があります。

1.OpenOCDから…
　OpenOCDではすでにセミホスティングに対応しています。そしてプログラムも
　当然ながらセミホスティング用にビルドする必要があります。
　現在Launchpad-ARMGCCのみで動作を確認しておりますが設定方法は
　私のプロジェクト上では以下の要素を。

　* makefile内
　
　"--specs=rdimon.specs -lrdimon"をCFLAGSに追加。それに伴いLFLAGSから
　"-nostartfiles"を削除(セミホスティング用のcrt.oを使う)。

　
　STM32F3,F4で使用する際はnewlib-nanoの制限によりCCM領域にスタックを
　おいているとセミホスティングが正しく働かないので普通のnewlibの
　ライブラリに切り替えてビルドしてください。

　* ソースコード内
　
　"initialise_monitor_handles()"を標準関数を実行する前に必ず実行。

　* デバッガソフトウエアとの連結
　当たり前ですが上記の設定でビルドして出たバイナリを書き込んでもそのままでは
　何も起きません。OpenOCDで接続してデバッガとホストPCとが通信できる状態に
　ならないとだめで、OpenOCD接続時に-c"arm semihosting enable"を追加する
　必要があります。

　
　"arm semihosting enable"はセミホスティングを使わないときも実害はないので
　つけっぱなしでもかないませんのでmakefileには反映しています。さて、すべて
　準備がそろった状態でrunさせるとOpenOCDのアウトプットにprintfの文字列が
　表示されます。

　* LPCXPressoみたいに小規模マイコンでできるのか？
　
　たとえばフラッシュのサイズが32kbしかないLPC1114でもLaunchpadの
　"newlib-nano"と組み合わせることによってなんとバイナリサイズ7kb以下で
　printfが可能です！
　小規模ゆえに同一RAM領域にスタックとヒープが存在するのでnanoの方でも
　セミホスティング可能というわけです。(浮動小数点付も22kb以下で可能)
　標準関数組み込んだらバイナリサイズが一気に肥大した～！
　…なんて話は今は昔。

2.STLink-Utilityを使って…
　これはCortex-Mの仕様上CortexM3/4専用技ですがSWVを利用してprintfを
　実行します。原理はprintfの出力先をリダイレクトするのと全く同じです。

　ねむいさんの公開してるプロジェクトでは…
　
　syscalls_if.h内のputch()のdefineをITM_SendChar(x)にするだけで終わり
　です。しかも1.の方法と違って垂れ流し方式なのでデバッガと常時接続
　しないと先に進まないといった障害もありません。

　
　STLink-Utility3.0.0以降でSWVが使用可能です。
　
　クロック設定はsysclock(ねむいさんのサンプルでは72MHz)に合わせて
　ください。ここでハードウエアリセットを掛けるとprintfの文字列が
　表示されます。

●STLink/V2がUSB3.0のホストでOpenOCDが繋がらないんですけぉ！１１！！
私が公開しているOpenOCDバイナリのビルドポリシーをLibusbの0.1から1.0系に
変えて少しした(現在は1.0系ライブラリとしてlibusbx1.0.16を使っています)あたりから
STLink/v2やFT2232系のデバイスがUSB3.0で繋がらなくなった！でもUSB2.0ポート
からならいけたという報告を頻繁にいただくようになり、私も調査を開始しました。
…が、ねむいさんのUSB3.0の環境ではそんな不具合全く出ない。

手持ちや後輩が持ってた拡張カードとかいろいろ試したところ特定のUSB3.0ホスト
で且つlibusb1.0系で繋いでくるデバイスの動作がすべておかしくなるのをやっと
突き止めました。
そのUSB3.0ホストとはAsmediaのASM1042!
libusbxを利用するすべてのデバッガハードウエアに波及しやがるのでOpenOCDは
おろかUrJTAGやAvrdudeやFlashromもだめですorz.

libusbxのビルドをログ出力対応にして追跡していったところ、DeviceIoContolの
関数で"IOCTL_USB_GET_NODE_CONNECTION_INFORMATION_EX"を投げて
"成功"が帰ってきてるのにストアされるはずの値がすべて0に
なっており非接続状態と判断されてコケてるのが判明しました。
ねむいさんの知能ではlibusbxのコードをいじっても全く解決する
手立てが見つからず途方に暮れていましたが、libusb0.1系APIからの
接続やWinUSBを使っているSTLink-Utilityでは全く問題がなかったため
まさかと思ってASM1042のドライバのバージョンをいろいろ変えて
確かめているとなんと動きましたorz.
以下のファームとドライバのVerで安定動作しました(WindowsXPにて確認)。
　Firmware:Version 120816-02-02-06D (V3)
　　　　　　Pour Windows Xp/Vista/7/8 32/64bits
　Driver :Version 1.14.4.0 Pour Windows Xp/Vista/7 32/64bits
上記のファイルはStation-Driverから取得可能です。

最近出回り始めたASROCKやASUS製のマザボでASM1042がよく使用されているので、
該当されるUSB3.0ホストを使っていてうまくOpenOCDが動かない方は一度上記の
組み合わせを試してみてください。

また、救済手段としてSTLink/V2をlibusb1.0系のAPIで繋ぎに行くビルド
設定にしたOpenOCDバイナリも用意しております。ドライバの差し替えが諸事情で
困難な方はこちらを差し替えてご使用ください。
OpenOCDが0.9.0になるまで公開しておきます。
20131225追:
解決しました。こちらをご覧ください。現在OpenOCD,FlashROM,Avrdude,UrJTAGの
各バイナリにバンドルしているlibusb-1.0.dllはパッチ済なので問題なく動作します♥
20131225追:

ちょっと難ありのASM1042ですが書き込みのパフォーマンスはぴか一で
μPD720202をも凌ぎます！
さらなるドライバの改良が望まれるUSB3.0ホストですね。
wrote 34816 bytes from file main.elf in 2.359314s (14.411 KiB/s)
verified 34004 bytes in 0.265619s (125.018 KiB/s)
↑uPD720202の時のSTM32F3にSTLink/V2つかって書き込み/ベリファイ速度
wrote 34816 bytes from file main.elf in 1.734330s (19.604 KiB/s)
verified 34004 bytes in 0.109372s (303.615 KiB/s)
↑ASM1042の時のSTM32F3にSTLink/V2つかって書き込み速度/ベリファイ速度

●ねむいさんとこのFatFsのSDIOで繋げるほうのSTM32F2とかF4のサンプル使った時
　SDカードに4GB超えてデータ書き込もうとするとデータが破壊されるんだが…

ごめんなさいごめんなさい！！！！
SDIOで読み書きする際のアドレスを指定する引数のデータ幅64bitに拡張して更新
しました。これでSDHCの仕様限界の32GBまで大丈夫です…SPI版はすでに対応済
なのでご安心を。
　
あ、しまった。
画像には見えてませんがdiskio_sdio.cもちゃんと64bit対応してます。

●Versaloon化してしまったSTLink/V2の正規のファームウエアを復活させる
おそロシア

しかも復活後もフツーにファームウエアのアップデートもできますし…
これで失敗も怖くない！？

●Connect Under Reset
STM32をつかっているときwfiやwfeを含むコードを実行するとデバッグユニットへのクロックも
停止してJTAG/SWDで繋がらなくなるのは常識中の常識ですが2013年になった
現在ではさすがに"普通に使っていただけなのに急に書き込み出来なくなった！！１！"
というおまぬけな質問される方はいなくなりました。

実際に回避する方法はJTAG/SWDにつなぎに行く瞬間にSRSTを手動で連打するという
極めて原始的な方法をお伝えしておりましたがOpenOCD0.8.0ではすでにその操作を
実行できる機構が追加されています。
具体的にはcfg内のresetの設定を以下のようにするだけです。
reset_config srst_only srst_nogate connect_assert_srst
これはConnect Under Resetというもので実はSTLink_Utilityにも同じく実装
されています。
私の配布しているOpenOCDバイナリに同梱されているcfgファイルにはコメントアウトの
形で追加していますので適宜コメントを解除して活用してください。

よく頂いていた同種のご質問に"低消費電力モードとかにするとデバッグ
できない！1!!!"という内容もありましたが、大抵はCortex-M3に存在する
Core Debug Resistersのうちの一つ
DHCSR(Debug Halting Control and Status Register)に0x07ぶち込んだら
解決する話しであるということも併記しておきます。

具体的にどうすればいいかというとCMSIS3.xx以降をお使いの方は下記の
コードをWFI();もしくはWFE();実行前に挿入してください。
ただしコアの消費電流はデバッグユニットが働く分増加しますのでご留意を。

CoreDebug->DHCSR |= 0x7;

これはDHCSRレジスタにC_STEP,C_HALT,C_DBGENビットを立てることを
意味します。
同時に立てても効果はでますがC_HALT,C_DBGENビットが立っていない
状態でC_STEP単独で立てることができないことに注意してください。
深いことは考えずにSleep系命令を含むファームのデバック時には実行前に
しっかりCoreDebug->DHCSR |= 0x7;を唱えておきましょう。

これとConnect Under Resetを組み合わせるとWFI();やWFE();を含む
コードでも安定してデバッグが可能となります。

いろいろ試す17

試"す"というか試"した"結果のご報告の方が多いかも…

●STM32F437シリーズの予習
2013年4月中旬現在はまだチップ単体は手に入る時期ではないのですが
去年買って放置していた超格安全部入りボードを使用して来たるSTM32F437シリーズの
予習をしていました。
ただこれに付属しているTFT-LCDモジュールのタッチパネルドライバICが定番の
ADS7843ではなく、I2C接続のSTMPE811というI/Oエキスパンダと温度計も一体化
された妙に"いんてりじぇんす"なICだったのでそれの対応に非常に苦労しました。

↑画像は春になり発情期を迎えたいないさn
とりあえずいつものが動かせられるようになったので同じ基板を購入した人たちは
無改造で追試できると思います(TFTLCDのドライバはILI932xを選択の事)。
I2Cバスエラー対策はまだ実装していませんので、フン詰まりになったら電源を
いったん落とした後再投入して対処してください。(やっけつ)
また今回はタッチパネルの処理の上位層も少し見直して無駄な記述をしていた
箇所や分かりづらい箇所を廃しております。たとえば、

キャリブレーション画面で青の■をしっかり押せたら…

黄色の■になる！…もちろんこれだけではありませんが細かいところも修正してます。

せっかくなので全体的にソースコードも見直してコメント等をできるだけ随所に
挿入して、プログラムの流れもつかみやすくなるよう努めるようにしました。
本来は書いた本人がプログラムの動作に関する詳しいドキュメントを書くべきなの
ですが~~こちらのかた~~が非常に分かりやすい解説をして下さっており、ねむいさんも
いつも参考にさせてもらっていま…あれ？

今回の修正はおきぱにあるSTM32F1,F2,L系のものを始め他社のARMマイコンのFatFs
移植例にも順次反映していきます。

●STM32F4で外部SRAMを使う
ねむいさん非常におまぬけなミスをずっと放置しておりました。
STM32F4向けのいつもののプログラム中でターゲットボードにREDBULLを指定した
場合は外部SRAMを使用できるようにFSMCの設定を行っていたのですが…
REDBULL上ではキー入力も同時に有効にしておりそこのGPIO設定がでたらめ
だったためFSMCのポートにもそれが波及し外部SRAMへの特定の
アドレスのアクセスで頻繁にHardFaultっておりましたorz
一見まともに動いているように見えたので気づくの遅れましたorzorz
今回のソースコードの見直しではぢめて気づきましたorzorzorz

というわけでそこを修正して大容量のSRAMをmalloc系関数のheap領域として
使えるようにして、(さすがに内部SRAMと比べると非常に速度が遅いうえに
マトリクス化されていないのでスタック領域までは割り当てる気がありません…
F4はCCMあるし)これでメモリサイズを気にせずに自由自在に使えるようになった！
…と思いきや、16bitのアラインメントが乱れるようなアクセスが連続で続くと
やっぱりコケます。
これはlibjpegで画像をデコードするような時に特に顕著になりこのように
途中で表示がグレーになったストール状態に、虹裏で見られる富山みたくなって
しまいます。

↑libpngとgiflibだとこの現象一切起こらないのですが…調査はいずれまた…

また、FSMCのバスにSRAM以外に入出力容量の大きいブツ(低速でしか動作できない
一昔前のTFTLCD等)がぶら下がっているとやっぱりこけます。オシロでWRの波形を
見たらオーバーシュートしまくりです。なのでTFT-LCDも影響を与えないものを
オシロの波形とにらめっこして選ぶ必要があります。もしくはFSMCに影響を与えない
SPI接続のLCDの選択も考えてください。

ねむいさんが試行した限りでは16bit区切りになるような、たとえばVRAMとして
16bitにパックされたRGB565のデータをスタティックに確保しただけの状況下の
使用では問題は一切発生なかったのでこの先も慎重に確かめてみます。

●LPC4357全部載せ基板
RMBレートが13円のころに買っておいてよかったです♥USDも99円(20130411現在)
まで回復してますが海外のパーツ・基板漁りはひとまずお休みして買いためたブツを
消化して逝きましょう先ずはNxPのCortex-M系最高峰のLPC4357のボードです！
(2013年01月中旬当初は国際送料込みでなんと13000円台で購入できていた超格安な代物でした。)

以前LPC4330というLPC4300系の基板をいじっておりましたがあっちはプログラムを
格納するフラッシュ領域が全くなく、スズメの涙ほどの内蔵SRAMか低速な
SPIFI-SPIROMから実行せざるを得ない非常に使いづらい代物でした。
しかしこいつは違います！204MHz動作でフラッシュも1MB内蔵なので使い勝手が
改善されて(ると思い)ます！…しかし…

…
4.3inchLCD基板の接合部でみてはならないものが目に入ってしまいました…
…なんだこの隙間は…これのせいでベースの基板もひん曲がってるし…
(後日このヘッダピンを半田槽で外し新しいものにまっすぐ付け直しました)

通電すると動作確認用のサンプルプログラムが起動します。またOpenOCD用の
cfgを作っていませんがLPC4300系のフラッシュ書き込みルーチンもまだ
レビュー段階なので先ずはそこから基礎を固めて試してみましょうか…！
(逆さになった何かを無視しつつ)。

●OpenOCDをさらに使いやすく
年明けくらいからでしょうか、ねむいさんが提供しているOpenOCDバイナリを
STLink/V2から使用する際にドライバをLibUSBからではなくSTMicro提供の
純正ドライバを使うように変更できないだろうか？というご要望をちらほら
いただくようになりました。

まさかとおもってSTMicro純正のドライバをよく調べてみると、Windows向け
ドライバとしてWinUSBが使用されているのがわかりました。
また去年行ったFT2232系FTDIデバイスのMPSSE対応の際にWinUSB(LibUSB-1.0)用の
ビルドができるようになっていたのですが、STLink/V2に関してはVersaloonと
同じくLibUSB0.1系を使用するようにビルドオプションを指定したままになって
いたので純正ドライバは使用できない状態でした。

今となってはWinUSB(LibUSB-1.0)を使用しない道理は存在しないのでSTLink/V2の
ドライバとしてWinUSBを使用するようにビルドオプションを変えて純正ドライバを
そのまま利用できるようになったバイナリを現在は提供しております。
ST-LinkUtilityなどの純正ツールとOpenOCDがドライバの差し替えなしに利用
できるようになったのでぐっと便利になっております。
そのかわり従来のLibUSB0.1系から使用できなくなりますのでご注意ください。
↑一応変更当時はトップにでかでかと告知してたので皆さん移行済みかと思います

追：
ドライバの扱いについてちょっとまとめます。
LibUSB-1.0：WindowsにおいてはWinUSBのラッパーとして働きます。
　　　　　　ですのでLibUSB-1.0のAPIを使いたい場合インストールするドライバは
　　　　　　WinUSBとなります。WinUSBのKMDFを使用しています。
LibUSB-0.1：WindowsにおいてはLibUSB-Win32と呼ばれ、LibUSB0.1(libusb0)の
　　　　　　APIはWDMを使用しています。
LibUSBK ：WinUSBのエミュレーションとして働きますが、WinUSBでサポート
　　　　　　してないアイソクロナス転送も使用可能です。
　　　　　　また、libusb0のAPIとも互換性があるのでLibUSBKをインストール
　　　　　　しておくと1.0系と0.1系APIを使うアプリがどちらもドライバの
　　　　　　入れ替え無しに使用可能となります。

さらにFT2232系デバイスの方もZadigでインストールする際にLibUSBKを選択
することによりWinUSBを使うOpenOCDやLibUSB0.1系を使うUrJTAG/FlashROM
などの便利ツールがドライバの入れ替えなしにシームレスに利用できるようになり、
低いコストと簡単な手順で強力なデバッグ環境をそろえることが可能となって
おります♥

●aitendoさんのanux
>ANUX続けるのやめまーす(←peep.usでページを保存しました)
こんなこったろうとおもったですよぅ！！
そうだねチャイナリスクです…せめて全回路図くらいPDFでくだち…

いろいろ試す16…という名の新年のご挨拶

あけましておめでとうございます。

去年も色々ありましたが今年も私ねむいさんといないさん(とその他虹裏メイドたち)
をよろしくお願いいたします(ぺっこりん)。

さて、早速ですが1/6に私の誕生日を控えそれの仕込みに今修羅場ってるのでお年玉
代わりのファイル更新のご連絡をさらっとだけさせていただきます！

●FatFs移植サンプルの更新
ねむいさんからのお年玉第一号です！
私のぶろぐのメインコンテンツのうちの一つですがSTM32F4をはじめとしたARM
マイコンのFatFs移植例をTFT-LCDドライバを大量追加して更新しました！
あとmakefileで無意味な記述や冗長な表現があった物を削除&外部に追い出して分かり
やすくした(つもり)です。

そしてChaN氏や海外のelec系BBSで紹介されて以来海外の方からも色々ご意見等を
戴くようになりました。国内の方の場合は私の作例見なくともFatFsの移植は簡単に
出来ちゃう人がほとんどなので、個人のノウハウが成否に大きく依存するTFT-LCDの
制御に関する情報を求めてやってこられるケースが非常に多くなっています。
尤も数年前に同じ事の繰り返しになるので概論書いて以後はもうやるまいと思って
いましたがまたTFT-LCDネタで一つ書こうかしらなんて考えています。

↑たとえばtaobaoで捨て値で買ってしまったような、ドライバーICの型番だけ
　分かっててピン配置が不明の未知のTFT-LCDモジュールの解析法とかです。
　こうご期待！

●OpenOCDのバイナリを更新しました。
お年玉第2号でこちらもメインコンテンツのひとつですが、年末辺りからようやく
バイナリ使ってくれる方がちらほら出てくれたようです。(私のアナウンスもまずか
ったですが…)。

もちろんオリジナルには無い機能や書き込みスクリプトも搭載してますのでとりあ
えず落として使ってみてください。

あとわざわざ告知した理由は年末にTI-ICDI(LM4F-Launchpad)が公式対応したおりに
stlink系のAPI呼び出すときの手順が少々変更されたからで、以前私が配布していた
古いcfgファイルやプロジェクトファイルを使用しているとバッティングを起こして
エラー出て停止してしまう危険性があるためです。

おもに影響を受けるのはstlink系のハードウエアで、プロプライエタリドライバの
TI-ICDIが取り込まれた際に抽象化レイヤの名称が"stlink"から"hla"という普遍的な
名称に変更されています。
現在おきぱで配布しているものはこのhlaに置き換えたものなので新しいプロジェクト
と併せてお使いください。LPC1114をSTLinkで使ってた人は知らないと嵌るかも…。

●今年の抱負など
こうやって書いとかないと絶対実行しないタイプの人間なので

1.beagleboneをいじる
　->気が付いたら買ってしまったので弄らないともったいないのです！！
　　せめてPC連動の据え置き型mp3プレーヤーみたいなのを作ろうかと…

2.ANUXをいじる
　->気が付いたら(ry
　　せめて虹裏見る用のブラウザ(ry

3.ドットマトリクスLCDライブラリ
　->ご存知の方もいますが2.5元i2c液晶買って以来数年間育て続けたネタですが、
　　がた老さんに先を越されてしまいそうです(汗
　　いまだ水面下ですが去年の春に16諧調グレイスケールOLEDまで実装したので
　　TFT-LCDライブラリと同じ感覚で気軽に使用できる物を目指したいと思います！

4.英語の勉強
　->私は読み書きは時間掛けると疎通は何とか可能だが会話がもう壊滅的でヤバい。
　　学生のうちに英語圏で不自由なく生活ができるレベルの英会話は出来るように
　　なっといた方がいいですよぅ…あと余裕あったら北京語も(日本に棲むような
　　語学力ある中国人以外は英語全く通じない奴が多いので)

5.夏期(4~10月)に近畿圏でトレランを10本以上こなす
　->へばって歩いちゃったら意味ないんですけどね…
　　でもへとへとで山から帰ってきて風呂でさらに体液絞って絞って絞った後の
　　ビールがものすっっごく美味いのです…♥
　　それと現在使用しているGPSモジュールの精度がかなり良いので初期の精度が
　　悪い時の測位データの採り直しも兼ねて･･。

6."5."で体重を60㎏以下に落とす！！！１１！！１
　->油断するとすぐ60kg肥えやがる#

STM32F4シリーズを使ってみる7 -Helix MP3 Decoderを実装してMP3ファイルの再生を行う-

マイコンを使った工作物としては入門となったMP3ファイルの再生ですが、今日日の
コアクロック100MHz越えのMPUならVS1053等の外付けのデコーダーICを使わずとも
ソフトウエアでデコードが可能です。
STM32F4にgiflibを載せて以来、次のステップとして(入院中もノートPCで)音楽再生に
挑戦していましたが私もようやく形にすることが出来ましたのでご紹介します。

すでにSTM32ではShuji009氏がHelixMP3Decorderで挑戦されており、さらに
野田さんはlibmadでMP3プレーヤーを製作されています。
ねむいさんはこちらのBBSで公開されていたHelix+STM32F4Discoveryを利用したもの
を大部分参考にさせていただきました。このプログラムはSPIポートを経由して
SDカードからデータを取得しデコードを行う形になっていてハードウエア的には私の
いつものとほぼ同じ構成だったので非常に助かりました。
ソフトウエア的な点についてはChibiOS/RTを使用していたので私の非OS環境に移植する
ためにはさすがにそのまま転用は不可能で、一つ一つ動作を理解しつつ再構成していき
ました。

ChaN氏のファイラーはデータ転送用に容量固定値の汎用のSRAMを確保するように
なっているのでそれを上手く使いSRAM容量を一切無駄にしないようにしています。
また、I2Sへのデータ転送はリングバッファ構成でDMAするのでCPUにかなり余裕が
できます。

あとSTM32F4を使い始めたころから何度も言及していますがCCM領域はDMA不可能
なのでCCM領域をスタックとして使い、自動変数にバッファを置くようなメモリの
使い方をしていると特定困難な不具合になりますのでご注意ください。
…ってわざわざこういうこと書いてるのは自分で言ったにも係らず嵌ったという
ことですorz。

ついでにいつものTFT-LCDにも各種情報を乗っけることにしました。
MP3のIDタグはv1とv2があり、v2でArtist/Titleが見つからなかった場合v1の方も
くまなく探すルーチンにしています。
もちろん日本語表示もFontX2ドライバで対応してます♥

↑MP3ファイルを再生してるところ。48kHz/230kBpsでもSTM32F4はぱわふりゃー
　なのでまったくの余裕です♥(※最適化オプションは必須です)

↑Riff-WAVEファイルももちろん再生可能です。WAVEのルーチンはChaN氏の
　WAVEPlayerFM3マイコン版を移植させていただきました。

MP3HelixのデコーダーはCBRとVBRをサポートしています。演奏中に全演奏時間や経過
時間をリアルタイムに表示するためにはCBRの場合はヘッダを除いたバイト数から容易
に算出可能です。しかしVBRの場合は少々厄介です。正確に算出したい場合は１フレー
ムあたりのビットレートからバイト数を計算しさらにそれを全フレームにわたって行う
必要がありますがもちろんこんなもんワンチップマイコンレベルではやってられない
のですが以下のプロセスで近似できます。

①　ID2ヘッダ領域にあるXingと呼ばれるヘッダから全フレーム数を算出
②　サンプルレートから1フレームあたりの時間を算出
　　 MPEG1Layer-3は1フレームあたり1152Sampleと定義付けられており、たとえば
　　 44.1KHzなら1フレームにかかる時間は((1152*10^3)/44100(Hz))=26mSecと
　　近似できる。
③　①と②を掛けると総演奏時間がミリ秒単位で得られる。

Xingヘッダーが無いと上記の技が使えませんので演奏時間/経過時間はめちゃくちゃに
なっちゃいます。殆どのMP3エンコーダーはXingヘッダーをちゃんと付与するのであまり
気にはなりませんが…。

今回のデモンストレーションで使用したaitendoさんのLCDはSPI接続オンリー
なのですが、STM32F4の性能のおかげでLCDへの転送をソフトSPIにしても音が一切
途切れず余裕で間に合うレベルです。
STM32F4ほんとすごいってね、また一つ確信させていただきました!

てわけで先日より先行で紹介はしておりましたがソースコードを改めて紹介します。
おまけでフリーで使用できるFontX2のフォントや隠れたメインコンテンツのTFT-LCD
ドライバも沢山(特にaitendoさんので初期化ルーチンが提示されてない品種)追加
しておりますのでこちらも併せて皆さんの参考としてください。

STM32F4シリーズを使ってみる6 -giflibを実装する-

前回はlibpngを実装してTFT-LCDに表示を行いましたが、今回は同じく現在でも
多用されているgif形式の画像がデコードできるgiflibをSTM32F4に実装し、さらに
アニメーションgifのTFT-LCD上においての再生も成功しました。

●あらまし
giflibはlibungifを前身に持ち、LZWというアルゴリズムでエンコード・デコードを
行います。ご存知の方は多いと思いますがそのパテントを持っていたUnisys社により
一時はgifフォーマットがあまり使われていなくなっていた時期がありました
(代わりのフォーマットとしてpngが出てきました)。
2012年現在はそのパテントの期限も切れて自由にLZWが利用できるに至っています。

gifフォーマットはpngと比べて256色までしか表現できませんが、アニメーションgif
として今でも現役で使用されています。ことさら私たち虹裏メイドに関しては、
ファイルのアップロードに500kByteの制限がある虹裏の板の仕様上pngと並んで
アニメーションを表現するのに非常に重要な形式であり、これをSTM32F4に代表される
大規模マイコンに移植し表示せしめることは最早宿命とも言えます！

STM32F4への実装と動作の理解の助けとして、yoya氏のwikiを参考にさせて
いただきました。ありがとうございます！

●必要なもの
giflib
今回は出来たてホヤホヤのgiflib-5.0.0を使用します。

●ファイルI/O
libjpegやlibpngと同じようにFatFsのAPIを差し替えりゃ簡単…とはまったく言えず、
PC向けにファイルI/Oが特化されたgiflibをChaNさんのFatFsの流儀に嵌めるまでは
かなり試行錯誤を強いられました。最終的にDGifOpenFileHandle()内はFatFs完全特
化する形で書き変えてしまいました。

●makefileに追加するCソースファイル
デコードするためには最低限下記ファイル群が必要です。
dgif_lib.c
gif_err.c
gif_font.c
gif_hash.c
gifalloc.c
quantize.c

dgif_lib.cに関しては一部内容の書き換えが生じます(後述)
dgif_lib_fatfs.cとリネームしておいてください。

●ARMマイコン上で動作させるための~~少しの~~変更
FatFsのAPIに当てはめるため、幾つかの変更を強いられます。
dgif_lib_fatfs.c
　->"/* Nemui Changed */"の変更・削除した部分を参照してください。
gif_lib.h
　->ff.hをインクルードしてください。
　->178行目のプロトタイプ宣言は以下に変更してください
　　　GifFileType *DGifOpenFileHandle(FIL* fp, int *Error);
gif_lib.h
->ff.hをインクルードしてください。

●gif(アニメーション)を表示する
多くのアニメーションgifではインターレースがどれかのフレームで使用されて
いたため、インターレースの表示ルーチンも実装しました。giflibにあったexampleを
見れば特に困ることはありません。
もちろん表示スピードは落ちますが透過表現も実装してます。

また、実際の表示に関してはRAMの少ないマイコン上の話なので一列ずつ表示
することになります。この時に消費されるRAMはベースで28672Byte(デバッガの
追跡により算出)と一列ごとのピクセル数*3です。
だいたいlibpngより少し少ない量になりますね。

しかしながら、320x240サイズのちょっと大きめでフレーム数が多いgifアニメー
ションは再生中にもメモリ要求量が増大していき、総量で70kByte近く消費しました。
libpngも大きい画像サイズの奴をデコードしようとすると65kbyte程使うように
なりますがそれより多いのです。
というわけで専ら大容量の内蔵SRAMが使用できるFM3・STM32F2&F4ですね～。

デコードされたRGBデータは8+8+8の24ビットの形式となっているため、565の
16bitにしてTFT-LCDにデータを書き込みます。
グローバルカラーマップとローカルカラーマップの判別もこの段階で行います。

そして動かしたところです…
(gifファイルはとしあき&｢｣作の物を使わせてもらいました！)

↑写真が静止画なので分からないと思いますがgifアニメーションが動いてます。
　アンドリューW.K.さん(キャラクターが)いいよね…

↑gifアニメーションの最終フレームまで来たら停止します(ループはしません)。
　ちなみにgifの仕様上ディレイ時間は10mSec区切りとなるので実装時は適切な
　時間のディレイを生成する必要があります。
　また、私の表示プログラムでは最終フレームまで行かなくても途中で各入力を
　行うことによりファイラに強制的に戻ることができます。

↑STM32F2でも動く！当たり前ですが…
　…STM32F1はRAM容量的に流石にきつかったので抜きで。

↑FM3マイコンでももちろん動きます！

ということで今回の成果はおきぱのSTM32F4,F2,FM3のFatFs移植例に
すでに反映しています。前回も少し触れましたが、私が使わせてもらている各
ライブラリ・プログラム・フォントのライセンス表記についてもきちんと明記する
ようにしていくようこころがけています。

おまけ

またまた買ってしまった(写真奥)…これからは解像度320x480で小型なTFT-LCDの
時代です！手前のaitendoさんで売ってるのより一回り小さいやつで、コントローラICは
HX8357Aです。今回のいつものの更新ではこちらの液晶にももちろん対応させています。

大きさも3インチと一回り小さいので出来あいLCD基板にちょうど乗ります♥

STM32F0シリーズを使ってみる

ッついに！手に入った！！！
ぁすみません・・フォーカスずれてましたね…
このBeachBoysのコレクターCDは探して探して探してカナダの片田舎のレコード屋でやっ
と在庫を見つけてそこの親父にねむいさんのインチキ英語でなんとか意思が伝わって
やっとこ購入できた代物でして存在知ってから入手まで実に2年を要したのですがその
労力を払っても聴く価値のある非常にありがたいCDなのです…!
BeachBoysの新アルバムも発表され、ワールドツアーも行われるようになってねむいさ
んの中でBB熱が再び非常に高まっております。

aitendoさんから販売され、秒速で売り切れたandroid基板をねむいさんも
無事ゲッツしました！twitterのTLを見ているとどうやらこちらの中華PADの中身に使用
されている基板だと判明しているようです。しかしねむいさんはHDMI接続の
モニタ持ってないので、先に購入しているBeagleBoardXMのDVI-Dにも対応した
小型モニタを探す旅から始まりそうです。こうして積み基板が増加していく…。
でもいいんです買っただけで満足ですから！

それでは本題行きます…。今年の春先にSTマイクロさんより"STM32のDNAを御得な値段
であなたにテコ入れする(直訳)"をスローガンにCortex-M0系のSTM32マイコンが発表、
販売を開始しました。国内/海外の展示会場でもゲッツした人もすでにいますが、Digikey
でもSTM32F0-Discoveryが入荷されたので早速購入してみました。

いつものST謹製"Discovery"スタイルの基板で、cortex-M0系のSTM32F051R8T6が
搭載されており、日本円で1000円以下のお値打ち価格となっています。
もちろんデバッガハードウェアのSTLink/V2もオンボードで搭載されていてこの基板と
USB(A-miniB)ケーブルさえあれば開発可能です。

しかも今回はプロトタイピングを重視した作りか同じサイズのユニバーサル基板が
一枚ついています。値段を考えると非常にお得です♥(実際にArduinoと組み
合わせたファームウェアのプロジェクト一式がダウンロードできます)。

現在M0系でポピュラーなのは私のぶろぐでも取り上げていたLPC1114に代表されるNxP
系マイコン(評価基板は3000円前後)ですが、ここに1000円以下の破格値で参入したこ
とによりまたまたホビーユースにおける小規模ARMの勢力図が書き換えられるかと思わ
れます。

さて、最初の基本であるLED点滅から開始するわけですが、LPC1114系のマイコンで培
ったリソースがすでに大量にあるのでこれをベースに15分くらいでSTM32F051R8T6
向けのプログラムをやっけつしてビルドを行います。NxP系と違う点はCRPのための
特別な定義が必要ないところですね。
それ以外はスタートアップやリンカスクリプトもほぼ流用します。

次に書き込み手段ですが…もちろんSTLink/V2をOpenOCDから操作して、書き込みや
デバッグを行います。使用するドライバはSTマイクロ提供の物(WinUSB)です。
STM32F051R8T6もM0なNxP系のマイコンよろしくデバッグ用ポートがSWD接続しか
存在しませんがパッチを当てることによりVersaloonとSTLink/V2がOpenOCDから
使用できます。
さらに気づいたのですが、最近のOpenOCDのコミットではM0系のデバッグ機能が
強化されていて以前はcrcエラーが出てしまい不可能だったフラッシュ書き込み時の
ベリファイも可能になっています♥

↓STLink/V2でOpenOCDから書き込んだときのメッセージはこんな感じです。

> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program

openocd_m0 -s C:/Devz/ARM/OCD/tcl -f target/stm32f0x_stlink_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.6.0-dev-00595-g445a54a-dirty (2012-05-28-09:15)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

1000 kHz

srst_only separate srst_nogate srst_open_drain

Info : clock speed 1000 kHz

Info : stm32f0x.cpu: hardware has 4 breakpoints, 2 watchpoints

target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0xc1000000 pc: 0x080007c8 msp: 0x20002000

auto erase enabled

Info : device id = 0x20006440

Info : flash size = 64kbytes

target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000003e msp: 0x20002000

wrote 3072 bytes from file main.elf in 0.265629s (11.294 KiB/s)

target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20002000

target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000002e msp: 0x20002000

verified 2408 bytes in 0.078126s (30.100 KiB/s)

target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0xc1000000 pc: 0x080007c8 msp: 0x20002000

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:

↓Versaloonの時はこんな感じです。

> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program

openocd_m0 -s C:/Devz/ARM/OCD/tcl -f interface/vsllink_swd.cfg -f target/stm32f0x_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.6.0-dev-00595-g445a54a-dirty (2012-05-28-09:15)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : OpenOCD runs in SWD mode

1000 kHz

adapter_nsrst_delay: 100

jtag_ntrst_delay: 100

cortex_m3 reset_config sysresetreq

verify Capture-IR is disabled

Info : Versaloon(0x15)by Simon(compiled on Feb 29 2012)

Info : USB_TO_XXX abilities: 0x0000076E:0x010001EF:0xC0000007

Info : clock speed 1000 kHz

Info : stm32f1x.cpu: hardware has 4 breakpoints, 2 watchpoints

target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0xc1000000 pc: 0x080007c8 msp: 0x20002000

auto erase enabled

Info : device id = 0x20006440

Info : flash size = 64kbytes

wrote 3072 bytes from file main.elf in 0.265628s (11.294 KiB/s)

wrote 2408 bytes from file main.elf in 0.093752s (25.083 KiB/s)

verified 2408 bytes in 0.140626s (16.722 KiB/s)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:

当たり前ですがどちらの方法でも危なげなく動作します。

もちろんOpenOCD/Insightを使ったデバッグも無制限でバリバリ可能です！

今回の検証に使用したコードはすでにおきぱにて公開していますので自己責任のうえで
お試しください。また、おきぱにあるCortex系のコードでCMSISが使用されて
いる物のほとんどはすでにSTREX系命令のビルド時エラー対策の修正がされている
CMSIS3.0系を使用していますので安心してビルドが可能です。

STM8Sは値段は安いですがちょっとあつかいにくいきらいがありました。
しかしSTM32F0なら敷居がさらに下がって小規模マイコンでARMを使用する
人も増えるでしょう。秋月さんからの販売がカギとなると思います!
20121115追：
秋月さんから販売されました！

STM32F4シリーズを使ってみる5 -libpngを実装する-

誘惑に負けて買ってしまった…盈钰電子のSTM32F4ボード…
176pinなSTM32F407IGT6,1MBSRAM,NAND&NORFlash,HS-USBPHY,Ethernet,I2SCodec,camera....
そして3.2inchのTFT-LCDまでついてオトクな699RMB!
日本円単純換算でも10000円以下の超格安です(2012/5上旬現在)

本来ならばREDBULLの基板をベースにやるべきですが費用対効果が最高なので購入した
方が早いっちゅーことで…しかもSTM3240G-EVALの回路にほぼ互換なのでSTさん提供
のサンプルなんかもほとんど素で動かせられますのでこいつでいろいろ学習していき
ましょ♥
だめだ私すっかりSTM32漬けだ…

さて、前回さらっとご紹介しましたが、libpngのSTM32F2/4への移植についてお伝え
します。私たち虹メにとってpng形式の画像ファイルはコラ等で非常に身近なもので、
jpeg形式と同じく大量に扱われています。それをマイコンでデコードし表示できる
というのはとても有用性があるわけで、かねてからの悲願がかなった形でもあります。
今回は実際の移植の手順も合わせてご紹介します。

●必要なもの
libpng
これは必須ですね。少し前にlibpngのセキュリティホールが発見されているためバー
ジョンには気を付けてください。今回は"libpng 1.5.10"を使用します。

zlib
pngファイルの実画像データは可逆圧縮されていてDeflateと呼ばれる圧縮技術が使用
されています。libpngはDeflateアルゴリズムを処理するためそのライブラリである
zlibの一部コードを必要としています。今回は"zlib 1.2.6"を使用します。

MCU
libjpeg(IJG Jpeg Library)と同じくlibpngはRAMを大量に消費します。
内部SRAMが96kByte以上あるマイコンならQVGAサイズまでなら何とか表示可能です。

●ファイルI/O
こちらはlibjpeg(IJG Jpeg Library)と同じ要領でChaN氏のFatFsと連動させます。
sirius506氏、そら。氏のlibjpegの移植例を参考にしています。
実際にどうやってるかは私のサンプルの./lib/display/abstract/src/ts_fileloads.c
にあるload_png関数の上にあるfatfs_read_data()を読み進めてください(丸投げ！)

●makefileに追加するCソースファイル
こちらのSTM32F4サンプル中にあるlibpng.mkを見ていただければわかりますが、
pngファイルの読み取りのみに限ると以下のファイルだけが必要となります。
-libpng
png.c
pngerror.c
pngget.c
pngmem.c
pngpread.c
pngread.c
pngrio.c
pngrtran.c
pngrutil.c
pngset.c
pngtrans.c

上記のうちpngerror.cは一部内容の書き換えが生じます(後述)

-zlib
adler32.c
crc32.c
inffast.c
inflate.c
inftrees.c
zutil.c

ヘッダファイルの方については念のためオミットせずに全部ぶっこんどいてください。
また、libpngを解凍したディレクトリ中の./scripts/pnglibconf.h.prebuildをリネ
ームしpnglibconf.hとしてソースと同じディレクトリにぶっこんでください。

●ARMマイコン上で動作させるための少しの変更
x86なWindowsシステムで動作させるわけではないため、エラー表示などのコンソール
I/Oの処理のオミットは必須です。
pnglibconf.h中のPNG_CONSOLE_IO_SUPPORTEDとPNG_STDIO_SUPPORTEDの
定義はコメントアウトしておき、さらにpngerror.c中のpng_default_error
関数はfprintfからprintfに変えておきます。
(printfのリダイレクトが必要無い場合はすっからかんでもいいです)
ねむいさんの環境では書き換えたファイルはpngerror_std.cとしています。
20140731追:
↑バージョンが上がってヘッダの#defineをコメントアウトすればよくなりましたので
　pngerror.cに手を加える必要がなくなりました。

また、txtとハードウエアの倍精度浮動小数点演算、インターレースのサポートも
行わないのでpnglibconf.h中の以下の定義もコメントアウトです。
PNG_READ_INTERLACING_SUPPORTED
PNG_FLOATING_ARITHMETIC_SUPPORTED
PNG_WRITE_zTXt_SUPPORTED
PNG_WRITE_iTXt_SUPPORTED
PNG_READ_zTXt_SUPPORTED
PNG_READ_iTXt_SUPPORTED
PNG_zTXt_SUPPORTED
PNG_iTXt_SUPPORTED
元からコメントアウトされていたものについてはそのままにしておいてください。

さらにpnglibconf.h中のZBUFFERの確保量(PNG_ZBUF_SIZE)をSDカードのセクタ
サイズである512バイトに合わせてください。これ以上の
値にすると512バイト以上読み込んだ際にエラーになりデコード不可能になります。
また、残念ながらlibpngにはlibjpegのような1/(2^x)にするサイズスケーリングは
ありません。

●libpngを呼び出し、画像データを表示する
大まかに分けて以下の順番で実行します。これらは必須です。
1.png_create_read_struct関数でpngファイル全般を制御するポインタ確保
2.png_create_info_struct関数でpngファイルの情報に関するデータをストアする
　　ポインタ確保(IHDRとIENDチャンクの分）
3.エラーハンドリングの設定
4.png_set_read_fn関数でfatfsのpngファイルポインタと連結
5.png_get_IHDR関数でIHDRチャンクの読み出し
6.画像の形式を24bitRGBに変換する。
7.画像のx,yサイズのチェック(1280pixel以上は撥ねる)
8.png_get_rowbytes関数で1行あたりのバイト数取得
9.png_malloc関数で"6."で取ったバイト数分の配列確保
10.png_read_row関数でIDATチャンクを一行ずつ読み出し、さらにRGBデータ幅を24bit->16bit
　　に落としてTFT-LCDに表示していく
11.表示が終わったらpng_free関数"7."で確保した配列を解放
12.png_read_end関数でIENDチャンクを読みだす。
13.png_destroy_read_struct関数で"1.""2."で確保したポインタの解放

気を付けなければならないのは各処理ごとにエラーを検知しておかしい場合は先の
処理に進ませないようにすることです。これを怠るとHardFaultに簡単に陥ってし
まいます。またIDATを読み切ってない場合にpng_read_endを実行すると即座にエラ
ーになりますのでTFT-LCDの解像度より画像サイズが大きい場合でも必ず空読みして
読み切ってください。この手順は24bitのpngを想定していますが異なる形式の場合は
24bitに変換するために"5.""6."の間に各種transformの処理が必要です。
実際にどうやってるかは私のサンプルの./lib/display/abstract/src/ts_fileloads.c
にあるload_png関数を読み進めてください(丸投げ！)

一回の表示で消費されるRAMはlibpng自体が必要とする量が約33kByte(デバッガの
追跡により使用量を算出),それに加えてTFT-LCDに表示する際のデコード済みの
データを置くバッファも必要とされるため結局以下の計算式で総消費量が求められます。
NEEDED_RAM_AMOUNT = ((XSIZE-1)*4)Byte+33kByte

式中のXSIZEはTFT-LCDのX軸方向最大ピクセル数ではなくpng画像データのX軸方向
最大ピクセル数です。つまり幅が広くなればなるほど使用するRAMの量が増えます
(libjpegもこの点は同じ)。また、今回のデモはアルファチャンネルを強制付与して
いるため(RGBAのならびになるため)(XSIZE-1)*3ではなく((XSIZE-1)*4)になります。

●実際の表示

今回の検証用のTFT-LCDとして320x480なTFT1P2797-Eを使用します。大規模マイコン
用のディスプレイとしてねむいさんのイチオシです♥

検証用の画像はこちら。こちらのサイトのキャラクタージェネレーターを使って作成した画像に
さらにコラージュを加えた私服のいないさんです。メイド服にコラしたかった
のですが髪型だけで力尽きましたorz…これをTFT-LCDに表示してみます。
ビット深度は24bitのトゥルーカラーです。

表示ルーチンとしてまず画面左上に画像の情報を出すようにしました。
col_depthはビット深度で8*(RGB)で上記の24bitとなります。
col_typeはpngの画像タイプで0がグレイスケール、3がインデックスカラー、
2がトゥルーカラー、6がアルファチャンネル付トゥルーカラーです。

実際の表示に関し、グレイスケールやビット深度が小さい画像も24bitに変換してい
ます。また透過pngやアルファチャンネルつきの物はいったんアルファチャンネルに
変換して、1ピクセルごとのアルファチャンネルを示すバイトは書き込み時に無視して
います。インターレースpngの表示はは私のサンプルではサポートしていません。
誰か腕に覚えのある方実装おねがします…。

てわけでPCとまったく遜色ないレベルでいなちゃんを表示することができました！
メモリが豊富な環境ではpng_read_image関数で一気に読み込みできるのですが、STM32
等のマイコンでは到底足らないので、1行ずつバッファに読みだして表示を行います。
読みだしたデータはRGBの順番で並んでいて8+8+8=24bitで1ピクセルとなります。
最終的にTFT-LCDには5+6+5=16bitにして書き込み、表示させます。

透過PNGを表示させるとこんな感じになります。前述の通りアルファチャンネルは
読み捨ててるので透過部分はRGB(0,0,0)の黒色で表現されています。また解像度の
関係で表示が隠れてしまったのですが、アルファチャンネル付トゥルーカラーに
変換された透過pngを示しています(赤で囲った部分)。

TFT-LCDのサイズよりオーバーする場合の画像では当たり前ですが画面外のデータは
表示できません。また画面からはみ出ている部分もpng_read_rowで全部読み切ってし
まわないとエラーになったりHardFaultに陥ってしまうので注意です。
ChaN氏のbmp表示ルーチンを見習って大きい画像でもUARTからのコマンドで仮想的な
表示開始位置を変えて表示できるようにするのが今後の課題ですね～

ちなみのこのaraiさんの描いたねむいさんの絵はアダルツなのでこのブログ的にも
見えてない部分は…ｹﾞﾌﾝｹﾞﾌﾌﾝ失礼

減色とかグレースケールにした時の比較です(注：表示の際はすべて24bitのトゥルー
カラーに変換されています。左上の数値は変換前の情報です)。

ビット深度24bitトゥルーカラーの標準的なねむいさんです。
col_depthが8になってますが実際は8bit*3で24bitとなります。

256色のインデックスカラーはこんな感じに。

24bitのグレースケールはこんな感じ。

8bitに落とすとこんな感じ。

さらに4bitに落とすとこんな感じです。

というわけで通常のPCと同じようにpngファイルの表示もSTM32F4上で可能と
なりました。しかしながらメモリはかなり食いますので内蔵SRAMが豊富にある
STM32F4専用の機能ですね～。
libjpegと絡めると空いた時間でお茶が飲めてしまうくらいビルド時間も
倍加されてしまいますのでご注意ください。

STM32L-Discovery(STM32LDISCOVERY)をいろいろ使う

…ッッ…や、やっとEtherPod(STM32F107VCT6)にFreeRTOSとuIP実装してその上に
DHCPクライアントとDNSレゾルバとHTTPDとそして目的のNTPから時刻合わせ機能
の実装まで完成した…！uIPやFreeRTOS付属サンプルだけだとこんなん絶対でき
ませんわこれ…。先達たちがネット上に残した知恵を探しだすスキルが鍛えられました。

とにもかくにもこれで漸くこの子を卒業してSTM32F4系EthernetとLwIPに手を…！
ところでなんで去年の9月にできたこともう一度やってるかと言うと、ソースコード入
ったUSBメモリを地下鉄の溝に落っとこして壊してしまって１から全部作り直しになっ
たからです‥‥‥‥orzｶﾂｶﾂに作りこんでてバックアップをサボってるときに限ってこ
ういう事が起こるというorzorz
ちなみに虹裏上の活動で作ったり描いたりしてきた絵やとしあき君&｢｣からの大切な頂
き物は、4重のバックアップ体制で自宅が爆発しようが京都府に巨大隕石が落ちてクレ
ーターになろうが核の炎に包まれてシェルターにどう詰めてもあと二人しか入らないと
言われた瞬間にケンシロウに｢ﾄｷ兄さん!｣と言わせる間も与えずｸﾞｺﾞｺﾞｺﾞｺﾞと扉閉めてあげ
て二週間後にや、やぁ…と余裕こいて挨拶できるくらい絶対に失わないようにしてあ
りますのでご安心くださいまし(ﾆﾔ･･)。

さてさわりはこの辺にしといて前回ほんの少しお話したSTM32L-Discoveryにごく基本
的な~~いつもの~~を実装したのでご紹介します。

Discovery系で比較される対象はSTM32F100RBT6が載っているSTM32VL-Discovery
ですが、実際はこちらのSTM32L152RBT6が載ったSTM32L-Discoveryの方がはるかに
性能が高いです。

↑ねむいさんが目を付けためぼしい機能比較
STM32L系のほうが後から開発されたので当たり前と言っては当たり前なのですが、そ
のせいかバスの構成やペリフェラルのレジスタ構成などはSTM32F2/4系のMCU群と酷似
しています。私もそうでしたが、移植される方はSTM32F2/4系からのほうが楽です。

今回の~~いつもの(= FatFs + TFT-LCDドライバテストプログラム)~~について、当基板に
タッチセンス用のパタンとSTマイクロ謹製のSTM32L向けタッチセンスライブラリが用
意されているのでこちらも入力系に組み込んでいます(基本はUARTの入力のみです)。
お肌が乾燥してるとタッチセンスの入力が無反応になることがあります。S**Kです。

使用するピン/ペリフェラルの構成としてはSTM32VLDiscoveryの時となるべく似せる
ようにしてみました。今回もI/Oリソースの有効利用のためにSWD接続のみで書き込み
デバッグを行うようにしました。STM32L152RBT6は外付けの水晶を付けるとUSBも使用
できるのでこちらも試してみたいと思います。図中のLCDとあるのはLCDグラスドライ
バのことではなくいつものMCU接続タイプのTFT-LCDを指します。

あと使ってて気づきましたが、クロック周波数や多ピン品種の外部バスサポートとか
の超低消費電力とかのうたい文句見てるとXMEGA系みたいな8/16bitのアーキテクチャ
で大規模化したマイコンを潰しにかかってるなぁと感じましたね。どっちも使ってい
る私が言わせてもらうとどう見てもARMのほうが扱いはるかに楽なんですもん…
FatFSのDMA化も楽にできましたし！(←まだ根に持ってる)

動かしているところです。ChaN氏のファイラは上述のとおり定番のUARTの他に基板上
のタッチセンスパタンからも入力可能です。タッチパネルTFT-LCDモジュールの時と
微妙に勝手が違うので差の吸収するために入力方法に工夫してあります。

既におきぱにある他のマイコン向けのデモも順次更新していますが、がた老氏が私の
移植例を使って成功したのを受け、デモ内のファイラにChaN氏のTextファイルビュー
アも盛り込んでいます。(STM32F107系は先行して公開してます)
ついでですが、XMEGAのFatFsのサンプルも大幅更新してます。ChaN氏の最近の実装を
参考にファイラをVRAMを使用しない構成とし、以前は出来なかったQVGAの解像度でも
ファイラを使用できるようになってます。もちろんTextファイルビューアや動画も(遅いですが)
再生可能になりました！

またまた話が逸れますがFatFsのSTM32・LPC2388(LPC1788も近日公開予定)・XMEGAへの
移植例としてChaN氏からリンク貼ってもらってるおかげで海外からのアクセスがうな
ぎ登りになってます。その9割が共産圏(元共産国含む)なのは置いといて海外から来た
人たちのためにリンクをわかり易くしました。これでもう"HENTAI-Siteに飛ばされた"
とは言わせませんよぅ！
日本国内についてはどうかというとアクセス解析やSNS等の発言をリサーチした限りでは私
の作例を参考にされてる方はlinux系OS使いな方たちが圧倒的です。Windows系の場合、
無料で利用できる統合開発環境はかなりの選択肢が存在しています。はじめてSTM32を
触る方々にとっては私のコマンドラインビルド中心な"どういう風にプログラムを組むか"
が主体のブログは全く参考にならずむしろ"その統合開発環境をどう使いこなすか"ことこ
そが往々にして最重要課題となるので、中身のないこと長々と書きましたが私は素の
Eclipseは使いませんったら使いません！！１！メーカお仕着せのやつでも拒絶反応ｇｇ

はぁはぁ…失礼…また話が逸れてしまいました‥
ぇっと後は書き込み/デバッグについてですが、前回ご紹介した通りSTLink/v2に対応
したOpenOCDからすべてを行います。また、私の作例中のmakefileをみたらすぐにわか
るはずなのですが、各デバッガハードウエア&MCU向けのcfgを引数にとってさらに
cfgに記してあるフラッシュ書き込み用のプロシージャコールを呼び出せばtelnetを接
続してﾁﾏﾁﾏしなくてもOpenOCD単体でフラッシュに書き込みができます。

↓STLink+OpenOCDから書き込むとこうなります。
(この記事を書いた当初はLibUSBを使用しておりました)

> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program

openocd -s C:/Devz/ARM/OCD/tcl -f target/stm32lx_stlink_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.6.0-dev-00448-gc59a441-dirty (2012-03-01-10:03)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Warn : must select a transport.

1 kHz

trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain

Info : clock speed 1 kHz

Info : IDCODE 2ba01477

Info : stm32lx.cpu: hardware has 6 breakpoints, 4 watchpoints

target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0x01000000 pc: 0x0800bf74 msp: 0x20004000

auto erase enabled

Info : flash size = 128kbytes

target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000

target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000

target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000

target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000

target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000

target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000

target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000

target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000

target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000

wrote 114688 bytes from file main.elf in 12.796548s (8.752 KiB/s)

target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000003a msp: 0x20004000

target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0x61000000 pc: 0x2000003a msp: 0x20004000

verified 111172 bytes in 0.515612s (210.558 KiB/s)

shutdown command invoked

前回触れたAsynchronous Algorithmルーチンはすでに最新のコミットに取り入れられ
ています。

確認も終わったのでSTM32L-DiscoveryのSTLinkもVersaloon化しちゃいました！
この基板でSTLink部の回路構成が全く同じなのでVersaloon本体・DFUブート
ローダ共にSTM32F4Discoveryのものと全く同じのが流用できますが、こちらに
STM32LDiscovery用のを用意しましたので興味のある人はどうぞ。Versaloon化
するメリットはUSB仮想COMが使用できる点に
尽きますね♥
※大事なことなので何度でも言います

あと注意点ですが、STM32LDiscoveryは外部リセット入力回路のプルアップ抵抗が省略
されています。R37に10kohmのチップ抵抗を必ず付けてください。

↓Versaloon化+OpenOCDから書き込むとこうなります。

> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program

openocd -s C:/Devz/ARM/OCD/tcl -f interface/vsllink_swd.cfg -f target/stm32lx_swd_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.6.0-dev-00448-gc59a441-dirty (2012-03-01-10:03)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Warn : must select a transport.

Info : OpenOCD runs in SWD mode

100 kHz

adapter_nsrst_delay: 100

jtag_ntrst_delay: 100

cortex_m3 reset_config sysresetreq

Info : Versaloon(0x34)by Simon(compiled on Feb 29 2012)

Info : USB_TO_XXX abilities: 0x00000008:0x00000040:0xC0000006

Info : clock speed 100 kHz

Info : stm32l.cpu: hardware has 6 breakpoints, 4 watchpoints

target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0x01000000 pc: 0x0800bcb8 msp: 0x20004000

STM32L: Enabling HSI

2000 kHz

auto erase enabled

Info : flash size = 128kbytes

wrote 110592 bytes from file main.elf in 17.983915s (6.005 KiB/s)

verified 110492 bytes in 1.140595s (94.602 KiB/s)

shutdown command invoked

んんｎ、現在の実装だとswdのクロックを途中で高速に変えられないので
ちょっと微妙ですね…128kByteしかないしまぁいいですか。

正直言うと素のSTLinkでもかなり使い勝手がよくなったので初めて触られる人は
無理にVersaloon化しなくても十分やっていけます。
いやはや良い時代になったものです。

いろいろ試す10

あけましておめでとうございます。
今年もねむいさん(と虹裏メイドたち)を宜しくお願いします(ﾍﾟｺﾘ

と関係者向けのごあいさつを終えたところで今日のブログはおわ…ったら去年の
二の舞になってしまいますので、今年こそは本気を出して出来る限り前へ前へと
進んでいこうと心に誓う次第でございます。虹裏に投下する絵やコラももう少し
増やせるようにネタの回転力もあげたいなと。

さて、MentorGraphics社に買収されたCodeSourceryが去年暮れにリニューアル
して新バージョンがリリースされています。
やはりと思いましたが落とすのにメールでユーザーの登録を求めて
来るようになり、非常にかったるくなってしまいましたがこちらからフツーに
落とせますのでご活用ください。

今回の変更点はGCC4.5.1からGCC4.6.1にアップした点ですが、LinkTimeOptimization
の効果が少し変わっています。以前と同じままだと必要な部分まで削られてしまい
ますので以下のように変更しておいてください。細かい変更はGCCの本家に~~丸投げ~~
-flto -fipa-sra
↓
-flto-partition=none -fipa-sra
またデバッグ時にLTOを有効にしてるとブレークポイントが上手く張ることができない
ことがあるので無効にしておきましょう。
さらに最適化レベルに-Ofast(-ffast-mathを強制付与)が加わりました。

新しいSourceryでCMSISを含むコードをコンパイルしていると以下のような
エラーを吐いて

"Error: registers may not be the same -- `strexb r0,r0,[r1]"
というエラーメッセージを吐いてビルドが止まることがあります。
この対策は･･･
20241009追：
つべこべ言わずCMSISv5使いなさい！！！１１！！！
20241009追：

"ことがある"と書いたのはコードの流れによってはエラーを回避できる機械語に落とし
込まれる場合もあり、発見が遅れるケースが出てきます。
この件についてはこちらのディスカッションにある内容が詳しいです。
回避方法は…
引っかからないようにレジスタ変数を強制的に割り当てるというベタベタ
なコードに置き換えるのが唯一の方法です…。_STREXBとか_STREXHとか使わないから
コメントアウトするというのは後で困ることになるのでなるべく避けましょう。
__STREXB関数の変更例。__STREXHも同じような感じで変更してください。
uint32_t __STREXB(uint8_t value, uint8_t *addr)
{
uint32_t result=0;

__ASM volatile ("strexb %0, %2, [%1]" : "=r" (result) : "r" (addr), "r" (value) );
return(result);
}

↓

uint32_t __STREXB(uint8_t value, uint8_t *addr)
{
register uint32_t result asm ("r2");
register uint8_t value1 asm ("r0") = value;
register volatile uint8_t* addr1 asm ("r1") = addr;
__ASM volatile ("strexb %0, %2, [%1]" : "=r" (result) : "r" (addr1), "r" (value1) );
return(result);
}

audin氏のブログのコメントにてiruka氏によりスマートな回避方法が提示されています。
上にあるディスカッションにも記述されていますがインラインアセンブラに早期破壊
オペランドを示す修飾子"&"を付与することによって__STREXB、__STREXHをコンパイル
した時にオペランドが同一レジスタとなりエラーが出るのを回避するとのことです。

CMSIS1.x系はcore_cm*.cに記述されていますが、CMSIS2.0以降はcore_cmInstr.hに記述
されています。変更する内容はどちらも同じです。CMSISの方が修正されるまでこれで
回避しておきましょう。

20120529追：
CMSIS3.0x以降では早期破壊オペランドを使用する修正になっています。
おきぱにおいてあるサンプルはすべてCMSIS3.01にしておりますので安心して
お使いください。
これらは液晶表示デモも兼ねています。今回の更新にあたり、多数のSPI液晶を含め
た液晶モジュールのドライバも追加しています。少し前にaitendoさんより販売された
S95591-AAA(コントローラIC:S6D0129)とTFT1P2797-E(コントローラIC:ILI9481)
のドライバももちろん作り込んでいますので参考にどうぞ。
あと業務連絡ですが、S95591-AAAとTFT1P2797-Eの初期化手順は全く違いますので
勘違いされないようご注意ください。

おまけ
もうキリがないからやめようと思ったのにまたやってしまった中華液晶モジュール
のコレクションたち…さらに詳しい詳細は私までご連絡を…

↑
176x220サイズのQCIFなSPI専用液晶。コントローラICはHX8340Bなのですが…
なんとHX8340B(N)という細かい型番が存在しているようで初期化手順どころかレク
タングルの指定・GRAMの書き込みコマンドまで全く違う別物でした…以前紹介した
HX8340Bは本当はHX8340B(T)という型番だそうです。
しかもSPIは9bit固定でした！！！！orz
てわけでハードウエアで9bitシリアルがサポートされてるMARY(LPC1114)とかには
いかがでしょうか？ちょっと解像度的にきついと思いますけど…

↑
Mouserで購入できるSDT018ATFTと言う液晶モジュール。コントローラICはILI9163C
だそうですがこいつも外に出てるピンの関係でシリアル接続は9bit固定でしたorz
てわけでハードウエアで9bitシリアルがサポートされてるMA(ry
(8-bit 8080,9-bitSerial接続）

↑
これはセカンドソースがたくさんあり、ebayでも最安5USD前後で購入できるNOKIAの
液晶です。情報元はこちらの方のページです。
コントローラICはSPFD54124Bです…が案の定外に出てるピンの関係でシリアル接続は
9bit固定でしたorzてわけでハードウエアで9bitシリアルがサポ(ry

↑
それとねむいさんのぶろぐ見てる人なら楽勝でしょうが、0.4mmピッチのハンダつけが
出来る人向けです。
(8-bit 8080,9-bitSerial接続）

↑
最後に128x128以上の解像度がなかなか手に入らないアクティブマトリクスOLEDの中で
176x220のQCIFサイズなC0200QILC-Cを

視野角とか素晴らしいのですが、OLEDの弱点である焼きつきが起こるので同じ画像を
ずっと表示することはできず、フォトフレームとかに使うと泣きを見るでしょう。
ここ最近は広い視野角TFT液晶がどんどん出てきているので無理してOLEDを選択する
必要も無くなってきました。

クリスマスの時の頂き物を…。いなちゃんは性的すぎる…♥

STM32F4シリーズを使ってみる4 -STLink/V2をversaloon化-

20231002追:
10年以上前の記事となり現在では有効ではないリソースが多数あり、
Versaloonはお勧めいたしません。
もしそれでもどうしてもVersaloonをやってみたい方はメールをください。
20231002追:

~~Versaloon本家~~がSTM32F4対応したのを受けて今回はSTM32F4 Discoveryに
仕込まれているSTLink/V2をSWD接続方式のVersaloon化する方法を紹介します。

もう何度も行っていますが、Discovery系の基板をVersaloon化したことによる
メリットは以下の通りです。
1.書き込み・デバッグにOpenOCD(ただしVersaloon対応にビルドしたものに限る)
　が利用できる。
2.VersaloonのファームウエアにUSB-CDCも仕込まれているのでUARTの
　通信手段を別途用意する必要がない。
3.Versaloonはソフトもハードもファームウェアも無償で利用できるので
　自分の好きなように改造できる。

と言ったところでしょうか。ねむいさん的には"2."が実際のデバッグや情報
表示等にかなり使えると実感しています。

●Versaloon化手順 on STM32F4-Discovery
概念についてはこちらとこちらで詳しく紹介しているので基本的な部分は
はしょりますが、Versaloon化するSTLink/V2(STM32F103C8T6)にいつもながらの
DFUブートローダを仕込んでおいてその後にversaloon本体(DFUファイル)を
書き込みます。
DFUブートローダのバイナリはUARTブートローダ若しくはSWD経由でフラッシュに
書き込みを行います。各々の方法も基板に下準備が必要です。

1.SWD経由でDFUブートローダを書きこむ場合
　SWDで書きこむ手段として今回はvsprogを使用することにします。
　用意するものはVersaloon化したSTLinkですが素のSTLinkでも書き込むまでの
　下準備は同様です。
　
　まず基板をひっくり返して写真の箇所のジャンパ抵抗をそれぞれ移転させます。

　
　上記写真の要領でSWCLK,SWDIO,GNDをそれぞれ接続してください。

　
　STlink/V2が仕込まれているSTM32F103C8T6にはReadProtectionのヒューズ
　ビットが掛かっていて、これを解除しないとフラッシュの書き換えが
　できません！
　~~これはOpenOCDのflash unlockコマンドでも解除できません。~~
　2013年現在ではstm32f2x.cにバグ修正が入ったのでOpenOCDからでも解除
　可能です。
　vsprogを立ち上げSTM32マイコンを認識したら上記画像の要領でヒューズ
　設定を行ってください。エラーが出まくりますが無視してください。
　この状態でWriteを押すとエラーが出まくりますが無視して書きに行って
　ヒューズを消すことができます。

　その後は~~こちらに用意したSTM32F4Discovery用のDFUブートローダ~~
　(の中のmain.hex)をフラッシュに書き込み、ベリファイまでエラーが
　出ずに行えたら書き込み成功です。

2.UARTブートローダ経由でDFUブートローダを書きこむ場合
　この方法は以前細かく説明しているので、ここではSTM32F4-Discovery
　基板上ではどの線を引き出せばよいかという点に絞ってお伝えします。
　~~DFUブートローダはSTM32D4Discovery用を書き込んでください~~

　
　実はSTM8S,STM32VLDiscoveryの時と比べてすっごく楽です。UARTブート
　ローダ用の線が引き出されていてなおかつ線を引き出しやすいSMDの抵抗が
　ライン上にあります。書き込みの手段を持ってない人はUARTブートローダしか
　方法がないので比較的やりやすいと思います。"TO_+3.3V"のジャンパは
　書き込みが終わったらはずすのを忘れないでくださいね。
　UARTブートローダを起動するためのBOOT0につながる抵抗はR7ですが、
　シルクの位置が上にずれてるので間違えないようにご注意ください。

3.Versaloon本体のDFUファイルを書きこむ
　STM32VL-Discoveryの時と同じくSTM32F4-Discovery基板上のResetボタンを
　押しながらPCとUSBケーブルで接続してください。DFUブートローダが正しく
　書きこまれていたらPCがDFUを認識します。その後、~~STM32F4Discovery用VersaloonのDFUファイル~~を
　書きこみます。書き込み方法はこちらを。

　書き込み後はPCとST<32F4-Discoveryの接続を切り離し、Resetボタンを
　押さずに再接続した時にVersaloonとして認識すればVersaloon化の
　成功です！
　Versaloon本体のLibusbドライバのインストールはZadigで
　行ってください。
　USB-CDC用ドライバ(COMonVersaloon)は本家のリポジトリを
　手繰って取得してください。
　これでおしまいっ！

　…と言いたいところですが、Versaloonとして使用する前に下に述べる処理を
　絶対に忘れないでください。

4.後始末
　
　
　SWDでDFUブートローダを書いた場合は最初に移動したジャンパ抵抗と
　ジャンパを元の位置に戻します。次にDFU・UARTブートローダ共通ですが、
　R68を取っ払ってください。これはSTLink/V2側からターゲットのSTM32F4
　マイコン外部クロックを供給するためのもので、Versaloonではこのピンは使用
　されていません！
　このジャンパ抵抗を外して8MHzクリスタルが効くようにしてやらないと
　STM32F4は16MHzの内部RC発振に強制されてしまいます。一見普通に動いて
　しまいUART等のタイムベースが重要なペリフェラルの動作で異常になって
　しまうので注意してください！

というわけでSTM32F4-DiscoveryもVersaloonで快適デバッグ/書き込みが
できるようになりました♥
先に書いた通り私のお目当ては複合デバイスとしてVersaloonとともにに
仕込まれているUSB-CDCです。
ごてごて外付けのデバイスを接続せずに済みますのでとってもスマートです。

おまけ
今のOpenOCDでデバッグした際に浮動小数点レジスタは見えるのか！？

ねむいさんがバリバリ使っているOpenOCD(V0.6.0)+Insight(GDB7.25)で
やってみましたが浮動小数点レジスタは見えませんでした(; _ ;)
OpenOCD＋InsightがCortex-M3というか無印のARMV7M扱いでデバッグしてる
せい(Cortex-M4FのコアはCortex-M3と上位互換してるから整数演算部は
普通にデバッグ・書き込みできる)でしょか???情報待ちですね。

も一つおまけ
ぜんっぜん関係ないですがtaobaoで超掘り出し物の液晶モジュール見っけ
ました！2.6inch,240x400のWQVGAサイズでタッチパネルつきのTFT-LCDが
たったの20元でしかも新品！もちろんデータシートなんて無かったのですが
運よく推定したピン配置がドンピシャでバッチリ動いてくれました♥
しかも類似品種のピン配置を調べるとSPIも使用可能なのが分かりコスト
パフォーマンス最高だと思います。

あーしまったこの角度で撮るとせっかくのゆっこちゃんの肢体がー(棒)

STM32 Value Line Discovery(STM32VLDISCOVERY)をいろいろ使う

CQ出版より"世界の定番"との触れ込みで大々的に宣伝されたSTM32ディスカバリ本
が発売されました。これはSTM32F100RBT6が使用されたSTM32ValueLineDiscovery
基板を扱い初心者向けに解説されたものであります。
ちなみにSTM32なんちゃらディスカバリな基板はVL&L&F4と3種類あって、
"STM32ディスカバリ"と書かれてしまうとどれを指すのか非常にややこしい
のですがまぁそれは置いておいて…

以前からSTM32VLDiscovery基板については私も秋月さんからひっそりと販売されて
以来ちょこちょこと触れてきましたがこの基板に関する質問のメールをちらほらと
頂くようになったので改めて単独の記事として紹介したいと思います。
ちなみに便乗ではない！！

●FatFsとTFT-LCD表示のデモプログラム
私のブログでいうところのいつもののことですが、STM32を扱う中でごく基本的な
要素を抑えてあります。私の他の物と同じくChaN氏のLPC2388向けのFatFsの
プログラムをベースにしていますが、移植しやすいよう抽象度を上げています。

・フリーのコンパイラを使ったコマンドラインビルドに対応
・基板上のLED操作
・基板上のSW入力(外部4+1方向SWはオプションで)
・printf系標準関数がリターゲット可能なUART
(サイズ節約のためChaN氏のxprintfを割り振ってます)
・sprintf/malloc系標準関数のサポート
・systickとタイマを利用したAVR-Libcと同じ感覚で使えるDelay関数
・STM32間のポートの移植性を容易にしたFatFsのデバイス依存部
・容易に移植が可能なTFTLCD/OLED表示用ライブラリ
　SPI-LCDを使った時のブロック転送はDMA化可能。

ほかのマイコンからSTM32というかARMマイコンを始めた人が真っ先に
引っかかるのはsprintf/printf系標準関数がうまく動作しない点だとおもいます。
今となってはFAQレベルの事なのでここを熟読したり私のUARTへリターゲットしてる
部分のコードを読んでうまいこと動作させられるようにしてください。

上記のプログラムについては各ペリフェラルに対しポートの割り振りは
以下のようにしています。特筆すべき点は、後述するSWD接続のVersaloonを
使いデバッグすることに限定してSWDでは使用しないJTAGポートの一部を
SDカードアクセス用に割り振り、使用可能なI/Oをさらに確保したところでしょうか。

※1：STM32VL-Discoveryデータシートより引用・加筆。
※2：単にポート振っただけでSW入力や8bitLCD等実際使用してない個所あり。

定番のSPI接続のTFT-LCD(128x160)を動かしてみたところ。
ChaN氏のTJPegDecでjpeg画像を表示している最中です。

次回紹介予定の2.5元のi2c液晶モジュールも。素晴らしい掘り出し物です！

●STM32VL Discoveryに仕込まれてるSTLinkをVersaloon化
最早これも定番でしょう。STマイクロの**ディスカバリー系な基板にSTLinkとして
仕込まれているSTM32F103C8T6は各基板ごとに微妙にポートの配置が異なっていて
同じVersaloonのバイナリは使いまわしはできませんが、すでにVersaloon本家
ではSTM32VLDiscovery向けのファームウエアがサポートされています。

さて、肝心のVersaloon化の方法ですが本家ではDFU等のブートローダを
仕込まずに直接Versaloonのバイナリを書きこむようになっていますが、
私はアップデートを容易にするためにいつも通りのDFUを仕込むように
しました。以下に私が行った手順を示します。
DFU仕込まない場合は"1."の書き込み時にいきなり本家の方のSTM32VL
Discovery用のバイナリを書きこんでください
(この場合別途ビルドする必要あり)。

1.DFUを仕込む
　こちらにSTM32VLDiscovery用DFUブートローダのバイナリを用意しました。
　(Versaloon_DFU_Bootloader_for_STM32VLDiscovery_.zip) 最初に
　書いてください。
　書きこむ方法はSTLink等のフラッシュを書きこむ手段が別に用意
　されてる場合はそちらを使ってください。
　~~Jim氏のTakenApartの記事~~にSTLinkをつかった手順が示されていますので
　そちらの記事をもとにDFUブートローダを書きこんでください。

　また、STM32はこの基板が初めてでフラッシュを書きこむ手段を他に
　持ってない人は、UARTブートローダーを使う方法を、こちらの改造手順2～8を
　参照して書きこんでください。
　UARTブートローダを有効にするためのジャンパの引きまわしは
　STM32VLDiscovery基板上では以下の写真の通りとなります。
　
　この基板上では足あげ等の加工も水晶の付け替えも必要なく0.5mmピッチの
　足からリードを引き出すだけなのでまぁ楽勝ですね。
　DFUを書き込んだ後はもちろんジャンパをはずすのを忘れないで
　ください！

2.DFUを起動
　さて、DFUを書きこんだらPCに接続するわけですがSTM32VLDiscovery基板
　上では下画像のリセットボタンがDFUの起動キーとなります。
　リセットボタンを押しながらUSBケーブルでPCと接続してください。
　
　USBデバイスとしてDFUが認識されたら成功です。
　
　そうだね画像使いまわしだね。言い忘れてましたがDFUseをインストールした時に
　DFUドライバがインストールされますので忘れずにインストールして
　おいてください。

3.Versaloonを書き込み/起動
　STM32VLDsicovery用のVersaloonのDFUファイルは~~こちら~~に。書き込み方は
　ここの"14."を参考にしてください。でも向こうにあるDFUファイルは別物だから
　使っちゃだめです！
　書き終わったら基板を一度PCと切り離し、再度接続します。この時に
　Vesaloonとして認識されたら成功です。VersaloonはLibUSBが使用されて
　いますが、LibUSBのドライバはZadigでインストールした方が確実です。
20120105追:
　以前はSWDのジャンパはあべこべになっていましたが、現在では
　差し替え無しでそのまま使用できます。

4.Versaloon化したSTM32VLDiscovery基板上でターゲットのSTM32F100RBT6を
　デバッグ冒頭で述べたプログラムをビルド・書きこみを行うわけですが、
　用意するものはSTM32マイコンをビルドする環境のほかにVersaloonに対応
　した特別なOpenOCDが必要です。
　おもな手順はこちらとこちらですでに紹介しています。

てわけで丸投げしまくりのやっけつ手順になってしまいましたが簡単に改造
可能なので(自己責任の上で)お勧めします。
しかも今のVersaloonはUSB-CDCが同時に使用できる複合デバイス構成になって
いるため、これを利用してこの基板上でUARTの通信手段を完結させることが
できます♥

STM32F4シリーズを使ってみる3 -FatFsと下部レイヤ(SDIO・MMC)ドライバたちの実装-

来たぞー！
…って来たのはもう2週間以上前ですけど…
144PinのSTM32F4も手に入ったのでSTM32F2の時と同じく中華生基板に組んで
みました。STM32F2とF4はほとんど同じです。特にコードは上位互換があるので
回路を完全に合わせるとF2のコードがそのまま使用できちゃったりします。
まあでもさっさとCortex-M4F用にしてしまった方が良いでしょう。

↑ということでいつものChan氏のプログラムを走らせて
　みました。

特筆すべきはF2系では何とか動くものの安定していなかった48MHz動作の
SDIOがF4系では非常に安定してることで、SDカードとさらに大容量/高速な
データのやり取りができるようになっています。ただし高速なクロックに耐え
うるSDカードの選択は必須で、Class10のカードを必ず選んでください。
最近出回ってるUHS-1の奴は逆に駄目なものもありましたので幾つか購入して
試してみてください。あと当たり前のことですが、配線の引き回しももの
すごく重要なので注意してください。
↑でたらめ書いてました。SDカードの仕様上通常モード(NomalSpeed)は
　25MHzが上限値でSTM32F2/F4ではUSBとの共用を考えると24MHzが現実的に
　安定して動かせられるクロック上限となります。
　お詫びして訂正しましま。

んでもって前回さらっとお見せしたSTM32F4 Discoveryの方のいつものですが、
ちゃんとした実装にあたり、周辺にぶら下がってる回路の影響でどのように
構成すべきか悩みました。なぜならば…
SDIO : SDIO_CLKがCS43L22のSDINとかぶってるから使えない
FSMC : 肝心のnRDがCS43L22のResetに、nWRがUSBの過電流検出に被ってて(ry
　　　　その他諸々のペリフェラルが被ってて(ry
SPI3 : CS43L22がI2S3として使ってて(ryついでにI2C1も
SPI2 : MP45DT02がI2S2とし(ry
SPI1 : LIS302DLがSPI1(ry
…

まぢでひっぺがしたろかと思いましたが先に書いた通りSTM32F407ZGTが
手に入ったのでSTM32+SDIO+FATFS+FSMCの構成はこっちに実装してDiscoveryの
方は既存のペリフェラルと何とか共存する道を選んでみました。
てわけで妥協したのが以下のSTM32+MMC+FATFS+SPI-LCDのプラン…。

SDカード　: SPI1(LIS302DL(SPI通信)と共用)
TFT液晶　: SPI2(MP45DT02(I2S通信)と排他)
　　　　　　※STM32F4DiscoveryではSPITFT液晶のみ対応
その他　 : CS43L22は丸々残す！
　　　　　　UARTはUART2(TX:PA2 RX:PA3)
SDカードとSPITFT液晶はもちろんDMA化してあります。

TFT液晶がシリアルしか使えない上にMOSIがI2Sの入力とかぶってしまうので
MP45DT02とは排他になっていますが、必要な人はGPIOによるソフトSPI
(超遅いですが)で逃げてもよいと思います。
私のLCD表示ドライバは潰しが効くようにかなり柔軟にデバイス依存の部分を
作り込んであります。またSTM32F1系ではペリフェラルはひとかたまり単位で
しかリマップできない構成でしたが、F2系以降はピン単位で柔軟なリマップが
できるようになったのでみなさんもデータシートとにらめっこして工夫して
みてください。

とりあえずSTM32F4 Discovery上でこの構成でハード改造を行わずに音楽
再生はかろうじてできるでしょうか？
音再生関係の作り込みはこれからなのでがんばってみます！

てわけでいつものコードでSDカードの読み出し速度比較を行ってみました。
使用したカードはClass10が策定される前に販売されたATP製4GBClass6の
microSDです。

STM32F4Discovery上で組んだFatFsは先に書いた通りの構成ですが、SPI1は42MHz
まで叩きだせるので読み出し速度もめっちゃ速いです！(注：SDカードは選びます)
音楽再生程度ならもう十分な早さですね♥今回の実装に際してMMCのSTM32用
ドライバも移植性をかなり高めた作りにしてみました(もちろんDMA化も)!

ちなみにDMA化に際する注意事項ですが前回も言及していますが、CCM領域を
DMAの読み書き先として利用することは一切できません！STM32F4系でCCM
領域を高速なスタック領域として使用する前提でF2系から移植を考えた場合、
既存のプログラムがauto変数をDMAの読み書き先として定義されていると
特定困難な不具合に悩まされる可能性がありますのでよく吟味してください。

お次は中華生基板(STM32F407ZGT6)で組んだSDIOの読み出しスピードです。
上にも書いていますが、F2系ではコケまくって全く安定してなかった48MHzの
クロックでも安定してアクセスができるようになり、20MByte/Sec以上の
すさまじいスピードで読み出しが可能になりました♥ちなみにこの
基板上ではFSMCもDMA化してます！

バグ出しもほとんど終わり、最低限のドキュメントもそろいましたので
STM32F4 Discoveryと中華基板対応のいつものコードを公開します。
makeファイル内の定義でSTM32F4Discoveryと中華生基板のビルドを切り替える
ことができます。その他細かい部分のノウハウは口で説明するよりソース見て
もらった方が分かると思います。
~~だから誰か早くSTM32F4Discoverymp3プレーヤー作ってくだち！！~~
20121220追:
STM32F4Discovery用でMP3再生機能追加しました！

あ、お伝え忘れてました。今回の公開に当たってSTM32F2系とSTM32F107、そして
最近この検索ワードでアクセスが急増中のSTM32VLDiscovery向けのFatFs+液晶表示
プログラムも大幅に更新しておきました。
んでもってOpenOCD用Flash書き込みCFG群もSTM32F4xx用を追加しておきましたよぅ

STM32F4シリーズを使ってみる2 -STM32F4のメモリ構成を理解し基礎を作る-

20111201追：
最近複数の方からメールでご指摘いただきましたが、私はこのwikiとは関係ありません。
私の今回の記事からいくつかの文章を丸々コピペしていますが、私が後日誤りに
気付いて修正した内容が修正されずそのままになっていますので信用しないよう
注意してください。
20111201追：

今回は前回述べたとおり192kByteに増強された内蔵SRAMをどのように使うかを
決定し、お約束の標準関数の使用やFPUを用いた浮動小数点の計算をSTM32F4
Discovery上で実践してみます。

STM32F4系は192kByteのSRAMを持っていますが、実際は112kByte,16kByte,
64kByteの3ブロックに分かれています。後で図示しますが、112kByte分は
AHBバスマトリクスに接続された汎用SRAMで,16kByte分は同じくAHBバス
マトリクスに接続されているものの、112kByte分のSRAMと同時に読み書きが
できるように(主にEtherNetMAC&USB-OTG(HS)用に特化されているようです)
なっています。
アドレスは連続しているのでEthernetやUSB-OTG(HS)を使うつもりがない人は
128kByte分まるまる汎用SRAMとして使用することが出来ます。
その他細かい制約があるので各自データシートやマニュアルを参照のこと。
☝丸投げ

もうひとつの64kByte分はCore-Coupled Memory(CCM)と呼ばれ、Cortex-M4Fの
コアに直接接続されています。このSRAM領域はAHBバスマトリクス上にはなく、
DMAの読み書き先としてこの領域を使用できません！
(20111026追：実際に試しましたがHardFaultになったりDMAが完了
しなかったりで、やはりDMA用のメモリとして使用できませんでした）
また、128kByte分の汎用SRAMもSTM32F4のコアクロックと同様の168MHzで
アクセスできるので俗に言うTCM(Tightly-Coupled Memory)としての速度的
優位差もほとんどないでしょう。

以上の点を踏まえて、STM32F4系でつぶしが利くようにねむいさんはSRAMの
構成を下図のようにしてみました。

64kByteもある広大なスタック領域を君はどうつかうのか！？
注：CCM領域はDMAできません！！大事なことだから２度言います！！

この構想をリンカスクリプトに落とすと下図のような感じです。

この下にも長－く各セクションの定義が続きますが省略。
この構成で前回のTFT-LCDの表示テストも改めてクリア・またprintf系の
標準関数もUARTにリターゲットして動作を確認しました。

次にFPUを使って浮動小数点の演算のテストに取り掛かりました。
Cortex-M4Fは単精度の浮動小数点ユニットを持っています。GCCコンパイラから
この機能を使うためには浮動小数点命令に落とし込むようにフラグを与えて
あげないといけません。
具体的にどういうフラグを与えるかについては酔漢氏が昨年に考察されていました。
氏の情報を元に私の環境では以下の箇所の変更で単精度の浮動小数点命令に
切り替わりました。
-msoft-float("-mfloat-abi=soft"と同じ意味)
↓
-mfloat-abi=softfp -mfpu=fpv4-sp-d16

-mfpu=fpv4-sp-d16は必須です。これが無いと倍精度の命令を使ってしまい、
実行したとたんにHardFaultになってしまいます。

ちなみに-mfloat-abi=※※※※　の意味はそれぞれ以下のように表されます。
-mfloat-abi=soft　　：浮動小数点の演算に整数命令のみで構成された
　　　　　　　　　　　　　　　浮動小数点演算ライブラリ(soft-float)を使う。
-mfloat-abi=softfp　：浮動小数点の演算に浮動小数点演算命令を使うが、
　　　　　　　　　　　　　　　floatを引数にする関数の呼び出し規約はsoft-floatと
　　　　　　　　　　　　　　　同じく汎用レジスタを使って値を渡す。
　　　　　　　　　　　　　　　(↑この仕組みはソフトウエア・リンケージといいます)
-mfloat-abi=hard　　：浮動小数点の演算に浮動小数点演算命令を使い、
　　　　　　　　　　　　　　　floatを引数にする関数は浮動小数点レジスタを使って
　　　　　　　　　　　　　　　値を渡す。

酔漢氏のページでは"-mfloat-abi=hard"となっていました(GCC4.5.xからこの
オプションが利用可能)が、無償で利用できるSourceryCodebenchLite版にある
標準関数等のライブラリはsoft-floatでビルドされているため、標準関数を
絡めるとリンク時に引数渡しの不整合がおきてエラーになります。
これを回避するためにはCodebenchLite版のビルド済ライブラリを使わない設定
(-nostdlibオプションを付ける)を付与し、同じ機能を持つライブラリを一から
"-mfloat-abi=hard"でビルドしなおさなければなりません。
というわけでいちいちビルドするのめどいので以後は"-mfloat-abi=softfp"で。
20131226追:
GNU Tools for ARM Embedded Processorsなら"-mfloat-abi=hard"が
使用可能です！！

これでFPUの命令を含むプログラムがビルドできるようになりましためでたし
めでたし･･･と言いたいところだが！
ここも嵌ると思うので記しておきます。Cortex-M4Fの仕様によるとFPUは浮動
小数点命令が行われる前に(つまり起動時)に有効にしてやらないといけません。
STM32F4xxのサンプルではsystem_stm32f4xx.cのSystemInit()の最初で実行
されているものもありますが、テンプレートからsystem_stm32f4xx.cを生成
するとこの記述が欠けているのでほとんどの場合は自分で追加しないと
いけません。

☝のような感じでFPUの有効化を行ってください。

20120410変更：
実際にコンパイルオプションを変えて浮動小数点演算の箇所のアセンブラ
リストを比較してみました。Launchpad提供のGNUToolchainを使用しています。

●-mfloat-abi=soft

FPUを一切使用しない場合です。FPUのレジスタは一切使用されず、また
浮動小数点演算ルーチンが呼ばれています。

●-mfloat-abi=softfp -mfpu=fpv4-sp-d16

FPUを使用する場合(SoftFP)です。関数の値は汎用レジスタで渡されています。

●-mfloat-abi=hard -mfpu=fpv4-sp-d16

FPUを使用する場合(HardFP)です。関数の値もFPUレジスタで渡されています。

printf関数は暗黙の型変換によってfloat値を渡してもdouble型に強制変換
されます。単精度のFPUしかもたないSTM32F4ではdouble型に変換するための
__aeabi_f2dルーチンが必ず挿入されます。

ってわけでこれでほぼ完全にCortex-M4Fとして開発を行う下地が整いました！
現在はSDカードとSPI接続のTFT-LCDとUARTをつなげていつものをこしらえる
ところまで進みました。STM32F4 Discoveryの回路構成の都合で、SDIOとFSMCが
使用できないのでSDカードもTFTLCDもSPI接続です。
はやくこいこいSTM32F407ZGT6!

あ、そうそう、Chan氏のTJpegDecも組み込ませてもらってます。

STM32F4はぢめました

…きちゃった♥

…STM32F2すら使いこなせてないうちにCortex-M4コアのSTM32F4が来て
しまいました…！
CPUクロックが168MHzにアップした上にFPU&DSPユニットが付きさらに
メモリも192kByteまでお付けしてお値段据え置き(購入当時日本円換算で1280円)
ですって奥さん！！

チップ単体はまだ手に入らないので(これも時間の問題ですね)すが、
評価キットとしてSTからSTM32F4Discoveryがすでに販売されています。
この評価キットはI2SコーデックにMEMSセンサもついていてアナログ信号の
処理も手軽に扱えそうですていうかそういう風に使わざるを得ないでしょうね…
苦手ですが。

20111201追:
秋月さんからも1650円で販売されました!
20230709追:
うわぁああああ4600円になってるうぅうううう１！！１！！

てわけでさっそく動かしてみました。すでにSTM32F4Discoveryの
ファームウエアパッケージで予習済みなのでいつものTFT液晶を
使って何か表示するプログラムをビルドし書き込んでみます。

CodesourceryはすでにCortex-M4Fに対応しています。ビルドオプションと
しては少しの変更でビルド可能です。
(注:上記のオプションではまだ不完全で、FPUを使った演算になりません！
　　FPUを有効にする方法はこちらを)

STM32F2系(Cortex-M3)とアッパーコンパチであるため、OpenOCDはそのまま
読み書きとデバッグ(FPUレジスタ除く)を行うことが可能です！
ねむいさんはビルドしたプログラムの書き込みにVersaloonのSWDを使用しました。
(注：エラッタのせいでSTM32F2系とまったく同様のMCUIDとなっているようです。
　　　VersaloonはコアIDのほうは判別は行っていないようなので
　　　引っかかりませんでしたがFT2232系のJTAGアクセスではコアIDの判別に
　　　引っかかり、STM32F2系のcfgファイルのまんまだと警告を出しますが、
　　　先に述べたとおりアッパーコンパチのため、とくに実害はありません。
　　　私が公開しているOpenOCD用のCFGファイル群
　　　はすでにSTM32F4対応済です。)

びぃぶろくんが、かわかわ美人さんに欲情すると困るので小さく
20120124追：
Gaijinさんがinai-sanはHENTAIだって

とりあえず今回はほんのさわりだけですが、次回はせっかく192kByteに増強
してもアドレスが連続してるのは128kByte分でそのうちの16kByteはEthernet&
USBOTG-HSのDMA専用に事実上取られてしまうので実質112kByteで残りの
64kByteはバスマトリクス上にないから微妙に使いどころがないという
内蔵RAMの効率的な使い方とかをリンカスクリプトの組み方と交えて実践
していこうと思います！

STM32 EvoPrimerを買った...

世間ではSTM32F4シリーズが発表、音系に特化したSTM32F4Discovery
なんかももうすぐ手に入るようになった昨今ですが、８月末に秋月で纏め買い
してるついでに購入してしまいました･･･。こんなの買ってしまった時点で
｢私は情(に)弱(い)です｣って言ってる様なもんですね･･･orz
･･･まぁいいや。

↑STM32Primer1,2の後継となるEvoPrimerです。

↑今回のはCPUカードを差し替えることによりSTM32F103系、STM32F107系、
　STM8S系の評価を行うことが出来ます。
　逆に言うとEvoPrimer本体だけ買っても何も出来ません！

↑ねむいさんはSTM32F103VET6が載ったPrimer2を持ってるので
　STM32F107系のCPUカードを選択しました。

↑カードを挿して(めっちゃ硬い)真ん中のボタンを押すと"Welcome to STM32!"
　のボイスとともに初期設定画面がでます。ちなみに初回購入時はEvoPrimer本体
　からCPUカードからスタンバイ電源を供給するためのスイッチをONにして
　おかないと起動の度に初期設定をする羽目になるので注意です。

↑早速中身を開いてみました。
　QVGAの液晶やI2S等のデバイス盛りだくさんです。ちなみにこのQVGA液晶は
　ピンの設定で8bit,16bit,SPI(←これ重要)が使用可能な逸品です！

　液晶モジュールのデータシートを穴のあくほどよく見ましたがこの
　モジュールはSPIの設定はできるもののSDI/SDOのピンが出ておらず実質
　8/16bitしか使用できません。
　しかもEvoprimerとしては8bitバスしかサポートしてません。
　さらに言うとCタイプだと素直なピン配置になっておらず、わざわざ
　ビットシフトしてから書かなければならない回路構成になってやがるので
　描画がSPI並みにくそ遅いですorzorz
20130107衝撃の事実判明！！！
ちゃんと調査したところコントローラICはちゃんとILI9325でしたが、
なんとFPC内部でSDOがD0に、SDIがD1に直結されていてSPIでもデータの
読み書きが可能なことを確認しました！！！！

↑STM32Primer2で致命的となってしまった電源回路ですが、回路図を
　見渡す限りでは対策がされている様なので今回は大丈夫だと思いますよ。
　た　ぶ　ん

↑STM32Primer2と並んで動かしたところ。
　一回りおっきくなってて持ち運びができません…。

その他EvoPrimerと同じく買ってたもののまったく触っていない物達･･･

↑LPC1227LPCXPresso(上)とLPC11U14LPCXPresso(下)ですって奥さん！

　11U14の方って反対側にUSBminiBコネクタついてるわりには3.3Vの
　レギュレータ無いからうかつに切り離せられないじゃないですかーやだー！
　
　あとXmegaでよく分かられたとは思いますがねむいさんはLPC系の
　ARMマイコンでDMAを使いこなす知能がないのでLPC1227の方はあつ氏や
　todotani氏の作例を参考に弄ってみようと思います。

　ちなみに上記二つのデバイスはSWD接続しかなく、まだVersaloonが
　対応してないので手も足も出ません！･･･といいたいところですが･･･(下記に続く)

↑お次は台湾NuVoton製のcortex-M0マイコン、NUC120さんだ！
　基本的なドキュメントやサンプルコードは出揃ってるのでこちらも
　時間を見て･･･もちろんまったく触ってま(ry

　ちなみに書き込みはNulinkと呼ばれるSWD接続可能なライタです。
　KeilやIAR等の開発環境からしか使えないと思いきやCooCoxのCoFlashという
　フラッシュ書き込み専用ツールを使うとスタンドアロンで書き込みできたり
　します♥
　

↑このCoFlashというツールですがハードウエアが上記のNulinkに加え、
　JTAGkey,JTAGkey2やST-Link等の有名どころにも対応してるので書き込み専用
　としてもかなり使えると思います！

↑これも脊髄反射で購入してしまった･･･
　ほんっとマイコンしか触ってない私ですがFPGA忘れてしまわないうちに
　何とかしたいですはい･･･

STM32F2シリーズを使ってみる3

4月から本当に少しずつ使い始めたSTM32F207ですが、公式の方もやっとこ
資料が出そろってきてだいぶ扱い方が理解できるようになってきました。

とりあえず一つの通過点ということでいつものchan氏のLPC2388向けのFatFs
+OLED表示プログラムの移植をしました(ほとんど原形とどめてませんが…)。
いろいろやってきた中でjpegデコーダ乗せたり(デコードが1.8倍速くなってる!)
FONTX2の使い方覚えたりで今回はM+フォント(FONTX2)を使いFilerの
日本語表示を可能にしてみました。

↑やっとここまでこれた…
なんと当のchan氏も6/11更新のLPC2368向けFatFsサンプルでFilerの
日本語化をされていたようで今度はこちらを元にしておりぢなるなFilerの
構想を練っていきたいと思います。

そうそう、気になるFatFsの読み取り速度ですが、SDIOが出せる最高速度の
48MHzまでクロックを引き上げた場合、最大21MB/Secを叩き出すことが
できました！

↑てかいつも比較に使ってるATP製のmicroSDカードもすごい…class6なのに。
しかし、48MHz動作は8bitモードしか保証していない(rm0033.pdfより)ので
sdカードで使うときは実際は24MHzで動かすことになるのですが
…それでも十分早いですね。

おきばにはすでに上記で紹介したSTM32F207ZGT6向けのプログラムを
公開しています。これはPowerAVR製の紅牛(もとはSTM32F103ZET6)という
ボードの回路互換となっています。
ねむいさんSTM32F2向けに備えてかなり前にtaobaoで部品未実装の基板
"だけ"超安価で購入していました。てわけでホントに最低限のことしか
できないのですがF2を試すに当たってはこっちの方が幾分都合がよいのです。

ここからどんどん付け足していきます

またmakeファイル内の定義の書き換えによって以前使っていたSTM32F207VGT6
向けにも対応できます。
STM32F207VGT6の方はこちらの(STM32F103VET6)ボードの
回路互換です。両者に共通するのはFSMCのピンが引き出されていて出来合いの
LCDボードが直結できるという点に尽きます
(☝TFT-LCDマニアな人には超重要なファクター)。
まぁデータシートで1xx系とのピンの処理方法の違いとかとか
詳しく解説されていますんで・・・・、
日頃ねむいさんのぶろぐ読んでる人なら簡単に乗せ換え可能でしょう。

あと開発環境のtipsとして、前回も説明しましたがCodeSourceryG++等の
ポピュラーなGCC開発環境はそのまま使用できます。Cortex-M3対応なら
何でもよいでしょう。問題は書き込み環境ですが…20110619現在はシステム
メモリ上のブートローダから使用できるフリーのツールがまだ整わず、
よってJTAG/SWDからしか書き込む方法がありません。幸いOpenOCDの0.5.x系と
VersaloonはすでにSTM32F2系のフラッシュの書き込みに対応しています。
私もフラッシュ書き込み用のOpenOCDコンフィグを公開していますのでJTAGな
いしはSWDでつなげられるアダプタ持ってる人は開発に際して問題はないです。

最後に、次回予定のLPC2388関連の記事で詳しく解説しますが、64bit版
Windows7環境下のビルドにもmakefileの設定で対応できるようにしてあります。
副業先のポジションとPC環境がガラッと変わったのでねむいさんも必要に
迫られてというのもあったりしてます。
ねむいさんとうとう従業員Bから晴れてエンジニアにじょぶちぇんぢ！
(やってること相変わらず雑用だが)

おまけ：
aitendoさんからついにあの扱いやすいSPI液晶が販売されましたね。
以前私が説明した奴です。これ使ったシールドとかも海外ではもうすでに販売されて
ますが、TFT-LCD Shieldを開発した時の生基板を利用して無理やり乗っけてみました！

次はこれで行こう。

そしてaitendoさんからはもう一つQCIFサイズのタッチパッドつきの液晶が発売されま
した。これ確かtaobaoで捨て値で売られてて私も10枚くらいまとめて買って動かして
(飽きて放置)してました。これ8/16bit選択できるのは良いのですが、ピン間隔が0.7mm
なので手配線ではきつい人がいるかもしれないですね。専用の変換ボード出るの待った
方が良いと思います。どちらかというと…、

こっちとか

こっちとか

こっち
の方がピン間広いし8bit固定で小難しいこと考えなくて良くてよいと思います。
思いますよぅ！！(重文)

↑AS021350DをXMEGAで動かしてみたところ。
実はATXMEGA128A1にもchanさんのFilerを日本語対応して移植に成功してます。
~~しかしXMEGAはFatFsを結局DMA化できないまま白旗降ってクローズします…。~~
20230701追:
DMA化してSRAMも外付けしましたよう！！！！！！！！！１！！！

STM32F2シリーズを使ってみる2

てなわけで前回の記事からはや一ヶ月、手探り状態でいろいろ進めているうちに
ST公式でやっとこF-2デバイス用のペリフェラルライブラリが出たり

BeableBoardXM購入合戦に勝利したもののまったく火入れしてなかったり

ALTERAのFPGA評価ボード買ったり

ステーション型はんだごて購入したり

USB接続型PCオシロスコープPicoscope3206Aを破格値でゲッツしたり
探訪も笠置まで進んでたりそうこうしてるうちにSTM32F2シリーズも
普通に購入できるようになってたりする昨今、いかがお過ごしでしょうか？
震災を境に身の回りの状況が一変してしまいましたが、ねむいさんはいない
さんをひざに乗せてくんかくんかしつつできることから着々と取り組んでいく
所存でございます。

勘違いや無知無学が祟って時間を食ってしまいましたが、STM32F207VGT6で
SDIOとChan氏謹製のFatFsを連結させて安定動作できるまでになりました。
SDIOはもちろんDMAを使って高速に転送可能です♥
以前のSTM32F103VET6のものと同じ条件でReadの速度を比べると若干の
向上が得られました！

SDカードだとSDIOは25MHzまでしか出なかったり(MAX48MHz)カード自身の
転送速度もボトルネックになってるとは思いますが、小規模のマイコンで
もこんだけ早かったら御の字ですよね～。

さらに前回ちょろっと紹介しましたが480x272pixelの4.3inchTFT-LCDの
ドライバも組み込んで"いつもの"をやってみました。こちらもFSMC使った
高速転送です！
ねむいさんへたれだからSSD1963っていうコントローラつきの液晶モジュール
基板使ってますが･･･。

↑タッチパネル入力にももちろん対応。

↑再びぽぽぽーん
STM32F2になってフラッシュも1MByteまで増えたことだし、フォントも扱える
ようになって機は熟したからそろそろ私もChan氏のファイラーは卒業して
おりぢなるなファイラーを作ろうかな、と。

んでもってSDIOとFSMCの高速な転送を利用して動画再生も試みました。
Chan氏のLPC2388向けの動作再生ルーチンをチューンアップしないでまんま
利用してもQVGAサイズで29.97fpsな動画も余裕で再生できたので相当
"ぱわふりゃーなので余裕"なの確認できました。
やっけつだけど一番乗りだからどっかにアップしたいな～

とりあえず次の一手としてはオリジナルなファイラーの実装に着手しつつ
先日がた老氏FreeRTOSがらみの質問をもらった機会にご無沙汰だったRTOSの
おべんきょもふたたび進めていくつもりです(BeagleBoard-xMとDE0-Nano
から目を逸らしながら)。

おまけ：
て言うかこっからが本題です！！！！
LatticeのispVMがいつの間にかFT2232デバイスに対応していた件
いままでsvfとかUrJTAGとか使って手間のかかる方法しかできなかったのが
嘘のようです！もうこれでLPTポート無くてもいいです！

↑ふつーに認識

↑そしてふつーに書き込み
JTAGkey2Cloneで使うためにはJTAGのOEを常時イネーブルにしておく
必要があります。※ispVMに対応するようにスルーモードをつけて
回路図差し替えときます。

もちろん外付けSPI-ROMにも書き込むことができます♥ispVMは多種の
SPI-ROMに対応しているわけですが･･･つまりこれはLatticeのデバイスが
JTAGで繋がってればUSB接続のSPI-ROMライタが安価にかつ確実に構築
できるというものすごいことでまさに神対応なわけなのです！！
これでマザボのBIOSいくらすっ飛ばして怖くない！
xilinxさんやalteraさんもこういうの見習ったらｲｲﾅｰ
･･･絶対ありえないですが…

STM32F207はぢめました

ﾂｲﾆｷﾀﾖｰ
去年くらいに発表されて以来トンと音沙汰なかったですけどES品ですがやっっと
一般ユーザの手にもわたり始めましたSTM32 F-2シリーズ。
従来のSTM32と違う部分は最大動作周波数が120MHzまで増加したのとメモリ保護
ユニットがついたのとフラッシュアクセラレータが(やっと)強化されて120MHzまで
ノーウエイトで動作可能となったのとその他諸々のペリフェラル機能が追加された
点しょうか。
ライバルに相当するLPC1769も似たような機能をすでに備えているのでいまさら
目新しものではなくなってしまいましたがー…。あ、そうそうフラッシュ容量も
1MBまで増加してます。低速な外付けのメモリとか用意しないでも結構でかい
サイズのフォントもぶち込めるのがうれしいです。

てわけでさっそく使用してみましたが、STM32F107VCT6とは一部ピンの定義が
違います。そこだけ注意してデータシートのmigration guideを参考に
配線を変更しました。

使用したボードは元はSTM32F103VET6が乗っかっていたebayで格安で購入した
基板です。STM32F207からはFSMCが使えるので(←これ重要!)あえてこのボードを
選びました。

次に開発環境ですが、もちろん従来から使ってきたCodesourceryG++を使用
します。しかしまだSTマイクロの公式サイトではF-2デバイス用のペリフェラ
ルライブラリなんぞは用意されていない(10x系とはレジスタ定義は全く違う)
のでKEILのサンプルに含まれているF-2用のbeta版に当たるV0.01と記された
定義ファイルのみと上記のごく簡単なサンプルコードを頼りに手探りで
進めていきました。

ちなみにフラッシュの書き込みもF-2デバイスは手順が違うようでOpenOCD
ではSTM32F1xx系とは別に用意されていました。後述しますがOpenOCDは
STM32F103xF/G系の512kByte以上のフラッシュを持つ種への書き込みも対応
しています…これはありがたい。

書き込み時はこんな感じです。

ぽぽぽぽーんと動かしてみたところです。480x272も一瞬だわ…
流石120MHzとFSMC…。そして国内のホビーユーザーでF2のデバイス動かした
人間としては今度こそねむいさんが初めての人ですね！一番乗り！
次はSDIOに進みたいところですが、上で述べたとおりライブラリが無い状態
なので手探りで進むことになりそうです。まぁ10x系のものを参考にしたら
何とかなるでしょう。
実はここまで動かすレベルになるのにかなり手間かかった…
何せ資料が全くない…。

おまけ

2xx系はまだまだですが、512kByte以上のフラッシュ容量をもつ10x系の
STM32マイコンはすでにdigikeyやmouserで購入可能です。ねむいさんも
速効ひとつ購入してしまった。1年くらい前にtaobaoでSTM32用の格安の
空基板買っといたのがやっとこ日の目を見れましたのでこっちにさっそく
装着。単にフラッシュ容量が増えただけなので従来のライブラリが
そのまま転用できて動作の確認が非常にラクです♥

お約束カワウソ。

SWD専用Versaloonクックブック

20120210追:
OpenOCDが0.6.0の2月以降のコミットでSTlink&STLink/v2の素のハードウエアに
対応しました!!もはやVersaloon化すら必要ありません！！

20110829追:
Versaloon本家の対応により、STM8S/STM32Discoveryに組み込まれたSTLink
のハードウエアにもめでたく対応となりました！！以下に長々と書いているかなり
無理やりなハードウエアの改造は、現在行わなくても済むようになっています！
それでもねむいさん(の方法)がだいすきなんだーい！って言う人だけ読んでください！

デバッガを備えた扱いやすい32ビットのプロトタイプボードたちが群雄割拠する現在、
彗星のごとく電子工作シーンに現れそのまま大気圏に突入して消滅した
STM8S-Discoveryには32bitMCUを使用した2線式デバッガハードウエアSTLinkが
搭載されています。

このSTLinkの本体はSTM32F103C8T6というSTM32のARMマイコンで、これは
Versaloonというリソースが公開された汎用のデバッガハードウエアにも使用されて
いるものです。
今回は、そのままでは糞の役にも立たないSTM8S-DiscoveryのSTLink部分に
物理的改造を施し、SWD接続専用の簡易Versaloonとして再生する手順を
紹介します。

注：制限事項
　・この改造はVersaloon-miniのハードウエア互換にする改造です。
　・VersaloonはARMの他に多数のマイコンをサポートしているが
　　この改造はARMの、それもCortex-Mx専用になります！
　・てわけでSWD接続以外の接続はできない(ていうかできねぇ！)
　・頑張ってTDIとかTDOとか引き出せばJTAG接続も使えるけど
　　すごいめどいからやらないよ！
　・3.3V以外の信号レベルでは接続できない(一応5Vトレラント)
　・作業工程はWindowsXP以降の環境を使用。Windows7x64環境でも動作します！
　・真似して改造して基板がゴミになっても泣かない
　・ていうかJTAGKey/JTAGKey2Cloneをすでに持ってる方の補助的な位置づけです。
　・ハードの改造がめどいですという方はiruka氏のオレオレblaster化をお勧めします。
　・SWD専用ですが、本家の対応でめでたくSTM8S/STM32DiscoveryのSTLink
　　のハードウエアにも対応となりました！！↓に長々と書いているハードの改造を
　　無理にしなくても済むようになっています！大事なことなので2度言います！

●必要なもの
　1.STM8S-Discovery
　　これが無いと話になりませんね。750円でSTM32単体買うより安いです。
　　必要部品はすでに乗っていて一から回路起こすより断然楽です！

　2.12MHzのクリスタル
　　Versaloonの標準的なハードウエアは12MHzの外部クロックが必要です。
　　STM32の103系って標準が8MHzなはずだが…
　　ソフトが苦手なねむいさんとしてはハードウエアの方をカチ合わせる方
　　針で改造を進めます！いちいち修正してビルドするのめんどいし！

　3.チップ抵抗
　　1608~2012メトリックの100ohmを2つ・10kohmを3つ。これはポート保護&
　　フローティング時の信号レベル固定用です。

　4.1列ピンヘッダ
　　SWDやUARTの信号を外部に引き出す用途に使用します。

　5.0.26mm位のUEW・AWG26位のジャンパ線
　　UEWは48PinTQFPから足を引き出したりジャンパしたりに使用します。
　　ジャンパ線は3.3Vの電源ラインをバイパスするのに使用します。

　6.USB-シリアル変換若しくはパソコンとUARTで通信できる何らかの装備
　　改造工程でUARTによるブートローダを立ち上げてDFUを書き込む必要があります。
　　もちろん信号レベルはTTLレベルに各自で合わせておいてください。
　　(JTAGでも書き換えられますがここでは触れません)

　　また、DFUを書き込むためにPC側のプログラムはFlashLoaderDemonstratorを使用
　　しますので各自インストールしておいてください。
　　DFUを書き込んだ後はDfuSeを使いVersaloon本体を書き込みます。同じくインス
　　トールしておいてください。

　7.2.54mmピッチのショートピン
　　パソコンでも使用する標準的なショートピンを。STM8S基板にひっついている奴を
　　流用しましょう。

　8.TQFP(0.5mmピッチ)の足を上げたりはんだつけしたりが余裕で出来る技能
　　まぁこのブログを普段から見られている方はデフォで出来るでしょうからからあ
　　えて言わずもがなですね…(カメラ目線)

●改造手順
　※一気に改造するとなにが悪かったのか切り分けできなくなるので
　　逐次動作確認を行い、改造していきます。

　1.先ずSTM8S-Discoveryのミシン目をカットしSTLinkと燃えないゴミにわけます。
　　

　2.次にUART用のPinをUEW線にハンダ付けで繋げ、外部に引き出します。
　　

　3."2."で引き出したUARTのピンはピンヘッダを使って外部に出しましょう。
　　UART-TX(TxD)は10kohmで必ずプルアップしてください。
　　

　4.丸内の部分をジャンパします。ここから+3.3Vを外部に出したいなんて人は
　　AWG24位の太い線でジャンパしましょう
　　

　5.次に丸内のBOOT0のPinに当たる部分を丸内の+3.3Vラインに
　　ジャンパで飛ばします。
　　

　6.USBシリアル変換と"3."で付けたピンをTxDとRxDに注意して接続します。
　　そしてSTLink側のUSBコネクタをPCに挿しこみます。
　　USBデバイスが認識されないエラーがでますが無視で。

　7.FlashLoaderDemonstratorを起動します。STM32のUARTブートローダーが正しく
　　起動していればこの画面が見えるはずです。操作法などの細かい説明はこちら
　　にうっちゃりますが、先ずここでDFUのプログラム
　　(Versaloon_DFU_Bootloader.zip)を書き込みます。
　　STLinkのファームウエアははこの時点で消去されてしまいます。
　　
　　
　　

　8.元STLinkをPCから外し、"5."で行ったジャンパはもう必要ないので外します。
　　てか外さないと何やってもSTM32のUARTブートローダーが立ちあがっています。
　　

　9.次に書きこんだDFUの起動確認を行います。クリスタルを8MHzのものから12MHzの
　　ものに差し替えます。丸内の箇所にショートピンを挿し替えます。
　　

　10.再び元STLinkとPCをUSBケーブルで接続します。USBデバイスとしてDFUが認識
　　されたらOKです。まだVersaloon本体は書きません！
　　

　11.DFUが起動するのを確認したら一旦PCから抜きます。Versaloon本体を書く前に、
　　SWDを外部に引き出すための改造をします。四角内の部分の足を丁寧に上げます。
　　

　12.足を持ち上げたらまとめてUEW線をハンダ付けして引き出します。
　　

　13.ターゲットにSWD接続を行うためのピンを引き出します。JTAG用のポートが
　　余っているのでこれを利用しましょう。
　　VersaloonはPB6,PB7をSWDIO用,PB13をSWCLK用のポートとして
　　使用します。図中の表記はこれに倣っていますので間違えないように
　　してください。
　　
　　
　　
　　
　　

　14.SWDに使うポートを引き出す改造が終わったら"10.の操作を再び行いDFUを
　　認識させます。そして"DfuSe Demonstrationを立ち上げ、
　　~~Versaloon本体のDFUファイル~~を書き込みます。
　　

　15.書き終わったらUSBケーブルを外し、"14."で行ったショートピンを
　　丸内の位置にします。以後Versaloonのプログラム本体の書き換えは
　　 DFU経由で行います。

　16.再度元STLinkとPCをUSBケーブルで接続します。USBデバイスとして、今度は
　　Versaloonが認識されたらOKです。~~LibUSBのドライバを読み込ませてください。~~
　　非常に操作が簡単なzadigを使ってLibUSBのドライバをインストールしてください。
　　
　　

　17.vsprog等を使用しSWDで繋がるCortex-Mx系のマイコン
　　(LPC1xxx,STM32,ATSAM3x,etc)でVersaloonが使用できるか確認します。
　　結線さえあっていればこの時点でSWD接続で操作できます。
　　JTAGのTMS = SWDのSWDIO
　　JTAGのTCK = SWDのSWCLK
　　
　　Simonquian氏のページで配布しているvsprog/vsgui等のソースをビルドして
　　利用するかSWDのパッチを当てたOpenOCDをビルドし使用しましょう。
　　おや…これは…

…というわけで余り物の材料かき集めたら1000円以内でCortex-Mx系の
ライタ/デバッガが手に入ってしまいます。STM8S-Discoveryを買って
しまった人は玉砕覚悟でVersaloonへの改造を試してみてはいかがでしょうか？

20230819追：
上記で紹介したDFUファイルやVersaloonプロジェクトは公開終了しました。
もし今の世でVersaloon作ってみたいなんて方はねむいさんに連絡ください。

いないさんのおしりに顔をうずめてくんかくんかしたい

※今日の日記は7月上旬くらいまでの内容です

(いないさんの)ぱんつだけカフェ…ぱんつだけカフェ…ぐふふ…
……おお失礼、ここ最近副業先の会社近くのカプセルホテルで寝泊まりするような
生活になってから意識が夢うつつな状況が多くなって…
(注：6月末～7月上旬の頃の話です(重文))

最初はTFT液晶モジュール使ってなんか作るのが目的のはずでしたが今やいろんな種類
のモジュールを手にいれて動かすこと''だけ''が目的になってしまっています…。
でも8~16bitバスorSPI制御タイプのモジュールはあらかたやりつくしたのでそろそろ次
の段階に進もうかなと思っています(←同じこと言ってばっかですがー)

さて今回も、前回taobaoやaitendoで購入した液晶モジュールの火入れをやってきたい
と思います。まずは国内でも売られているのでご存知の方も多いでしょうけど3.5inch,
QVGAな少し大きめのモジュールを…。

コントローラICはSSD2119。8,16bitバス&SPI&(改造でRGB)も制御に使用できます。

いつものごとくSTM32で…powerMCU製のTFT液晶モジュール基板はコネクタに
出ている足配置が2.8,3.2,3.5"とすべて共通で、後はプログラムをこさえる
だけなので楽です。
…と思いきや3.5"のモジュールだけタッチパネルのPENIRQポート番号が
違ってました！！いやぁ慣れって怖いですねぇ…(しれっと)

てわけでタッチパネル制御も…コンパイルオプションでタテヨコ対応です。
STM32ライブラリのバージョンも上がったことだしそろそろSTM32/LPC2388用の
液晶モジュール制御プログラムも更新しましょうかね。

液晶モジュール&SSD2119のデータシートを眺めているとこのモデルは上記
CPUバス・SPIバスインターフェースの他にもSH2Aで使えるRGBインター
フェースも使用できるようです。
ただし基板には足が出ていないので自分で残りの足が出るように改造する
必要がありますね。まぁこちらは追々と…。

次に3.0inchでWQVGA(240x400)の縦長なLCDモジュールです。これはモジュールの
データシートを貰うことができませんでしたが、ネット上には同じ型種のモデルが
存在しピン配置も容易に推測できます。IM0,IM1が外部に引き出されており、
8bit,16bit,18bitCPUバスで制御可能です。コントローラはR61509Vだそうです。
得体が知れないのでタッチパネルが無い安い方を購入しましたが
案の定バリバリのユーズド品でした…。

16:9のWQVGAな画面を利用して某シングルCDのジャケットを…ドンピシャの画像…
↓

今の若い子って(まぁ私もわかいですけお)シングルCDとか知ってるのかしら…あ、
…失礼、さぁ次、次…(使ってるうちに反射板が剥がれました。なんじゃこりゃorz)

最後にaitendoさんで20%引きセールやってた頃に購入した0.94inch,96x64ピクセルの
OLEDモジュールALO-095BWNN-J9を。こちらはキャリーボードとセットも販売されて
いて、なぜかセットで購入した方がOLEDモジュール単体で買うより非常に格安でお得と
なっています(2010/07/05現在)
…？？？何で？？値段設定間違えてる？？それともセットのはなんかの不具合品？？

まぁいいや、STM32でとにかく動かしてみました。現在Lynx-EyED氏も活用されて
いますね。このモジュールは8bitCPUバスでも行けますがピクセル数が少ないのでSPIの方が
繋げる線も少なく楽でしょう。

ちっさ！めっちゃちっさ！…いつも3.2inchとか弄ってるのでやたら小さいです。

それとLynx-EyED氏も経験されてしまってるようですが、私もOLEDは焼きつくという
事実をすっかり忘れてしまっていて、冒頭のいないさんの臀部の絵を表示したまま
うっかり放置して焼きつかせてしまいました！！！みんなも気をつけよう！

…とまあ液晶モジュールはこのくらいにして次回は塩漬けにしていた各種評価ボードを
消化していこうと思います。

まずはCortex-M0なLPC1114のボード…

つずく

ペプシバオバブ

20101228追：
MCUバス接続タイプのTFTLCDモジュールを動かしたい奴は必ず読め！！１１！

※内容的には4月下旬の頃ものです。古いです。

ぉ…結構いけるじゃん！
何時も二度と飲みたくないような味だったのにこれはイケるんじゃないでしょうか！？
コンビニにも今も置いてます♥

とりあえず生存確認の為に月一くらいは更新したかった今日この頃(駄目だったけど)。
春先にtaobao経由で安価な電子デバイスをたんまり購入しました。主な目的はaitendo
でも未だ手に入らない3.2inchの液晶モジュールだったわけですが壊したれたのと
全く同一の物が運よく見つかったおかげで復活しました。

●牙復ッ活ッ！刃●復ッ活ッ
考えて数揃えて買うと輸送量+手数料合わせても国内で少量買うより滅茶苦茶安く
つきますね…感動的だな。

ついでに目を引いた幾つかの液晶モジュール(そうだよまただよ)も買ったのですが、
これには罠が待ち受けていました…。

先ずはこれ。上で述べたものとは別の種類のさらに安価な3.2inchのTP付きな
液晶モジュールで、交渉のさいにモジュールコントローラICをILI9320と
指定して購入しました。
しかし…実際に届いたブツはILI9320用の初期化コードではどうしても動かず、
コントローラのIDを読みだしたりして(JTAGkey2+OpenOCD+insightのデバッグが
すごく役に立った)調べた結果、R61505UというILI9320と一部動作互換のICで
あることが分かり、モロに足止めを食らってしまいました…。
一瞬フェイクつかまされたかとビビってしまいましたが、初期化手順を正しく
行うとしっかり動いてくれて使えることがわかったので…まぁいい経験になりました。
20100817追：
3.0インチ以上は16bitバス制御しかできないモジュールが多いのですが、なんと
こいつにはバス幅を切り換える抵抗が存在していました！！
一気に使える液晶モジュールに！！
ちなみにaitendoの3.2inchQVGAの奴は出来ないです

いつもの。

んでもってタッチパネル(触摸屏)付きなのでBlueScreenの凡例をお手本にさせてもらっ
てタッチスクリーンセンサADS7843を使用したタッチパネル入力化にもやっとこ対応。

次にこちら。QVGAなLCDモジュールで国内でも手に入りやすく扱いやすいものは
8/16bitのCPUバスな物しか選択肢が有りません。こちらはそれに加え、なんと
SPI/RGBインターフェースによる制御も可能な一品です！
いろいろできそうだと勇んで6個くらい購入してしまいました！しかし…
実際に使用してみてわかったのですが、動作が安定しません…具体的にどういうことか
というと電源投入して約5秒以内に初期化動作に入らないとコントローラIC(LGDP4531)
がやたらと過熱しだして暴走状態になり、何やっても画面が真っ白のままと
なってしまいます。そしてその状態に一度はいるとモジュール内の残存電圧が
抜けきるまで電源落としてほっとかないと電源再投入後また即暴走の憂き目に…。

私にも落ち度があるのかと↓の項目いろいろ試してみましたが改善しませんでした…。
未使用ピンを全部GND直結->×
未使用ピンを全部VCC直結->×
スタンバイモードになってなくてもとりあえず強制解除操作->×
RESET端子にRESETICを付けてPOR出来るようにしてオープンドレインで制御->x
マイコンのVCCを3.3Vから2.8Vに落とす->×
MicroChipが配布しているグラフィックライブラリのLGDP4531用初期化コード->x(ｵｲ)

同モジュールが乗った出来合いの基板も購入したのですが結果は同じでした。つまり
モジュールそのものに問題があるっぽいです…。(初期化手順が不完全なだけか
もしれませんが、これ以上は情報が少なくて手出しができません)このモジュールを使用して
いる他の方も(Unstable)とされてますから同じ問題に直面されているようですね…。

20190726追：
9年の時を越えついに安定動作せしめる方法が判明しました！！！！！！！１１！！１
3.3V系ならばLGDP4531のLCDに供給する電圧をシリコンダイオード
とかで0.6V分おとして2.7Vくらい、2.8V以下で駆動させればOKです！！！！
こんなん分かるか！！１１１！！！！
20190726追：
まぁ一応電源投入してすぐに初期化動作を行うということを守れば言うこと聞いてくれる
ので、自分の中でだけテストするのであれば問題ないのですが…現時点ではこれ使って
売り物製作るのは無理っぽorz　以下にいくつかのモードで動かした画面をば…。

↑STM32F107VCT6でソフトウエアSPIモード
READして帰ってくるデータのバイトオーダーがデータシートの記述と違うんだが
…おいおい

↑STM32F107VCT6で16-bit,i8080cpuバスモード。出来合いボードの方。
ゆっこちゃんかわかわ

↑LPC2388で8-bit,i8080cpuバスモード,伝説のデス○リOP動画再生。
LGDP4531はさきに紹介したR61505Uと同じくILI932xと一部動作互換です。
動作不安定なトコ以外は。なんとかならないだろうか…。

つづく

またTFT液晶モジュールかよ

20101228追：
MCUバス接続タイプのTFTLCDモジュールを動かしたい奴は必ず読め！！１１！

…
え？この前買った3.2"の中華製TFT液晶どうしたって？
…どうしたもこうしたも…
"ワタシ大陸に帰るアル"って言って去っていきましたよぅ…
……さよなら5980円！！！！

…さて、つぶしｔ去っていった液晶さんの代わりにaitendoさんから
2.8"のTFT液晶モジュールEGO028Q02を購入しました…。
コントローラICは前回使用した2.4"TFT液晶モジュール
YHY024006Aと同じILI9325です。

コントローラICが同じだから前回のと同じソースコードが使えるかなと思って繋いで
試して見るとお案の定同じでふつーに表示できました！今までで一番楽だったです。
公開しているおソースは試用にあたって気づいたバグや記述ミスも順次つぶして
更新を続けていますが、試される方は自己責任でどうぞ。

↑まずはいつもの癒し系小動物を。

そしていつもはいないさんのえろす絵でお約束するのですが2/9に彼女が20歳の誕生日
を迎えたこともあって今回は真面目に行きます！おめでとう！ぐふふ…
見えてる方の画像は虹裏に投下していますのでびぃぶろぐでは無害です…無害です！

…さぁつぎいってみようか…えっと…今回はaitendoさんからは変換基板は販売され
てないので自分でユニバーサル基板使って製作しました。この基板は秋月の定番のや
つですね～。

↑まぁお試しなので広めにとっています。広いとミスも減って組みやすいですし。

↑裏にはバックライトLEDドライバとタッチスクリーンICのADS7843を載せています。
　ADS7843のおべんきょはこれからです。

また、今回の液晶を使用するにあたり、同じくEGO028Q02を試用しているそら氏より
YHY024006Aと同じく8bitバス幅でアクセスできる手法を教えてもらいました。
XMEGAみたいな8bitマイコンでも動かすことができるようにIM0端子を細工して外部
からプルアップ/ダウンでデータバス幅を切りかえられるようにしています。

↑EGO028Q02を改造したついでにYHY024006Aも同じ改造を。こちらはADS7843は無しです。

実物見た方は分かると思うんですけどね、データシート上ではIM0端子が出ているよ
うな感じがするんですが実際はNCなんですよね(中華サイトを巡るとNCと明確に記述
されてる同型異番種の物が存在する)…
以前触ったH161T01やYHY024006Aもそうですが、この辺実にチャイナクオリてi(ry

aitendoさんのTFT液晶モジュールを使う2

20101228追：
MCUバス接続タイプのTFTLCDモジュールを動かしたい奴は必ず読め！！１１！

aitendoさんから抵抗膜式タッチスクリーン付きの2.4inchTFTモジュール、
YHY024006Aが販売されました。そろそろコントローラIC付きのおっきい液晶を
と考えていてのでねむいさんはすぐに飛びつきました！
この液晶モジュール単体は某中華製エミュレータ端末(コントローラICが同じかも）
やDSO nanoにも使用されているそうです。

データバスは8,16bitが選択できると書かれています。以前のSPI接続TFTモジュールで
中華クオリティはよく知っていたはずですが最初安易に8bitバスで挑戦して
敢え無く撃沈。
結局16bit接続でやり直しました。使用したMCUはもちろんSTM32F107VCT6です。
他のマイコン使うときは8bit分しか接続できなくてもラッチかましてあげれば16bitに
仕立て上げられるんで速度の低下に目をつぶれば何の問題もないでしょう。
変換基板にはIMOとかIM3とかバス幅切り替えられるようなシルク表記がありますが
どこにもつながっていないです！。
20100121追：vvtune氏が8bitバス接続でアクセスする方法を見つけられています。
これは…ありがたい…！

TFTの動かし方はSTM32に繋いでサンプルプログラムをSTM32用に移植(コピペ)して
そのまま"いっせーのポン"で終了です(はしょるはしょる)。この辺は一度TFT/OLED
モジュールを制御する枠組み作ってしまえば容易なものです。

んでお約束のいつもの…

↑私は新しい液晶モジュール手に入れたら必ずこれやらないと体の調子が…
　例の如くびぃぶろ君に怒られるので鮮明な画像は乗せることはできません(棒

…失礼しました…お口直しに小動物を…

↑ううむ、やっぱ画面が大きいってのは良いもんだ！？
　このモジュールもとても安いので複数個購入するつもりです…

このモジュール使ってDSO nanoでっち上げられるので、107系使うためにCQ-STARM
基板から外したSTM32F103VBT6を使用して試してみる価値はありそうですね。

てわけで今回はこれにて！…と言いたいところですが実はかなり前に別経路で
中華製TFTモジュールを購入していたりする…しかも5980円も払って！！！

…悔しいので涙目になりつつもこっちも表示テストしてみます…
コントローラICは先のモジュールのものと同じメーカーのILI9320。ILI9325と
酷似したレジスタ構成でしたがデバイスの叩き方は微妙に違っていました。
コントローラICが同じでもモジュール内の結線の違いで制御方法がだいぶ
変わってきたりもするので吟味は必要です。しかし提供されているサンプル
片手に"ゲタ合わせ"しておけば後にやることは同じです。

あらよっと。

STM32 Primer2にFreeRTOSを乗せる２ -液晶表示のタスクを追加する-

あけましておめでとうございます(した)。
自分の誕生日(1/6)の準備してたりなんやかんやであっという間に10日になっちゃい
ましたね。忙しくてなかなか手が割けなくなってしまいましたが、今年もお気楽に、
たとえば"砕けた表現やアニメ調のイラストが目に障るので授業で資料として使いやす
いようにブログの記事を修正してほしい"って教育関係者とみられる方からまたクレーム
もらうくらいの感じでやっていこうと思います。これがゆとり教育の弊害かー(棒

それはさておきSTM32 Primer2にFreeRTOSを載せる試みを進めていっていますが、
今回はLCDのタスクも追加しました。さらに、ProjectC3氏のフォントドライバも使いや
すく汎用性を上げて実装しています。フォントは8~16ptまで対応で今回のデモには
フリーのM+フォント(10pt)と美咲フォント(8pt)をCヘッダファイル化した状態で使用
させていただきました(デフォルトはM+フォント)。

簡単に文字が扱えるようになると、出来ることの範囲もぐっと広がりますね～。引き
続きFreeRTOSの動作を勉強しつつSTM32 Primer2で未使用の機能に手を出して見よう
と思います。また、STM32 Primer2とは別にもう少し大きい液晶を使用したデジタル
フォトフレームの構想なんかも練っている最中です。

↑だんだんサマになってきた!?

仕事納め

何とか時間取れました…なんか忙しくってホントに年末って感じがしませんね…

それはさておきaitendoさんのSPI液晶H161IT01ですが時間を見て少しづつ
いじってきましたが、ようやく使えるようになってきました。
使用の上での分かったことをいくつか…

●この液晶モジュールはSPI接続でしか使えない。
●SPI接続だと書き込み専用でしか使えない。よってシリアルINは要らない。
●バックライトLEDは3つ。一つ当たりの電流値typが15mAなので
　全部で45mA流す必要がある。
●3.3V系でも使用可能だがやっぱ単一だとやっぱ暗い。バラつきを考えて定電流
　制御ができるDCDCコンバータICを使用するのが良いでしょう。
●45mA流してもまだ暗いんで55mA流すとそこそこかしら。
●ZY-FGD1442701V1と比べると青みがなく自然に近い色です。
●少ピンでのマイコンシステムには最適でしょう。しかし変換基板が…

といったところでしょうか。変な癖も無く、使いやすい液晶だと思います。

んでもってこのSPI液晶を使用した応用編…

↑以前紹介したEtherPodにFreeRTOSを乗っけたときは外部表示機能がなかった
　のですが今回SPI液晶を表示機として使用してみました。
　文字の表示法もセクスィ部長氏とProjectC3氏
のページから勉強させてもらいました。
フォントはフリーの美咲フォントを使用しています。他のサイズのフォントも
いろいろ試してみようと思います。

↑実は日本語フォントは上手くいかなくでず～っと詰まってたのですがやっと
　一つの壁を超えた感じです。
　さぁつぎは避けまくってるUSBデバイスだ！…はまだ無理なので追々と。

と、今年はこんなところで…。仕事の中でマイコンや回路設計を覚えていって
その折にこのブログも始めて、さらに他の方とも共同で作業をするようになって
来ると一人で制作している時は見えてなかった部分がいろいろ見えてきたりもしました。
この業界に身を置く限り、常に新しいことの勉強勉強の連続の日々なわけですが、
これからも気力の続く限りずっと続けていきたいものです。

女主人超多忙に付き

現在死ぬほど忙しいです。
駆け込みの案件が何個かあって、まぁ年末は去年もこんな感じでしたけど…。

年末までの短い期間にSTマイクロ以外のCortex-M3のマイコン攻勢が勢いを
増してきましたね～。STマイクロがこのまま逃げ切るのか、はたまた他の
メーカーがシェアを奪うのか気になるところです。どこも新しいのだすのは
いいんですけど必ず付きもののerrata何とかしてほしいなと思ふ。

話は変わりますがaitendoさんでSPI接続のTFT液晶モジュール、H161T01が
販売されています。詳細は不明な点が多いのですが購入して試してみました。
変換コネクタも必ずいるので実質1400円しますね…。この前のが安価で高性能すぎるのかしら。

データシート見る限りではパラレルとシリアルでつなげられるように見えます。
しかしパラレル制御に必要なRD,WR,(68k系ならEもかな)がどこにも見当たり
ません。したがってシリアルでしか制御できないようです。"ウソつくん
じゃねーパラレルでもできるぞ"っていう方はやり方教えてください…。

今回"も"電源電圧+3.3V単一でも可能ですが、バックライトLEDのVfが+3.7Vです。
まともに使うためには5V供給するなり昇圧するなりの工夫が必要でしょう。
今回は制御だけが目的なので3.3Vのままで…。

というわけで動かしてみました。
データシートの額面通りだと50nSec(=20MHz)のクロックサイクルがtyp値と
なっています。STM32のIOは18MHz以上のトグルスピード出せるのでいつもの
如く組むのが簡単なソフトSPIで。
表示速度は以前のと比べると少し劣りますがストレスは全く感じません。
さかさまになってるけど表示方向としてはデータシート通りになっていて正しい
のでしょうか???まぁいいや…。

ハイお約束。めくるめくいなちゃんの肌色世界。ここは未成年の学生さんでも楽しめる
超健全なぶろぐなのでちゃんとピンぼｋ…やめて石投げないで

…大変失礼しました。こちらはカナメ・ワタツミ氏からのいただき物の私(ねむいさん)の
イラストです。使わせてもらいます！

ということでリセット線すら省けば最低CS,D/C,SCLK,SDATAのたった４本で動くので
小ピンのマイコンとかでもきれいな画像が扱えるようになるでしょう。aitendoさんが
専用のキャリーボード出してくれたらもう一寸売れると思います(ｵｲ

さらに話は変わりますが多分今日ので今年最後の日記になると思います。来年も安泰に
続けたいものです…もう少し時間に余裕が欲しいですな…。
んでもってCodeSourcery G++の新しい奴(4.4.1系)で少し前のソースコードをビルド
するとビルドできなかったりビルド通ってもまともに動かなかったりすることが
分かったので(特にFreeRTOS絡み)そちらの保守の対応と説明にも時間がとられ
そうです…じかんｇ(ry

STM32 Primer2にFreeRTOSを乗せる1

年末に差し掛かって糞ほど忙しくなっています。そんな中でも合間を縫って更新ッ…！

前回はSTM32 Primer2上にRIDEやCiecleOSなぞガン無視のBARE-METALな自分環境で
USBマスストレージクラス対応のミニフォトフレームなんか作ってたわけですが、今度は
すっかりおなじみのFreeRTOSを乗せてちゃんとしたシステムを作ることにします。
こちらもフォトフレームの制作時と学習を兼ねて段階的に進めていくつもりです。

えーと先にもいいましたがSTM32Primer2のコミュニティサイトに既に移植されたのが
ありますがそれはあえて一切視界に入れない方向でやっていきます！！！！

↑後発だから一味違う！！１！
まずは第一歩、以前CQ-STARM向けに一番簡単なのをこさえていたのでこれを2Primer2
(STM32F103VET6)向けに移植を…。プログラムの内容はLEDのタスクだけを動かすとい
ったごくごく単純なものです。しかーし！！コミュニティにあるのと違う点はFreeRTOS
が最新なのと真中のボタン長押しで電源が切れるという革新的ｎ
…や　やめて石投げないで
※公開停止しました。ソースコードほしい人はメールください。

このプログラムがこれから先のFreeRTOS+STM32Primer2のたたき台になります。今度
こそ横着しないでRTOSをまともに使いこなしていこうとおもいます。ついでにUSBもち
ゃんと学習していきたいとおもいます。今度は本気出す！

また、↑のと並行してNuttXという別なフリーのRTOSの勉強も初めています。
これはGenie氏が手掛けているEtherPodというSTM32F107が乗ったマイコンモジュール
(まだ試作段階ですが)に標準で搭載され、またそれに合わせた様々な機能が
サポートされる予定になっているのでEtherPodと併せて非常に注目すべき
OSとなるでしょう。

↑…実はすでにFreeRTOS+webserverのデモまで私が動かしててさらにこれのロー
　レベルドライバもこしらえてる最中だったりしたり

STM32 Primer2をBARE-METALで使ってみる(終) -フォトフレームを作る-

大きなバグ出しも終わってやっとこ使用に耐えるものが完成です。上位層の作り込みは
Chan氏のFatFsやターミナルプログラムの凡例のおかげで開発期間の大幅な短縮が
できました。そしてCircleOSに頼らないBARE-METALな試みも今回でいったん終了
です。

昨今の電子工作は回路検証はもちろんケーシングも非常に重要なファクターになって
いますが、もとからケースに入っているSTM32Primer2はとてもありがたいですなぁ。
…ってことで、

以下今回製作したフォトフレームの使用例を…
※20091226:電源監視機能を強化しました。

※20091126:USB-MSC(マスストレージクラス)機能を追加しました。

↑4+1入力キーの"真ん中"を押して電源投入。これはハード的に処理されています。

↑電源投入->タイトル表示後はSTM32Primer2に挿入されているSDカードを読み込み、
　ファイラを起動します。ファイルシステムはFatFsを使用しFAT12,FAT16,FAT32の
　フォーマット・およびロングファイルネームが使用可能です(画面上の表示は
　8.3形式ですが）。

↑ファイラ画面の基本操作は↑↓がファイルポインタの移動、→がEnter,←がCancel
　に相当します。

↑画像はbmp形式が表示可能で128x160pixelまでの物が使用できます。
　それより小さいサイズは、真ん中合わせで表示されます。
　画像はひねもすのたり氏画の私(ねむいさん)。
　…びいぶろ君が欲情すると困るからピンボケ！

↑…すみません…お口直しに癒し系小動物を。otter-beerは結構有名らしいです。

↑動画はimg形式。img形式のファイルは同梱のChan氏謹製の付属ツールでaviから生成
　できます。再生中→キーで一時停止、その後↑↓キーでコマ送り、戻しができます。
　上の画像のは虹裏で活動している名無しの絵師さんの動画をお借りしました。

20091126追加

↑USBマスストレージモードに入るためにはUSBケーブルをSTM32Primer2の
　"STM32"側のコネクタに挿し、ファイラのルートディレクトリでLeftキーを押します。
　LCDの画面が暗転し、PCにディスクドライブがマウントされたら成功です。

20091126追加

↑MSCモードからファイラに戻るためにはLeftキーをもう一度押します。
　ディスクドライブがアンマウントされ、ファイラの画面に戻ります。

↑UART2からの通信にも対応。上記結線(TTLレベル)でホストPCと接続。

↑ホストPCのターミナル(230400bps,8,N,1)上からESCキーを押すことで、ファイラは
終了し、FatFsのUART上のモニタプログラムが走ります。

↑現状では時刻設定はUART上のモニタプログラムからのみ可能です。

↑電源OFFは"真ん中"のキ―長押しで行います。この画面が出てからキーを放すと
　FETスイッチが切れ"電源OFF"となります。

と、こんな感じです。ミニフォトフレームに機能を絞っているので以下に挙げる機
能は基板上には存在しますが使用していません。後は各人がソース変えてお好みで
付け足してくださいね(ひでぇ)。
*Not Used Devices
-Touch Sensor
-3D MEMS Sensor
-I2S Peripheral
-IrDA

また将来搭載予定の機能は以下に。
*Future Features
~~-USB-MSC~~ 実装済
-LCD-Backlight Adjustment
-Adjustment Configuration which does not rely on host PC.
-Improve Backup Register Function.
~~-Improve Power Management~~ 実装済
~~最優先はUSB-MSC。SDカードの抜き差しは面倒ですもんね。~~
USB-MSC実装しました。
IJG JPEG Library を実装しました！

んでもって修正すべき項目は以下に。
*Known Issues
~~-Cannot execute program if there's no Li-Ion Battery jumper.~~ Fixed.
~~-Cannot execute backup function.~~ Fixed.
現状Li-Ion電池のジャンパしてないとNo Batteryと判断されてしまいすぐに強制shutdown
されてしまいます。電源電圧の上手い監視方法見つけたらこちらはすぐに修正します。 修正済

ということでまだまだ手を加えるべき点はありますが、興味を持たれた人は試して
みてくださいね。ご利用は自己責任で～

最新のFatFs移植例はこちらにあります。

STM32 Primer2をBARE-METALで使ってみる5 -FatFsの実装-

もともとBARE-METALで取り組むのを決めたいきさつは、Chan氏のLPC2388向けの
OLED表示プログラムを"STM32で再現できたら素敵じゃないか"って構想から
始まって少しずつ実現して来たわけですが,STM32Primer2でも再現してみたい！
という思惑からはじまってます…。

今回その要であるFatFsの実装にとり掛りました。STM32F107VCT6ではSDカードの
アクセスにSPIを使用していましたがSTM32Primer2(STM32F103VET6)ではSDIO
インターフェースが搭載されているのでこちらを使います。
またSDIOのドライバはSTマイクロさん本家からMassStorageClassのデモの形で
提供されているのでRowleyのサイトにある移植例を手本ni
"ゲタ"合わせを行いました。(ベースはSTM32F107VCT6のFatFs)

LCDの時よりかは手こずらずに移植は完了しました。が、いくつか引っかかる点が…

①割り込み版のUART-Txを使うとxprintf関数を実行したときうまく表示できない
　いろいろやってみましたが文字の送信がうまくいかなかったので折角割り込み版をこさ
　えたのにポーリング版に戻したorz(Rxは割り込みでも問題なし)
私の経験と知識の無さはこういう形で表れてくるorz
20100317:FIFOバッファの処理が不完全なだけでしたorz

②RTCの初期化がうまくいかない
　STM32Primer2は電力消費を抑えるためにVbat周辺の回路も同じく低消費電力化されて
　います。以前の回路ではうまくいってたバックアップ方法は今回は動きませんでした。
　具体的に言うとバックアップレジスタにマジックナンバを書いておいてその有無でバッ
　クアップされているか判定していたのですが、STM32Primer2の回路だとそこが正しく
　読めない…仕方ないのでマジックナンバが書かれているかの判定部分は削除しておく
　と時刻情報はかろうじて保持されているのでひとまずこれで進めることに…

開発が落ち着いたらバグ出しついでに上記2点の問題おっかけます。特に大きな支障は
ないので今は対策を保留…。
20100317：RTCの初期化に問題があってバックアップレジスタへの書き込みを
　　　　　禁じた状態で書こうとしてましたorz

とりあえずFatFsが動いたので読み込み転送速度の比較を行ってみました。使用した
SDカードはATP製の4GBSDHCカード。Class6のものです。比較検証用のファイルは
L氏のwebラジオ、"Lの虹裏ピアノラジオ"を録音したmp3ファイル(132MByte)を
使用しました。

↑まずSTM32F107VCT6の(SPI,18MHz,DMA使用)で…まずまずです。

↑次に今回STM32 Primer2に実装したの(SDIO,4bitmode,24MHz,DMA使用)…あれれ、思ったほど伸びませんでしたね…。
今すぐ下の方見ろ！！！１１！

↑最後にChan氏のLPC2388用MCIアクセスプログラム(MCI,4bitmode,18MHz,DMA)
ううむ…ぶっちぎりですなぁ…。

STM32のSDIOはもっと伸びるとおもうんですけどどっかでフン詰まりになって
いるようですね･･･まぁ現状でも十分すぎるのでこちらの件は以後の改善課題
としておきます。

というわけでマルチセクタ転送にちゃれんぢしてみました…

～小一時間後～

↑
やばい超早い♥

20111111追：
時は流れ、STM32F4では48MHzのSDIOクロックでも安定して動かせられる
ようになったので、約21Mbyte/Secの読み出し速度を常にたたき出してます！

次回は今まで検証してきた成果をすべて組み合わせ、BARE-METALなプロジェクトの
到達目標としていたPrimer2用フォトフレームの制作に挑みます。

STM32 Primer2をBARE-METALで使ってみる4 -FSMCとLCD-

もうすっかり使いこなせて当然…なはずのカラーグラフィックLCDのつもりでしたが結構
苦戦しました…。STM32Primer2ではLCDの結線はSTM32のFSMCを使用したバス接続
となっていて、CircleOSもこれを利用してLCDの操作を行っています。LCDモジュールの
コントローラICはST7732。以前のTFTモジュールやi2c液晶なんかとおなじメーカの奴です。

ST7735の時と同じ風にやったら楽勝だろうと考えていたらモジュール内部で完結して
いるICのモード設定ピンの関係に気づくまでどうしても表示がうまくいかなくて
うｎうｎ唸っていました。コントローラICが同じもしくは同等品であっても
モジュール全体でみると初期化・制御の仕方とか微妙に違うってことを
思い知りました(いまさらか)。

上記のことさえ注意しておけば後は特に気にすることなくすんなりと一枚絵の表示まで
こぎつけました。128x160フルに使って表示できます。

※性的描写があるので小さく表示

↑ごめん…またいなちゃんなんだ…もう許してもらおうとも思ってはいない
　…でもやめられない♥

今回はWindowsで普通に作成できる24bitのビットマップをそのままC言語ヘッダ
ファイルに変換して直接読み込んでいます(内部で16bitに変換してます)。
FatFsが次に控えているのでそれを意識しています。

後気づいたことを一つ…
CircleOSのフォーラム見ていると拡張コネクタから出ているi2cやcanがFSMCからの干渉
でうまく動かないなどのことが議論されています。回路図見た感じではFSMCのバスは外
には手軽に出せないし現状LCD専用状態だしで、あんましFSMC使うメリットが見当たら
ないように気がしますが私の検証用のプログラムはCircleOSのを真似てFSMC使っています。

STM32Primer2をBARE-METALで使ってみる3 -ADCによる電源監視とUART2-

前回はSystickタイマを利用したスイッチ入力で電源の制御を行いました。しかし
電源を付けっぱなしにしているとどんどん電力が消費され、ついには3.5Vを切って
しまいます。（リチウムイオン電池の詳細な特性については他の専門に解説されて
いる方たちにうっちゃる(うｎ？)として、）実際3.5V以下になると急速に電圧が低
下していってしまうという特性があるので3.5Vできっちり止めなければなりません。

STM32Primer2はリチウムイオン電池の電圧低下をハードウエアで監視する機構がな
いのでSTM32に内蔵されたADCを利用してソフト的に監視し、3.5V以下になったら強
制的にシャットダウンする必要があります。今回はCircleOSのDMAを利用したADCと
過去の自分のコードを利用して電源監視ルーチンを作りました。

電源監視ルーチンはCircleOSで行っている方法とほぼ一緒で、1Secごとに移動平均
化されたVbatの値が3500(3500mV)になりさらにそれが15秒間連続した時にSHUTDOUN
信号を出してFETスイッチをOFFにするというものです。

そしてこの機構が実際に機能しているかどうかを確認するためにモニタリングする
必要がありますが、この検証には背面の拡張コネクタから出ているUART2を利用し
ました。このUART2のルーチンも自分の過去の(ry)でprintfにリダイレクトさせるよ
うにしています。

以前107系等で組んでいた時はUART-Txだけは割り込みを使用せず、ポーリングで回し
ていました。今回UART-Txも割り込み方式に変えています。それで初めて気づいた
のですがprintf等使用時に高速にバッファに転写すると早すぎて割り込み処理が
間に合わず、文字列が反転した状態で出てきてしまいましたので少し細工を行い安
定して文字列を送信できるようにしました。

↑大活躍の極小USB-Serial変換(画像右上)。

以上の条件下(72MHz駆動,LCDバックライトは未制御のため全点灯)でUART2から文字
列を排出した状態で電源電圧低下を感知して自動で切れるまでモニタリングを行い
ました

上図の結果のとおり、満充電4.1Vから徐々に電圧が落ちて行って3.5Vに差し掛かっ
たところでFETスイッチが切れています。また3.6V付近から電圧の落ち込みが急速に
早くなっているのが分かりますね。自働強制シャットダウンまで約4時間まるまる
かかりましたがCPUは最高速度,LCDのバックライトも未制御の最大輝度ですのかな
り電流喰っている状態です。この二つを制御できたらさらに持つでしょうね。

次回はFSMCを使ったLCDの制御に入ります。
FSMCは全く使用したことがないので少々手こずりそうです。

STM32Primer2をBARE-METALで使ってみる2 -Systickタイマと電源制御-

前回は一番基本的なLEDの点滅を行いました。点滅だけなので、STM32 Primer2の
バッテリーの制御(電源OFF)ができません。これから先いちいちUSBケーブルを抜き差し
するのは不便なので今回は電源制御を行います。

電源の制御にあたって、STM32(というかCortex-M3)に搭載されているSystickタイマ
を利用し、定期的にSWポートをスキャンしてある条件を満たしていれば電源をOFFに
することにします。これはCircleOSと同じ仕様ですね。

具体的には1mSecごとにCenterキー(PA8)を走査して5000mSecの間連続してHi
レベルにあったときにSHUTDOWN(PC13)をHiレベルにしてFETスイッチをOFFに
します。4入力キーの定義も行っていますが、今回は使うのはまだCENTER
キーだけです。

↑4+1キー入力と電源制御(SHUTDOWN)周辺

またRLINKのフラッシュの方法も少し工夫しました。RFlasher7でちんたらやってた
ら非常に煩わしいので、OpenOCDを使ってた時よろしくmake programでコマンドラ
インのフラッシュライタを呼び出し、バッチ処理しています。これでOpenOCD使って
た頃とまったく変わらない操作性になりました。やっぱこっちのスタイルの方がい
いですね～♥もちろんRLINKのデバイスドライバはWinUSBの方で！

↑OpenOCDのフラッシュプログラムの処理をRLINKに置き換える

土台が整ったので、ここから先は駆け足になると思います。同じ事やってても何も
身につかないのは自覚してるので浅く広く早くでやっていくつもりです。
一応ねむいさんの基本スタンスは…
●無償で公開されてるライブラリ・プログラムは極力有り難く利用させてもらう。
●↑のことした場合は"ネットで見つけた"とか書かずに公開元のルールのもと引
　用先をブログやソース内で明示させてもらう。
●使わせてもらう前にざっとでいいからコードを眺めて流れを把握する。
●ここは自分でやらないとだめだ！って部分は自分で調べてフルスクラッチで書く。
●真似てやって壊れても潰れても燃えても泣かない(これ重要)。一度壊したけど。
●他の方がされていることに過度に干渉しない(これ重要)。
この辺虹裏内での立ち回りと全く同じなわけですが、気をつけます。

STM32Primer2をBARE-METALで使ってみる1

BARE-METALとか横文字でかっこつけてみたけれどつまりCircleOS(とそのAPI)
使わないでやってみるというわけです。
STM32F103VET6(を使ったSTM32Primer2のハードウエア)に合わせたフレーム
ワーク作りをやって行きます。

今までSTM32F103VBT6(CQ-STARM),STM32F107VCT6とやって来てリンカス
クリプトやスタートアップの組み方は熟知してますので定義だけ変えて
あげれば終わりです。
STM32F107VCT6をベースにしてPrimer2上の2つのLEDを交互に点滅するプログラムを
こしらえるのが今回の最初の目標です。(FWライブラリは勿論V3.1.2の最新で）

STマイクロさんが用意してくれているCソースのシステムクロック用の設定は、
デフォルトが103,101系は8MHz,107系は25MHzの外部クロックを想定しています。
STM32Primer2は12MHzのクリスタルを使用するため、system_stm32f10x.cにある
クロックPLLを設定する関数内で一部定義を書き換える必要があります。
提供されたライブラリにはなるべく触りたくなかったので、コピーした
ファイルをリネームしてmain.cと同じ場所に置きました。

↑赤で囲った部分がPLLの定義を書き換えたところ

さらに、使用している外部クロックを決める定義(HSE_Value)はmakefile内で行っています。

プログラムの書き込みは先日無理やり適用したWinUSBのドライバで安定して動くよ
うになったRlink(ビルドイン)を使い、RFlasher7で書き込みます。

まだ電源制御は乗っけていませんのでtodotani氏のブログ内の記述にある
とおり電源のONは出来てもOFFはできません。電源切る時はリチウムイオン電池の
ジャンパとPCにつなげてるUSBケーブル引っこ抜いて切る必要があります。

次回はこの電源制御を中心としてsystickタイマ・キー入力の実装を行うつもりです。

ペプシあずき

ペプシあずきっていう際物のペプシ飲んでみたのですが…
…うおえっぷ。子供向けのシロップ状の薬思い出してしまった…。

そしてそんなことやってる間にも私の周りの世界はどんどん回っていく。LPC2388のコ
ンテスト受賞者が発表されていますね～。私がFreeRTOSを知り、使うきっかけとなっ
た今井健太郎氏やUSBデバイスの開発で詰まったときに参考にさせてもらっているマイ
コン工作実験日記氏の作品が入賞されています。

私はチェンジニアリング(=他人の成果物使って切った張った)しかできないから一つの
プロジェクトを決められた時間でフルスクラッチでバシッと組めるってのは尊敬して
しまいます。この業界に転職して早一年と少し、なんとかしがみ付いてきたけどこの先
数年もしないうちにまた違う職種に移ってるんだろうけども何かひとつくらいはでっか
いの残していきたいな～なんて妄想してます(げんぢつから目をそらしながら)。

久しぶりの日記がここで終わってしまうと歯切れが悪いのでもうちょっと書いてみます。

●STM32 Primer2
以前から少しずつSTM32F107系の記事書いてきましたが、そちらと並行して
STM32Primer2をCircleOS無しで動かす構想を考えています。
目標は…FreeRTOSを乗せて動かす！

…と書いてしまいましたが実際ことに移すとコレ結構厄介です。まずは開発環境が…。
STM32Primer2にはビルドインされたRLINKがあるのですがこれがSWD接続の為にOpen
OCDから直接操作ができません(20091104現在)。
そしてRLINKのデバイスドライバ(Windriver)が未だにバージョンが低いものを要求し
ているため、AVRJTAGICEmk2等で使用されている最新のVerのものを使用することがで
きません！無理やり使うと確実にB.S.O.D.になってしまいますorz(XP環境の話です)

実はねむいさんがSTM32Primerを使用することに消極的だったのはこのドライバの問題
なわけで、よくよく調べてみるとWindowsVISTA以降のOSはマイクロソフト純正の汎用
USBドライバであるWinUSBなる物が提供されていてVISTA以降のOSではRLINKの
ドライバとしてこちらが適用されているようです。ねむいさんは
このWinUSBってやつを無理やりXPにも適用して難を逃れました！！(セコいな)
FreeRTOSを乗せる過程は一気にはできないので次回以降でぼちぼちとやっていきます。

●aitendoさんのTFTモジュール
たくさん売れたおかげで専用の拡張ボードまで起こしてもらって再販になっています
(20091104現在)。一枚絵の表示くらいならAVRでも十分にできるのでひとつくらいは持
ってても良いかと思います。私もLPC2388,STM32F107で表示させてきましたが
そら氏と同じく青みがかかった画面を何とかしようといろいろあがいてみました。
しかし結局大きな改善はできませんでしたがVMCTR1(VCOM control1）という
レジスタの値を変えるとコントラストは変えることができたので少しいじって
濃いめに出すようにしました。

STM32F107VCT6のプログラムはUSBライブラリのリリース待ちの関係で公開を
保留してましたけど一項に出る気配がないのでW.I.P.ですが置いておきます。
FatFsは先日R0.07eがリリースされていましたのでこちらも適用してあります。

LPC2388の方もSTM32とおなじ修正を施しておきました。以前はUART版とVCOM版は
分けていましたが今回からmakefile内で切り替えられるようにして一本化を行いました。
こうしておくと管理楽ですからね～。ついでにchan氏のmp3プレーヤーで使用している
mp3モジュールを使用したスイッチ入力にも対応しています。詳細は同梱のdocフォルダを。

●OLIMEXのAT91SAM7S256プロトタイプボード
ず～～～っと前からやるやる詐欺してましたがこちらも腐らせるにはもったいなさす
ぎるので手をかけることに決めました。こちらの目標はいくつか買い込んであった
TFTモジュールを使用したUSB接続のミニフォトフレームの製作をしてみようと
思います。

↑やるやる詐欺

aitendoさんのTFT液晶モジュールを使う

20101228追：
MCUバス接続タイプのTFTLCDモジュールを動かしたい奴は必ず読め！！１１！

かねてから興味があったaitendoさんの液晶モジュール、ZY-FGD1442701V1が手に入っ
たので早速使ってみました。現在はそら氏がATMEGA644Pで画像の表示まで達成されて
いますね。私はいつものSTM32F107VCT6で攻めてみました。

この液晶モジュールのコントローラはST7735で、データシートみる見る限りでは
chan氏のOLEDの時とほぼ同じようなアクセスの感じに見えたので、前回STM32に
移植したOLED用のコードとサンプルコードをもとに新たにST7735用のコードを
作りました。
STM32のローレベル部分はこさえてあって表示部分はchan氏の非常に柔軟なコードが
ほぼそのまま使えたので、はんだつけ工作も含めて移植は半日も掛かりませんでした。

で、OLEDでやってたミニフォトフレーム(?)をTFT液晶モジュールでも再現。

↑やや青みがかってますがOLEDモジュールに引けを取らないほど発色がよいです。
　そら氏がされているようにガンマ値いじればさらに綺麗になるでしょうね。

↑周囲を暗くして写して見ました。デジカメでうまく撮るための工夫を考えねば…。

↑ああ、残念だ。美しいいないさんの肢体が輝度が高すぎてで光学迷さ(ry

↑おやくそくはおいといてコツメちゃんを表示。うまくいった後はBEERがうまいぜHAHA！
　ﾀﾌﾟﾀﾌﾟ

液晶モジュールのデータシートはロジック3.0V,LEDバックライト3.3Vまでと
謳われていますが、ロジック部のコントローラST7735は3.3V(絶対最大定格4.6V)で
運用可能です。
ねむいさんはST7735のほうのデータを信用したので(良い子は真似しちゃだめよ！)
STM32F107VCT6動かしてる3.3Vの単一電源だけで液晶モジュールを動かしています。
多分稼働寿命対策でモジュール単位では低い電圧で運用してもらううつもりで書いて
あるんでしょうけど、遊びで使うなら3.3Vでもなんら問題ないでしょう。

STM32ではうまくいったのでお次はLPC2388でもやってみます。安い上に非常に
使いやすいのが分かったのでもう5～6個ほど買うつもりです。

色々直す…

…前回の検証でSTM32 Primer2に乗っかっているSWレギュレータIC(L6928D)を、
2つとも吹っ飛ばしてしまいましたが、これらはU9:メインMCU電源供給(2.85V)、
U17:バックライト用電源(3.1V)向けという非常にクリチカルな部分に使われており
どちらか一つでも壊すと、もはやPrimer2は使用不可能になります！！あほか！

仕方がないので代替で使用できそうなレギュレータを探し貼っ付けました
L6928Dは非常に繊細だとのことでもう使わない方向で…

まずバックライト電源生成部。元の設計上では3.1V出力ですが実際は3.2V近くです。
また、カラーLCDのバックライト電源は3.3Vまで使用可能でなおかつSTM32Primer2が
監視しているリチウム2次電池のシャットダウン電圧が3.5Vな点から、いつものLT1963A
先生に代役してもらうことに。電流は500mAも引かないので3.5Vまで落ち込んだ時の
ドロップアウト電圧も気にならないレベルです。これでもう一寸安くなってくれたら
ねむいさん的に最強のLDOなんですけお…性能が高い分お値段も高いんですよね。

次に2.85V生成部なんですが身近にすぐ手に入る2.85V出してくれるちっさいサイズの
レギュレータがLP3988しかありませんでした。残念ながら150mAしか引けないので
STM32Primer2回すだけで精いっぱいです。外部に機器を接続する時は別口でとらざるを
得ないです。耐圧はL6928Dよりも0.5V高いので過渡電圧余裕も確保…かしら？

一度は死んだSTM32primer2でしたが措置を施し電源が修復強化されて無事復ッ活！！
ちなみに10月11日は同僚のヤクいさんの誕生日なのでした！

そしてもうひとつ、不注意で壊してしまった(輝度が異様に下がってしまった)OLEDの
代わりに新しいOLEDの基板がやってきました。前々回もお見せしましたが、chan氏の
LPC2388用のOLEDアクセスプログラムをSTM32F107VCT6に移植しています。
LPC2388のFIOはI/Oクロック36MHzの高速アクセス(最高I/Oトグルスピード18MHz)が
できてOLEDも非常にスムーズに表示できたのですが、STM32もほぼ互角のI/Oアクセス
性能を持ちます。

ただし、STマイクロ提供のライブラリ関数からだと呼び出しオーバーヘッドが掛かり、
直接GPIOレジスタにアクセスする必要があります。
さらにSTM32に(というかCortex-M3)はビットバンドによるアクセスができるので、
うまく組むとLPC2388より早くアクセス可能でしょう。
今回は便宜上GPIOEのみを使用してOLEDを制御したので1命令分多くかかっています。

というわけでSTM32F107VCT6でOLED動かしたところ↓

嗚呼残念だ、せっかくのいなちゃんのえろすな絵が輝度が高すぎて光学迷彩が
掛かったみたいな写真になってしまったー(棒

…とふざけるのはここら辺にしといてカラー写真とかもOLEDでは綺麗に表示できてい
ます。モデルはコツメ氏。カワウソって良いですよね♥特に頭の形とか♥

はてさて、STM32の新(OTGを含む)USBライブラリのリリースはもう少しのはずです
が…。待ち遠しいですね～。

涙目のネムイ2(STM32 Primer2壊しました)

STM32F107VCTでもOLED使えるようになりました。64kBもあるRAMのおかげです♥
え？"なにも映ってないだろこの茶デブが!"ですって！？よっっく見てください！！
うっすらとシルエットが見えるでしょう？…OLEDを物理的に潰さなければもっと
綺麗に写ってるはずなのです！なのです！！
…いないさんの美しい肢体は新しいOLEDモジュールが来るまでおあずけ…

…さて本題、先日STM32 Primer2について黒田さんより電源IC(U9,U17のL6928D
というIC)が破損対策がされているのにもかかわらず破損したとのコメントを
いただきました。遊びでも仕事でもも電源周りのトラブルで泣かされている
ねむいさんはこれ以上Primer2で憂き目にあう人が出てしまわないように調査を
開始しました。

まず問題の部分、以前はU17のGNDが信号線扱いで間違って細いパタンが引かれてしま
ってGNDのインピーダンスが高い状態になってしまって電源投入直後の入力の過渡電圧
でIC死亡となっていた問題は、出荷時にU17のGND(4Pin)を太いジャンパで強化するこ
とによって回避しています(したはずでした)。

しかし対策されたはずの基板でも破損が発生したということは同じ問題が解決していな
いかもしくはまた別な問題があると思われます。とにかく現状何が起こってるかをオシ
ロで観測することに。

VCCINとGND,実際はC23の+と-の電位差をモニタし、FETスイッチがONになった瞬間の
電圧遷移を測定しています。

VCCINの波形は電源供給元によりかなり特性が変わります。これはリチウム2次電池のみ。

こちらはUSBケーブルの給電のみ。裏のジャンパは外した状態。

最後にUSBケーブルの給電＋リチウム2次電池。

L6928Dの絶対最大定格が+6VですがFETスイッチが入った瞬間の過渡電圧が+5V近く
まで迫っています。私の環境では定格内に収まっていますが、違う環境(USB給電で
使用時、かつVbusが+5Vより少し高いようなPCの環境)では+6V以上に跳ね上がる
可能性がありますね。

また黒田さんが教えてくださったRaisonance側の見解は、
>The two L6928D regulators (U9 and U17) are very sensitive.
>To solve this issue, the patch on U9 is the main measure.
>But it seems not to be sufficent.
>A second measure consists in replacing the input capacitors (C23 and C56)
>by multilayer ceramic capacitors (instead of tantalum).
>We will modify the web page to recommend this additional measure.

これはESRが低い大容量のMLCCを使って過渡電圧を抑制しようという試みでしょうか??
十分な性能を持ち、手に入れやすいMLCCを使って私も検証してみました。
※参考になる記事
…ほんとは電源周りに使うなら十分な耐圧持ったX7R、最低でもX5Rは欲しい。

とっかえました。撮影の際見やすいように電源ICは一旦取り外してあります。
>2012サイズではちょっと取り付けが苦しそうですね。
はい。確かにちょっと半田しずらいですorz。半田で盛って何とか取り付けました。

この状態でもう一度、FETスイッチがONになった瞬間のVCCINの電圧遷移を
測定しました。

これはリチウム2次電池のみ。

こちらはUSBケーブルの給電のみ。裏のジャンパは外した状態。

最後にUSBケーブルの給電＋リチウム2次電池。

波形に関しては目に見える効果が表れています。チップタンタル使ってた時に発生して
いた過渡電圧の"ヒゲ"がバッサリ削られています。これだと十分にL6928Dの定格に収め
られますね。

L6928D破損の原因がFETスイッチのON時に発生する過渡電圧ならばC23,C56の
チップタンタルをESRが低いMLCCに交換する手法は非常に有効でしょう。

20120522追:
Achan22氏のさらなる解析によると、出力段FET(Lxピン)に外付けのフライホイール
ダイオードを付与して回生エネルギーによる破損からFETを保護する必要もあるようです。

この後もいろいろデータ取りたかったのですが残念ながら続行できませんでした。何
故かというとオシロのプローブあちこちつなぎ換えてるうちにどっか変なトコ触っちゃ
ったのか知りませんがL6928Dを潰してしまったからです…。
しかもU9とU17の2つとも！！！！orz

>The two L6928D regulators (U9 and U17) are very sensitive.
>very sensitive.

~~繊細すぎる…~~さてと代替品探しに行くか…。

STM32の新しいライブラリを試してみた

前回も終わりのあたりでさらっと触れましたが、まず標準周辺ファームウエアライブラリ
(STM32F10x_StdPeriph_Lib)がv3.1.0->v3.1.2に変更しています。それとまだRC版ですが
USBライブラリ(STM32_USB-FS-Device_Lib)もV3.0.1->V3.1.0RCになっています。前回
はさっと見ただけで済ませてましたが、もう少し深く立ち入って検証してみたのでその
所感をば…。

●STM32F10x_StdPeriph_Libの方
　全体的に大変更は無く、若干のコメント記述の変更やデモプロジェクトの追加等でお
さまってるようです。ライブラリそのものもごっそり入れ替えるだけ公開してきたいくつか
のサンプルで正常動作を確認しています。

　また、前々回FreeRTOSを動作させた時スタートアップ周りのコードをそのまま使っていると
数秒で止まってしまった問題は私が設定したスタートアップのdefine漏れと私自身が作成
したi2cローレベルルーチンのバグ(ACKフラグの消し忘れ)が原因だということが分かり(orz)、
結局そこを直しただけでわざわざ変更修正していたsystem_stm32f10x.cも配布の物を
そのまま使える状態で動かすことができています。
つまらん時間食ったぜ…orz

●STM32_USB-FS-Device_Libの方
　現状まだRC版ですが内容物を見たところ、7月頃に公開されていたConnectivity-Line
用のUSBOTG-LIBと合併した形で公開されています。おそらく正式リリース版もこの形で
提供されることになるでしょう。また、評価ボードごとのヘッダ・ソースファイルも今回より新
しく提供されていました。私のようにCQ-STARM基板を改造しまくって使用し、かつライブラリ
付属のサンプルを流用してる人は要注意です。

　ちなみにSTM32F103系で使えてたUSBライブラリはUSB-OTG(とOTG用のPHY)が乗った
107系には転用できません(だからライブラリもわざわざ別にされてたわけなんですが)。今回
のライブラリの合併(サンプルプロジェクト付き)によって107系でも手軽にUSBが扱えるよう
になりました。でもって肝心の動作の方なのですが、STM32F103系はそのまま差し替える
だけで問題なし。STM32F107系もOTG-LIB関連のファイルを追加してビルドするようにすると
USBデバイスとして動かすことができるようになりました。現状では、USB-CDC・MSCの
二つは動作を確認できています。提供されているサンプルは今のところターゲットデバイス
のみに絞られており、OTGの機能をフルに使ったものはまだないようです。
今後の充実に期待ですね…私もUSB-miniABコネクタ買っとかないと…。

前回は新ライブラリで動作を確認次第公開していたサンプルコードも順次差し替えていくと
言いましたが、上述のとおりUSBのライブラリももうすぐリリースされそうなのでこちらの
正式リリースを待って公開としていこうと思います。今から急いでも仕方なしですからね～
…特に107系は。

あ、いちおう言っとくけどLPC2388はUSB-OTG用のPHYチップ付けないとOTGの機能使えま
せんから！USB-TargetだけもしくはUSB-HostだけならPHY無しの直結でも動きますけどね…。

STM32F107VCT6に乗り換えた

今をさかのぼること数年前、まだ私が｢｣がいるほうの二次裏で活動していた頃、タッチ
ペン使ってめどいさんと云々なDSのゲームの妄想ネタがあった(はずだとおもう)のです
が、STM32Primer2使って似たようなこと再現してみました。

bare-metalで組んだ方が勉強になる(ｷﾘｯとかでかい口叩いてしまいましたがやっぱし
APIとか提供されてたらそっち使った方が楽ですよね～ﾊﾊ、ﾊﾊﾊ…。今回紹介したのも
CircleOSにビルドインされてるDRAW関係のAPI呼んだだけ。アプリよりこれ用の絵を
引き直してる時間のが長かったです。

↑いないさんとあそぼう(性的な意味で)。びいぶろ君が欲情すると困るので画像をぼか
　してる上にちいさいのはあしからず。そのかわり虹裏には鮮明な画像を投下して
　おいた！

Primer1と比べると発色・視野角ともに良好で美しいいないさんのイラストがさらに
際だちますね♥写真はぼけてるけど。

↑もちろんタッチペン入力に対応。ペンの先っちょで"先っちょ"をつんつんすると…♥

…ごめん、もう二度とこんなことしないからゆるして…

さて本題、先日digi-keyよりSTM32F107VCT6を購入したので以前CQ-STARM基板に載
せ替えていたSTM32F107VBT6と交換しました。当たり前ですが先日走らせたFreeRTOS
もそのまま無事に動作しています。また懸念されていたシステムメモリから起動する
方のブートローダーが動かない件はVCT6になってもやっぱり駄目でした
(リビジョンは同じ'Z')。まぁJTAGあるから良いでしょう…。

そしてSTM32の Standard Peripherals Library(FWLib)がv3.1.2 に上がったので
こちらのライブラリもFreeRTOSのデモに組み込んで無事動作確認。あとは過去に
公開したSTM32F103VBT6,STM32F107VBT6用のプログラムも順次FWLibを3.1.2に
最終アップデートしてclosedとし、以降はSTM32F107VCT6一本で遊んでいきたい
と思います。

と書いているうちにUSB-OTG対応のUSBライブラリのRC版がリリースされたようです。
こちらも早速評価してみます。

STM32F107にFreeRTOS乗っけてEthernet-PHYを動かすっッ！

前回からやるやる言ってたSTM32F107でFreeRTOS動かしてEthernet-PHY動かすと言っ
てた件ですが、デモコードのRowley用のサンプルを参考にあれやこれややってLPC2388
で達成していたことと同じことができるよう目指しました。

移植の際に気になったのですが、もとのRowleyのデモので使用されているビルドの定義
が本来ならばConnectivity Line(以下CL)でなければならないのに何でかMedium-device
(以下MD)になってて何でこんな意味のない事やってるんだろうか？と思って自分はCLで
makefile組んでビルドしたら見事に爆死。

よくよく調べてみるとスタート時のクロック設定のルーチンでCLの定義された部分を実
行するとOSが走りだしてから数秒後に必ず止まることが分かり、仕方ないのでこの部分
だけをMDで定義されたルーチンをマージしてなおかつメインクロック・周辺回路に矛盾
が出ないようにして難を逃れてます。

また、Ethernet-PHYの接続はLPC2388の時と同じRMII接続にて試みています。手本の
STM3210-C EVALのデフォルト回路はMII接続なのでemacのコードはRMIIに書き換える
必要がありました(と言っても書き換えるの一行だけでしたが)。それとOLEDは同じもの
を持ってないのでいつも使ってるi2c液晶さんに代役をしてもらってます。後はデータ
シート&マニュアルを地図代わりに一本道。そんなこんなでFreeRTOS上でWebServer
とかi2c液晶にステータスとかの表示ができるところまでたどり着きました。

↑FreeRTOSを本格的に動かすためにベース基板新調しました。Ethernet-PHYの基板
　はLPC2388の時の使い回し。

↑WebServerが動作しているところ。
　OpenOCD+Insightのデバッグで動きをおっかけてくと
　FreeRTOS上でどうやって桶屋が儲かってるかが分かって面白いです。

人それぞれの所感があるでしょうけども私的にはやはり自分で設計したとおり&意図した
とおりに動作が得られてﾆﾔﾘと出来る瞬間が、別の言葉に例えると(例えがアレですけど)
いないさんのスカートの中身が見えた時のｲﾖｯｼｬｰ！感が電子工作の醍醐味だと思って
ます。ねむいさんはこれからもその感触を求めて精進してきます！非性的な意味で！

~~今回のコードはまだ動作が確認し切れてないのでW.I.P.にしときます。~~
※STM32F107VCT6に統合したので削除しました。
そしてそうこうしてるうちにdigi-keyで発注していた本命のSTM32F107VCT6が
やってきたのでサンプルで頑張ってくれたSTM32F107VBT6は短い期間でしたが今回で
任務を完了です…お疲れ様…。

STM32F107をもうちょっと使ってみる

CQ-STARMの基板に乗っかっている3.3V出力のLDOは、たったの150mAしか電流
容量がありません(てかこんだけの電流容量でSDカードとかよく動かせてたな…、
無茶な設計したもんだ)。
STM32F107に載せ替えてこれからもいろいろやって行くつもりなのでそれを見据えて
同基板にもうちょっと多く電流が引くことができるLDOを載せ替えました。

元のLDO周りの回路は全部取り外し…

裏のやたらにワイドなパタンを利用してLT1963AとMLCC(X5R,16V,10uF)を取り付け…。

このLT1963Aという石は逆電圧保護・逆接保護・過熱保護などの各種保護回路があり、、
なおかつMLCCが使用可能というナイスなLDOです。その分値段は張りますが…。
昔秋月にL1087というのがあったのですが値段も安くて使いやすかったなぁ…という
思ひ出。

(レギュレートする前の電源ソースにもよるけど)最大1.5Aも電流が引けるので3.3Vで
動くいろんなデバイスをぶら下げられます。秋月のGPSモジュールとかも+3.3Vだと常
時190mA近く食ってるけど改造後は余裕です！でもGPSは次回以降のネタにとっときます…。

これで電流容量的にも安心してSDカードが使用できるようになったのでSTM32F103で
やってたFatFsのテストプログラムを107系に移植しました。といっても移植性が
非常に高いMCUなのでリンカスクリプトとスタートアップとmakefile以外はほとんど
変えずに動作確認できました。次はいよいよ本懐のFreeRTOS上でEthernet-PHYを
RMII接続で動かす!ですね。

~~本日のソースはこちらに…ご利用は自己責任で…。~~
※STM32F107VCT6に統合したので削除しました。
また、STM32F103のFatFsのテストプログラムはR0.07cに変えたときに見落としていた
処理があったのですがこれの修正を施した上で107系に移植しています。

STM32F107はぢめました

http://belogic.com/uzebox/
いつ見てもすごいなこれ

…は置いといてSTマイクロさんにサンプル請求していたSTM32F107VBT6が
ねむいさんちにやってきた！！！！

このSTM32F107xxxってやつは今年の7月にリリースされたSTM32の新機種、Connect
ivitiy-lineという種で、今までのSTM32の機能に加えてEthernet-MAC,USB-OTG(PHY
も内蔵),I2Sインターフェースとてんこもりになっています。NxPのLPC2388も同じ
数だけ周辺がありますが、多分どっちも使い切れんだろうね…orz

このチップはCQ-STARMに乗っかってたSTM32F103VBT6とピン・機能互換なので、その
まま載せ替えが可能です。というわけで早速載せ替え～！

まずCPUだけ。STM32F107はUSB-OTGなので以前のUSBライブラリはそのまま使用でき
ません。しかしそれ以外は互換性があります。以前のプログラムをJTAG経由で書
き込み、UART,RTC,ADC,I2Cの動作を確認。載せ替えは(物理的に)上手くいっている
ようです。

次に上記のプログラムをベースにSTM32F107VBT6(Connectivity line)用にリンカ
スクリプトやスタートアップを適用していきました。またEthernet-PHYを使用
することも考えてメインのクリスタル(HSE)は25MHzの物に差し替えています。

少しの変更で作成したSTM32F107用のプログラムですが問題なく動作しました。

後はUSB-OTGのライブラリのちゃんとしたのが出そろうのを待つばかりですね～。
それまではFreeeRTOSのSTM32F107用デモ(Ethernet-PHY制御含む)の完全動作を目標に
していきたいと思います。

あと雑多な所感とか…

STM32 Connectivity lineのMCUはシステムメモリにUART1,UART2,CAN,DFUの
ブートローダーが仕込まれているとのことで特にシステムメモリからDFUが使えると
スタートアドレスやリンカスクリプトをいじる必要もなくなりさらにやりすいかなぁ
…と思って早速試してみたのですがなぜか起動しない…orz

STマイクロのフォーラムを当たると私と同じ症状の人がいた。ううむ所詮はサンプル品
なのかはたまたerrataなのか…情報がたまるまで待ちましょうか…まぁJTAGで書き込み
とデバッグは出来るのでそちらの方法で行えばいいのですけれども(涙目で)。
STM32のコネクティビティ・ラインはブートローダーに致命的なバグがあります。

そんでもってSTM32ではJTAGで書いた消したやってるとうっかり__WFI();でループす
るようなプログラム書いちゃうとJTAGにすらアクセスできなくなってしまうのですが、
これはWFI実行したことによってJTAGの周辺回路のクロックまで止まってしまうからです。
内蔵フラッシュメモリじゃなくてシステムメモリからブートした状態からだとJTAGが
ひっかかってくれますので改めてフラッシュの内容を全消去によって復活しますので
やっちまった時の逃げわざと思っていてください。

それともうひとつ…OpenOCDでフラッシュ書き換えたときに出てくるメッセージとかを…

> "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program

openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey.cfg -f C:/Devz/ARM/OCD/tcl/target/stm32_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.3.0-in-development (2009-09-03-18:39) svn:2663

$URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $

For bug reports, read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS

1000 kHz

jtag_nsrst_delay: 100

jtag_ntrst_delay: 100

Warn : use 'stm32.cpu' as target identifier, not '0'

Info : device: 4 "2232C"

Info : deviceID: 67358712

Info : SerialNumber: 11111111A

Info : Description: Amontec JTAGkey A

Info : clock speed 1000 kHz

Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)

Info : JTAG tap: stm32.bs tap/device found: 0x06418041 (mfg: 0x020, part: 0x6418, ver: 0x0)

Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)

Info : JTAG tap: stm32.bs tap/device found: 0x06418041 (mfg: 0x020, part: 0x6418, ver: 0x0)

target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0x01000000 pc: 0x08001b40 msp: 0x2000c000

Info : device id = 0x10016418

Info : flash size = 128kbytes

stm32x mass erase complete

Info : Padding image section 0 with 0 bytes

Warn : not enough working area available(requested 16384, free 16336)

wrote 44704 byte from file main.elf in 2.812626s (15.521527 kb/s)

verified 44704 bytes in 1.125051s

Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)

Info : JTAG tap: stm32.bs tap/device found: 0x06418041 (mfg: 0x020, part: 0x6418, ver: 0x0)



> Process Exit Code: 0

> Time Taken: 00:05

STM32F103VBT6の時はJTAGチェーンが見つかったときに
nfo : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG Tap/device matched
Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
って出てましたがさすがに違いますね(あたりまえか)
続くdevice idも
STM32F103VBT6では
Info : device id = 0x20016410となっていましたが
STM32F107VBT6では
Info : device id = 0x10016418
となっています。

あとあともうひとつ…
リンカスクリプトいぢってみて分かったのですがSTM32F107VBT6はRAM48kByte
のはずだと思ったのですが、実際には64kByteありました…。
…なんだこれ？？？…やっぱサンプル品だから仕様外の物もあるってことでしょうか？？？

涙目のネムイ(STM32 Primer2のあれ)

秋月さんとこからもSTM32マイコン評価キットのSTM32 Primer2が販売されています。
大量在庫で6100円の格安です！
ねむいさんは4月頃にDigi-keyで9600円くらいで購入していたので今すげぇ涙目です。
くやしい…でも…使用記書いちゃう！

20110824追加:
超実用！！USBマスストレージ機能つきGPSロガー

20091206追加:
USBマスストレージ機能付きいないさんのえろす画像表示機の制作

20091114追加:
ねむいさんがついに重い腰をあげましたの巻
早く座らせてくれ

20091012追加:
電源IC壊れたけどヤクいさんのために気合いで直しましたの巻

20091008追加:
電源ICが壊れて涙目の巻

20091004追加:
STM32 Primer2を使用したアプリ"いないさんと遊ぼう(性的な意味で)"を追加

オレンジのボタンを押して主電源を入れると"Welcome to STM32Primer2!"と喋ってくれ
ます。おお、なんかすげぇ！入力デバイスはおなじみMEMS加速度センサ、そしてPrimer1
には無い4方向キーパッドやタッチパネルなんかもついていたりします。
少し4方向キーパッドがおしづらいです。日本携帯ゲーム機に慣れている方は戸惑うかも～

タッチパネルは指のほかにもペンタブの先っちょでも使えます。というか画面が小さいので、
ペン入力デバイスをペンタブ売ってるとこで買っといた方がいいでしょう。指でやるとすぐ
指紋だらけになるし。画像はmp3を再生するアプリ。音質はそれなりです。

裏蓋を外したところ。Primer1ではガバガバだった蓋はけっこうかっちり閉まるように
なってます。裏には拡張用コネクタ、リチウム電池、デバッグ用・アプリ用USBコネクタ、
ステレオジャック、MicroSDカードスロットなんかがついてます。カードは別売りです。

基板のRevは1.1です。

表蓋は木ネジで固定されています。結構固いです。壊さないように丁寧にはずしました。
基板表面には部品がいっぱいのってます(はしょるはしょる)。
……おや？何かリワークしたあとが…

細いラインを太いジャンパで補強しています。グランドを強化してる感じです。これは…

調べるとこういう記述がありました。

多分アートワーク設計の時にGNDをただのプルダウンと勘違いして細いライン引いちゃ
ったのでしょうね…それでインピーダンス上がって寄生インダクタンスが出来てしまって
共振して高電圧が出てレギュレータ壊したと…あれ？どっかで聞いたような…まぁいいや…
どっかの基板と違ってちゃんと対策されて出荷されているので安心して使用できます。

むき出しの状態で使用してみる。タッチパネル液晶の発色がきれいですね～。

STN液晶のPrimer1と比べてみる…視野角が全然違いますね…さすがTFT液晶

おまけ。Primer1の表蓋外したところです。ねむいさんはCQ-STARMだけでもひいこら
言ってるのでPrimer1,2で遊んでる余裕なんて無いと思います。他の方の応用例に
期待をしたいと思います！

この記事を書いて約1年後、時代はmbedを使ったクラウド環境の開発が栄えてしまい、
ふつーに使っただけで電源回路が破壊されるSTM32 Primer2とかすっかり情弱基板
扱いになってしまったのでしたorz

STM32(CQ-STARM基板)にFatFs乗っけてみる

20150331追:
"STM32 FatFs"でググってこのページに飛んでこられる方が非常に多いのですが、
現在では通用しない過去の情報となっております。
代わりに普遍的なもう少し切り込んだ内容のFatFsの実装事例を紹介しております
ので、こちらをご参照願います。
20150331追:

~~i2cキャラクタ液晶制御のためのシンプルi2cライブラリ群に少し修正を加えました。~~
ライブラリ作りの折、他の人の作例をいろいろ見てると同じデバイス動かすのにも
いろいろな流儀があるなぁととても感心してます。

んで修正はいいんだけど私の場合AVR,LPC2388,STM32,(まだ公開してないがAT91SAM)の
多岐にわたって作っちゃってるんで、(過去の記事いちいち修正して回るのは大変な
ので)ソースの公開方法をちょっと考えなおそうかと思ってます。
とりあえず今回"は"おきぱに誘導で…。(やっけつ)
来週1週間かけてリンク周りは大改装しておきます…。そして今回も異様に長い前振り…。

こっからが本題ですが今年4月ごろにMartin氏が、Chan氏作FatFsのSTM32への実装を
実現されています。私もこれに倣ってCQ-STARM基板で使えるように移植を試みました。

Martin氏と大きく違う部分は評価ボードが違うのと、RTCの処理にnewlibのtime関数群
使ったのとFWLibV3.1.0系なのとスタートアップとリンカスクリプトを私がいつも使ってるのに
してあるのくらいdけっこうおおいぢぁないかおい！
…まぁ詳しくは後で示すソース見てねということで(はしょるはしょる)。

そんなこんなで難なくFatFsが動いてます。ロングファイルネームも日本語ファイル名
も全く問題無しです。

LFNとか使うとこのプログラムは90kb近く容量喰うのでDFU(12kb消費)使うこと考えると
残り26kb程しか余裕がありません。当然この状態からsprintfとか組み込むと容量オーバー
で使用不可になってしまうのでちょっと考えてプログラム組む必要があります…。
~~CQ-STARM基板で動くFatFsはこちらに。ご利用は自己責任で…。~~
FatFs実装を中心としたGCCプロジェクトを取り揃えております。

ここから出来ること…とりあえずOLEDで画像表示をやってみますか…

STM32(CQ-STARM基板)にV3.XX系のライブラリでFreeRTOSを移植する。

買ってしまった…もう戻れない、太陽の牙ダg…もうええっちゅうねん

残念ながらCMSIS規格がおっ建つ前に原書が刊行されているので原書を忠実に
日本語訳したこれは、CMSISのことについてはまだシの字も触れられていません。
…まぁでも「ねむいさんてこんなことも知らないでCortex-M3弄ってきたのか」
なんて言われないためにも持っておかなければならないのです…たとえコヤシに
なろうとも…

話変わって、以前はLPC2388上でFreeRTOS動かしたー！なんて記事書いてましたが、
最新版のFreeRTOSV5.3.1ではgcc環境下でSTM32F107への移植されたデモが公開
されています。しかもCMSIS規格にのっとったV3.XX系のファームウエアライブラリで行われ
ていたので、機は熟したとばかりにSTM32F103VB6なチップが乗ったCQ-STARM
基板への移植を試みました。

とはいったものの移植というほどのたいそれたことやってなくて今あるファイルを
実装例に基づいて(STM32F107のデモのCrossWorksのプロジェクトの構成を真似て)
右を左にやっただけ。
リンカスクリプトも私が今まで使ってきたものがそのまま使用可能でした。
スタートアップファイルもFreeRTOSの流儀に合わせて関数を定義してやるだけで、
エラー無くビルドが通ってます。(Codesourcery/RaisonanceRIDEのビルド環境下)

肝心の動作の方ですが、LED点滅のタスクとprintf関数の出力をUart経由で吐かす
タスクだけの簡素なもので試したところ正常な動作を確認しました。

うまく行った日はBeerがうまいぜHAHA!(ﾀﾌﾟﾀﾌﾟ)
…今回のソースは~~こちらに~~…いつものことながら、試される場合は自己責任で～…
※公開停止しました。ほしい人はメールください。
これ単体ではビルドできないのでFreeRTOSのソース本体を別途ダウンロード
しておいてください。

あと、もう知ってる方も多いと思いますが、PICマイコンで有名な後閑氏がFreeRTOSの
使用&移植方法などをまとめられています。
PICのみならず他のマイコンにもすぐに応用が効くようなとても分かりやすい内容に
なっているのでFreeRTOSを使われる方は必読です！

VCP(仮想COMポート)経由で標準関数使ってみる

今週の成果…塗り２枚、コラ２つ…まずまずかしら…
それとかなり目立ってきたけどRP中の寝堕ちだけはなんとかしなきゃいかんです。
スレのホストが告知せずに堕ちるってのは参加してくれた人たちにすごく失礼なこと
ですから…とにかく反省…。

話変わって本題…少し前にがた老氏がSTM32(CQ-STARM基板)にてダブル
バッファを用いたCDCのファームを公開されてましたので、私も試してみました。
氏のソースはV1.0のファームウエアライブラリを用いたものでしたが、私の
V3.0.xの環境に移植しても全く問題なく動いてます。
特に仮想COM経由の一文字入出力の関数が使いやすかったので、printf関数等
標準関数のリターゲットも容易に出来ました。

と言うわけでそれを組み込んだ今回のソースは~~こちらに~~。※ほしい人はメールください。
UARTにリターゲットしてた時となるたけ似せるようにしてますが、COMポートを
開いたときの挙動が先にキーボードを打つ必要がある等少し違います。

他は、RTCの割り込み中の処理で、Vccが落ちてVbatのパワードメインだけで
動いている場合、２～３日置いてVccを復活させると76時xx分xx秒とか
なってしまうおまぬけなバグを修正してます。
(修正と言ってもSTM32PrimerのRTCの処理真似しただけですが～)
なにはともあれ先達の知恵達に感謝ですね。

STM32の基板にもRTCとこいんでんちいっこいれる

ｺﾞﾄｯ

来たわよ
これはUSBのJTAGデバイスの普及間違いなしですね～
いい時代になったものです…私はもう作ったからいいや(しれっと

昨日はLPC2388の基板にRTCとバックアップ用の電池付けましたが、STM32にも
同じ事やってみました。STM32もLPC2388と同じくVbatでバックアップできる
独立したパワードメインがあるのでコイン電池一個でRTCを動かせます。

CQ-STARMはVbatはジャンパ抵抗で切り離せられるようになっているので
改造も楽ちんです(他のリワークがきついけど)。こんな感じで各部品を実装です。

~~RTCのプログラムのサンプル~~は以前のstdioのライブラリ使ったprintf
のプログラムをベースにRTC部分の割り込みと、UARTの受信割り込みを足しこんで
昨日のLPC2388のプログラムになるべく似せるようにしてます。
(どっちかと言うとSTMのがオリジナルなんだけどまぁいいや)
自己責任でどうぞ。あと32.768KHzの水晶は必ずつけるように！

ARM7TDMIに並行してCortexも本格的に覚えようかしら…ブログで公開するに
当たって深いとこまでいじって来たけどなかなか面白い。

VCP(仮想COMポート)DEMOを動かす

SkyDriveにうｐしたソースコードのファイルのURLが全部別のに
変更されていた！少し前に仕様が変わって10MB以下のファイルでも
直リン不可になってしまっていたらしいorz

人が見に来るようになる前にソースのダウンロード先だけは
確実に落とせるように変更しておきました。(←うつけ)
幸い画像の直リンはまだ出来るみたいだから画像の処置は様子見ですよぅ。

20190714追:
OneDriveになってPublicフォルダすらなくなりやがりましたFUCK!!!

マイコン使って仮想COMポートを実現する…今ではいろんな手法があります。
tiny45などのAVR使って簡易なCDCなんかもできたりしていやはや
すごいな～なんて。CQ-STARMに乗っかってる石にもUSBのインタフェ
ースがサポートされてるので当然のごとく仮想COMポート(以下VCP)の
デモなんか用意されてるわけですが…

これがなぁ…コンパイラのバージョンにシビアでコンパイルすら通らなか
ったり通ってもwarningわんさか出たりそれ潰してフラッシュしてUSBが認
識された！と喜んだのもつかの間ポート開いた瞬間に固まったりでもう一回
warningで出てたとこ穴のあくほど見て修正してやった開いた！と思ったら
今度は文字が送信出来てなくてもう一回ソースや海外の掲示板の投稿を穴
のあくほど見てまわりまわった挙句結局最適化のせいだとわかって修正し
てやっとこ使える代物になれたかなでも所詮はDEMOだと言ってしまえば
それで終わりですがそう言い切るのもなんだかな…あーつかれた。
いかんまた前振りが長い。

20110129追:
107系のUSB-OTGの物とソースを一本化し、なおかつエンドポイント３をダブルバッファリング
にしてさらに大量のデータを受信したときに取りこぼすバグを修正しました。~~こちらからどうぞ。~~
おソースはこちらです。USBライブラリV3.1.0のデモを適用してます。
上で長々と書いた私の無駄な努力が修正されています。
(どうやらV3.0.0でもまだ不具合あったみたいですねorz）
20101221追：
　今気づいたけどダブルバッファリング化して動作をさらに安定化させたverにふつー
　のバグ満載verを上書きした状態で放置してました。でもローカルのソースも破棄して
　残してないからもう修正できないやごめんね(ﾃﾍｯ♥

でもこのV3.X.X系ってライブラリの構成が大幅に変わってますね。
調べてみるとこの規格に合わせたといったところでしょうか。
てかこれだいぶ前の情報じゃないか…。
ねむいさんの知識は断片的で非常に危ういです。日々お勉強はつづきます。

あと私が使いやすいように独自の修正加えてます(これまで
公開したのもほとんど私仕様にしちゃったけど)。"Nemui"でコードを
サーチすると何やってるか分かると思いますが、重要なのを一つ。

void Virtual_Com_Port_init()関数開始直後にあるGet_SerialNum();
をコメントアウトしてUSBシリアルナンバを"STM3210"固定にしてます。
どうもこの関数がとってくるユニークIDとやらがうまくシリアルナンバを
反映してくれない。他のUSBデバイスだとあまり気にならないのですがVCPは
COMポートが増設され、違うUSBポートにさすごとにどんどんCOMポートが
増殖していくのでシリアルを固定にしてそれを防がなくてはなりません。
(多分うまくやる方法があるんでしょうけどね、現状はこれで満足…)

以下ねむいさん流仮想COMポートの消し方(WinXP32bit用)
１．提供された仮想COMドライバにアンインストーラがあれば
　　それを使用する。
２．１．が無い場合、
　　環境変数に画像の変数を追加する
　　変数名:DEVMGR_SHOW_NONPRESENT_DEVICES
　　変数値:1
３．パソコンを再起動。
４．ファイル名を指定して実行で"COMPMGMT.MSC"と入力、実行。
５．「デバイスマネージャ」を選択し、ウインドウの表示(V)をクリック。
６．プルダウンメニューの「非表示のデバイスを表示」をクリック。
７．「デバイスマネージャ」-> ポート(COMとLPT)をクリックすると
　　半透明のCOMポートが見える。不透明は現在物理的に繋がっているデバイス。
８．「削除」で憎いあいつを消す！これでCOMポートが消えます。

でも何度も言いますが提供された仮想COMドライバにアンインストーラが
あれば必ずそれを使用しましょうね。

９．たまにB.S.O.D.になって泣く

STM32にJTAG経由でDFUを書き込む

20121108追：
内容がものすごく古てもう実用に耐えない内容なのでこちらを参照してください。
STM32に限らず普遍的な内容を網羅してあります。

急に冷え込みましたね…えっくし
あの子は今寒さに凍えて体を冷やしていないだろうか…？
…温めてやれないのでしんぱいです。

ARM系のCPUでJTAG経由のフラッシュプログラミング方法なんて
巷にものすごく詳しく解説付きであふれてるので、ねむいさん的には
皆さんに全く参考にならない方法を紹介していきたいと思います。

20120517追：
レガシーポートを使用する方法はもうお勧めできません！

●レガシーなLPT経由の方法
私はM570RUのユーザーです。こいつにはLPTなんてレガシーなもの存在
しません。じゃぁどうやってやんだよ！というとExpressCard接続のLPT拡張ユニット
をつかってLPTポートを"物理的に"設けます。昔ながらのIOポート直叩きができます♥

認識されるとこんな感じ。しかし！エクスプレスカード=PCIExpress接続の拡張
LPTなので物理アドレスがいつもの0x378とかじゃなく0x3CD8とかへんてこりんな場所に
置かれます。もちろん0x378にアドレスの変更なんてできませんでしたorz
(物理アドレスもらえるだけマシだが…)

というわけで使えるアプリケーションは限られます。H-JTAGというJTAGサーバー
を提供するソフトは0x3CD8でも設定可能なのでこれが使えます。
~~LPT接続用のJTAGインターフェースの回路図はこちら。Wiggler互換です。~~
なんでJTAGのコネクタをわざわざ10Pinから20Pinに変換してるのかというと、
AVRJTAGICE/JTAGICE mk2とALTERAのJTAGインターフェースがこの10Pinの配列で、
ねむいさん的にはこれを基準としてすべての制作物を合わせているからです。
ARMしか使わない人は元から20Pinでいくか各自のやりやすい配置で行きましょう。

H-JTAGの基本設定はこんな　感じに　してください。
実はWiggler互換じゃなくてもLPTにつながりゃ何でも行ける。
Coretx-M3専用のTAPコントローラの設定は必ず行うこと。
そして難なく認識。
書き込み消去もほとんどストレスなくサクサク行けます。

話変わりますが、なひたふ氏のMITOUJTAG評価版0.31&トラ技特別版は
上記の拡張LPTは一切使用不可でした。0x378,0x3BC,0x278の物理アドレス
しかサポートしてないみたいです。残念。(まぁ評価版だし…)
ちなみにlinuxのioperm()関数とかもサポートするアドレスの範囲が
0x3ffまでなのでそれ使ってる直叩き出来るアプリも全滅。全アドレスに
使えるiopl()関数に適宜書き替えてやる必要性があります。

●USB(JTAGkey互換回路)経由の方法
アマチュアのARM開発ではこちらが今現在最もポピュラーな方法ですね～。
私のM570RUでもこれならスマートかつ無問題です。
(なぜかM570RUは物理COMポートがある。Linuxのデバッグ出力用だろうか？)。

先にも紹介しましたJTAGkey互換回路はかみき氏のものを流用させてもらって
います。扱える電源電圧範囲が1.65V～5Vとだだっ広いです。
+5Vトレラントな2電源レベルシフタのおかげなのですが、JTAGkey単体の評価や
レベルシフタの実力は別件で測ってますのでまた後ほどにでも。

また、かみき氏の回路にAT93C66Aの外付けEEPROM回路をさらに追加して、
Amontec JTAG keyと全く同じVIDとPIDにしています。EEPROMの設定を含めた
ドライバファイルはこちらに。MProgで書き込んでください。

STM32基板との接続も最もポピュラーな構成を流用しています。
STM32(というかARM全般)--JTAGkey互換(FT2232レイヤ)--OpenOCD(server)という
つなげ方です。

20120517追：
OpenOCDを使用した内蔵フラッシュの書き込みはこちらを参照にしてください。

前振り長くなりましたが、DFU(DeviceFirmWare)をJTAGkey互換回路で
STM32に書いてみます。,~~今回のおソースはこちら。~~最新のSTM32-USBファーム
ウエアライブラリとDFUのデモソフトウエアを適用してます。わかっているとは
思いますけど試される時は自己責任でよろしくお願いします。
開始アドレスは0x08000000固定です。makefike内で0x08003000開始も設定
できますけど当然動きません。気を付けてください。

新しいDFUをJTAG経由で書きこんで見ます。成功したときのログは
以下のようになります。STM32はJTAGデバイスが2つ見えます。

> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program

openocd-ftd2xx -f interface/jtagkey.cfg -f target/stm32_flash.cfg -c "flasher main.elf" -c "resume" -c shutdown

Open On-Chip Debugger 0.2.0-in-development (2009-05-09-21:00) svn:1606M

BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS



500 kHz

Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (Manufacturer: 0x23b, Part: 0xba00, Version: 0x3)

Info : JTAG Tap/device matched

Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (Manufacturer: 0x020, Part: 0x6410, Version: 0x1)

Info : JTAG Tap/device matched

Warn : no telnet port specified, using default port 4444

Warn : no gdb port specified, using default port 3333

Warn : no tcl port specified, using default port 6666

Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (Manufacturer: 0x23b, Part: 0xba00, Version: 0x3)

Info : JTAG Tap/device matched

Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (Manufacturer: 0x020, Part: 0x6410, Version: 0x1)

Info : JTAG Tap/device matched

target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0x01000000 pc: 0x08000ed8

Info : device id = 0x20016410

Info : flash size = 128kbytes

stm32x mass erase complete

Info : Padding image section 0 with 0 bytes

Warn : not enough working area available(requested 16384, free 16336)

wrote 8508 byte from file main.elf in 0.640630s (12.969411 kb/s)

verified 8508 bytes in 0.437502s

Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (Manufacturer: 0x23b, Part: 0xba00, Version: 0x3)

Info : JTAG Tap/device matched

Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (Manufacturer: 0x020, Part: 0x6410, Version: 0x1)

Info : JTAG Tap/device matched



> Process Exit Code: 0

> Time Taken: 00:05

DFUが正しく書きこまれていれば、DFUseを起動するとこの画面が見えるはずです。

これでJTAGさえあればDFU書き潰して0x08000000でスタートするプログラム
書きこんでも大丈夫ですね。…と言いたいところですが！
STM32のコアクロックが停止する__WFI命令等を実行しっぱなしの
プログラムを不用意に書きこんでしまうと起動->__WFIでクロック停止->JTAG
インターフェースも仲良くおだんまりとなってJTAG経由のアクセスが
一切できなくなってしまいます!

これを回復するには先日紹介したシステムメモリからのブートでシリアル
経由でフラッシュの消去を一旦行うか、リセットボタン連打しながらJTAG経由で
うまく引っかかるまでひたすら消去動作を行い続ける方法があります
(ファミコンの裏ワザみたいだ)。私としては後者前者の方法を強く強くお勧めします。

STM32のフラッシュプログラミング

当記事の内容はもう古すぎるのでこちらを参照してください。

…あづい…あづいですね…まだ５月なのに～…
まぁおかげでバイト帰りのいなちゃんの汗ｎ

CQ-STARMは最初からUSB経由でファームウエアのアップロードができる
DFUというプログラムが書きこまれているため、外部のプログラマーが
必要ないのが特徴です。

その代り、開発に際してプログラム開始位置は0x08000000->0x08003000
からになる。という制約を受けます。
DFUを使用してアプリケーションを作るときは、0x08003000からプログラムが
スタートするように考慮しなければなりません。DFUのプログラムは
0x08003000に決め打ちですっ飛んで行きますので。
(この辺AVRだと楽なんですよね～、ブート領域がメモリの後方にあって
ヒューズビットでいつでもスイッチできるからアプリの方はプログラム
メモリ容量以外は何も考えなくていいという)

考慮の方法は以下の2点です。
１．ソースコード内の割り込みベクタのアドレスを
0x08000000->0x08003000にする。
２．リンカスクリプト内のスタートアドレスを
0x08000000->0x08003000にする。
デバッグはDFU経由で書いて本ちゃんはまっさらからスタートしたい、
もしくはDFUなんていらんという人もいるでしょう。そういう時こんなの
いちいち書き変えてたらめんどいのでmakefileの記述で一発で切り替え
できるようにしちゃいましょう。

１．の部分、こんな感じで
２．の部分、ここをこうして
 最後にmakeで切り替えられるようにする

と後あと楽です。ケアレスミスもなくなりますし。
~~以前のMassStorageClassDemoにもこれを適用していますので詳しくはこちらをご参照ください。~~
(欲しい人メールくだち)

ちなみにCQ-STARMでDFUを使う場合、USBディスコネクトの回路を追加して
いると「Leave DFU mode」が正しく動くようになります…ってこれが当たり前か。
DFUなぞ使わないという人にはJTAGで書く方法とシリアルで書く方法が
あります。今回はシリアルで書く方法を紹介します。JTAGは次回にでも。

STM32はオンチップフラッシュROM、オンチップSRAM、オンチップのシステム
メモリの3種のブートモードをサポートしていて,DFUや通常のアプリは
フラッシュROM、RAMスタート時はオンチップSRAM、そしてSERIAL経由で
STM32のフラッシュを書き換えたい時はシステムメモリからの起動を選択できます。

JTAGあるしシリアルなんていらんジャンなんていう人もいると思いますが、
変なプログラムを書きこんでしまってJTAGが一切アクセス不可能に陥った
場合、強力な回復手段となるので、このモードがあるというくらいは
覚えておいてくださいね。

私はフラッシュ、システムメモリの2つのブートモードが選択できる
ように拡張基板にタクトスイッチを追加しました。どことどこを繋ぐかはこんなかんじで～
シリアルは、USB-SERIAL変換のICしか使う気がないのでレベル変換かまさ
ずにTTLレベルのままで置いときました。
USB-SERIALのユニットはCP2102使って、TTLレベルでRxD,TxD,GNDの３つだけ
しか使わない凄く小さいのを一つ作っておくと使い回しが効いて楽です。

用意ができたらBOOT0をVCCに吊ったままリセットを解除してシステムメモリ
からの起動を行います。その後PCにインストールしたFlashLoaderDemonstratorを起動します。USB-SERIALが繋がってる仮想COMポートを選択し、正常に通信ができていれば
こういう画面になります。そっからはフラッシュを消したり読んだり
書き替えたりプロテクト掛けたりと自由自在です。
CQ-STARMを仮想COMポートに化かしてももちろん行けます。基板2つもってる人は
一方を仮想COMポートにして試してみるよいでしょう。

MassStorageClass DEMOを動かす

最近工作ものばっかに手を取られて本業の二次裏メイド業が
おろそかになってる私。下描きでほったらかしているいないさんの絵が
早く仕上げてと訴えている。もうちょっと待っててね♥

さて本題、てDWM誌2008年5月号の付属基板と同梱のCDには
DFU経由でCQ-STARM基板に書き込みができるように
いくつかのデモがすぐに使えるようにとdfuファイル形式で
入っていました。しかし、紙面の説明がとても乏しく、そのとおりに
やっても動かない云々の意見と(その対策)が出ていたのは
みなさんご承知のとおりと思います。

この同梱されたdfuファイルというのはCQ-STARM向けではなく
STマイクロが提供する評価キットSTM3210B-EVAL/STM3210E-EVAL
向けのものです。

CQ-STARMはSTM3210B-EVALの回路構成を真似て設計されており、
STM3210B-EVAL向けのdfuデモファイル群も一応動くのですが、
その中でMassStorageClassの奴をそのまま使ってしまうと
ちょっとまずいことが起こります。

CQ-STARM上ではSDカードを挿入したときに必ずLになるポート
が出力になっており、ショートしてCPUおよびSDカードに
ダメージが行きます。どうなってるかはここ見てくださいね。
この件も私が見つけたわけではなく、去年すでに騒がれたこと
なのですが、忘れ去られた頃に新たにCQ-STARMに触る人がいる
かもしれないから書き残しておきます。

以下私が行ったわーくあらうんど。
●ソフトウエア
　初期のデモでは確かSTM3210B-EVAL上のLED４つが同時点灯するという
　コードのようでしたがV3.0.0/V3.0.1のデモコード見ると最小限のLEDのポートが
　出力になるようになってました。~~前回のコードはV3.0.0を適用してあるので~~
　そっちを使ってもらえればいいかなと思います。
　LEDの出力もCQ-STARMに合わせて変えてます。でも下のパタンカットは必須ですよ！

●ハードウエア
　STM3210B-EVALは本来MicroSD搭載なのでライトプロテクトと挿入検知は
　存在しない。だからここにつながるパタンいらないからカット！
　こんな感じで。

ついでだから他の便利な改造も基板に施してますので紹介します。

●USBディスコネクト
　USBのデモにはRESETをかけるとUSBが切り離される"USBディスコネクト"
　のコードが含まれているのですが、CQ-STARMはハード的に駆動させるための回路
　が存在しません。したがってDFUで書いてはUSBケーブル抜きを繰り返す
　必要があり非常にめどいです。だからこの部分を追加。
　具体的な改造はこんな感じ。パタンカットもなくビアとポリイミド
　テープを駆使してなんなく達成。これでUSB-miniBコネクタが激しい抜き差しで
　ｶﾞﾊﾞｶﾞﾊﾞになるのを避けられます。

●加速度センサにコンデンサ追加
　加速度センサ周りに10uFのチップセラコンと1nFのチップセラコンを追加する。
　これは加速度センサの指示ですね。つうか本来はじっそうすべきなのですがなぜか
　この基板を設計した人はそれを無視して動作不安定になるような回路設計を
　してらっしゃいます。

　10uFのチップセラコンは+3.3V系以下の系では秋月のこれを愛用してます。
　こいつは2012サイズなのに大容量でかつ静電容量変化率も少ないので、
　セラミックコンデンサ対応のLDOとも相性バッチリです。
　
　1nFのチップセラコンは1608のをビアと近接のGNDパタンはがして実装。
　10uFの方は元の1uFは一旦どいてもらってポリイミドでガードした上
　に仲良く同居。こんな感じで。

使ってみた感じですが、わたしの手持ちの256Mb,512MB,1GB,2GBはすべて
Windows上のディスクドライブとして認識、読み書きもできました。
残念ながらSDHCはファームウエアで対応しておらず認識できないようです。

開発環境を整える(自分流に)

今日は日が照って暑いですね～。私はここぞとばかりに押し入れにしまってた
夏服をひっぱりだして片っ端から洗濯していました。もう夏は目の前です。

それはおいといてネット上ではGCC+Eclipseを用いて無償でできる
ARM開発環境の構築法がすでに一般的に広まっていますね。
私もタｄ…GCC派ですがEclipseは使わず自分流の環境をおっ立ててやってます。
…うｎ、使いこなすまでのあれやこれやの設定とかがめどかっただけなんだ…。

20110728追：ビルド方法はこちらに誘導します

雑誌付録基板CQ-STARM(STM32)

去年、同基板の幾つかのサンプルをGNU Cにポーティングしてそれっきりに
していましたが、がた老氏が同基板で奮戦されているのに感化されて私も過去に
やってきたことを残すことにしました。

とりあえずマイコン工作基本の'き'であるLEDチカチカから始めてみましょう。
私はARMの開発環境としてRaisonanceのRIDEをインストールしてます。
実際RIDEも中身は「Codesourcery G++ lite for ARM」のツールチェインなんで
CodeSourceryでやってる人はそっちでも行けます。

~~プログラムはこちら。自己責任でどうぞ。~~
※ソースコードほしい方はめーるくだち

Martin Thomas氏のLED点滅プログラムをベースにSTM32の最新のファームウエア
ライブラリを組み込んでSTM32基板に対応したものを作りました。
printf,sprintf等の標準関数を正常に動かすためにRaisonance付属のリンカスクリプトや
その他もろもろをいじりまくりです。
この辺は長くなるのでまた改めて説明します。とりあえず動かす！

…今Martin氏のページ見にいったらChanさんのFATFS乗っけた作例を
アップデートされてますね～。試してみたいが時間が…

いなちゃんかわかわ

思うところあって私もブログ始めてみました～。
虹裏メイドな私ですがジャンルは技術系で
攻めてみよう　か　な　と思います…。

↑とりあえずSTM32Primer使っていなちゃんを写してみる
…はぁ～…やっぱりかわいいなぁ♥♥

…いいのかいきなりこんなんで

<< November 2024 >>

Sun Mon Tue Wed Thu Fri Sat

1 2

3 4 5 6 7 8 9

10 11 12 13 14 15 16

17 18 19 20 21 22 23

24 25 26 27 28 29 30
- ネムイ・トリノミアス
Foreign Visitors,See This First

免責・連絡先は↑のリンクを

ChaN's FatFs Projects and
OpenOCD Binary are Here.
おきぱはここ！

↓SNSもやってます↓
powered by まめわざ

- ARM/STM32 (116)
- OpenOCD (27)
- ARM/NxP (34)
- ARM/Cypress (5)
- ARM/Others (3)
- ARM/Raspi (1)
- AVR (13)
- FPGA (4)
- GPS/GNSS (19)
- MISC (81)
- STM8 (2)
- Wirelessなアレ (16)
- おきぱ (1)
- ブラウザベンチマーク (28)
- 日本の自然歩道 (25)
- STM32U0はぢめました
  ⇒ ねむい (08/07)
- STM32U0はぢめました
  ⇒ ひかわ (07/28)
- STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
  ⇒ ねむい (05/17)
- STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
  ⇒ どじょりん (05/16)
- STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
  ⇒ どじょりん (05/16)
- いろいろ試す61(と今年の反省会)
  ⇒ ねむい (01/02)
- いろいろ試す61(と今年の反省会)
  ⇒ ひかわ (01/02)
- いろいろ試す61(と今年の反省会)
  ⇒ ひかわ (01/01)
- STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
  ⇒ ねむい (12/31)
- STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
  ⇒ ひかわ (12/31)
- October 2024 (1)
- September 2024 (1)
- August 2024 (1)
- July 2024 (1)
- June 2024 (1)
- May 2024 (1)
- April 2024 (1)
- March 2024 (1)
- February 2024 (2)
- January 2024 (1)
- December 2023 (4)
- November 2023 (2)
- October 2023 (2)
- September 2023 (1)
- August 2023 (2)
- July 2023 (1)
- June 2023 (2)
- May 2023 (3)
- April 2023 (1)
- March 2023 (1)
- February 2023 (1)
- January 2023 (1)
- December 2022 (2)
- November 2022 (1)
- October 2022 (1)
- September 2022 (1)
- August 2022 (1)
- July 2022 (1)
- June 2022 (1)
- May 2022 (1)
- April 2022 (1)
- March 2022 (1)
- February 2022 (1)
- January 2022 (1)
- December 2021 (2)
- November 2021 (2)
- October 2021 (1)
- September 2021 (1)
- August 2021 (1)
- July 2021 (1)
- June 2021 (1)
- May 2021 (1)
- April 2021 (1)
- March 2021 (1)
- February 2021 (1)
- January 2021 (1)
- December 2020 (3)
- November 2020 (1)
- October 2020 (1)
- September 2020 (1)
- August 2020 (1)
- July 2020 (1)
- June 2020 (2)
- May 2020 (1)
- April 2020 (1)
- March 2020 (1)
- February 2020 (1)
- January 2020 (1)
- December 2019 (3)
- November 2019 (1)
- October 2019 (1)
- September 2019 (2)
- August 2019 (1)
- July 2019 (1)
- June 2019 (1)
- May 2019 (1)
- April 2019 (1)
- March 2019 (1)
- February 2019 (1)
- January 2019 (1)
- December 2018 (3)
- November 2018 (2)
- October 2018 (1)
- September 2018 (1)
- August 2018 (1)
- July 2018 (1)
- June 2018 (1)
- May 2018 (1)
- April 2018 (2)
- March 2018 (1)
- February 2018 (1)
- January 2018 (1)
- December 2017 (2)
- November 2017 (2)
- October 2017 (1)
- September 2017 (1)
- August 2017 (1)
- July 2017 (1)
- June 2017 (1)
- May 2017 (1)
- April 2017 (1)
- March 2017 (2)
- February 2017 (2)
- January 2017 (2)
- December 2016 (7)
- November 2016 (2)
- October 2016 (2)
- September 2016 (1)
- August 2016 (1)
- July 2016 (1)
- June 2016 (1)
- May 2016 (2)
- April 2016 (1)
- March 2016 (2)
- February 2016 (1)
- January 2016 (1)
- December 2015 (3)
- November 2015 (1)
- October 2015 (3)
- September 2015 (2)
- August 2015 (2)
- July 2015 (3)
- June 2015 (3)
- May 2015 (4)
- April 2015 (2)
- March 2015 (4)
- February 2015 (1)
- January 2015 (3)
- December 2014 (3)
- November 2014 (2)
- October 2014 (1)
- September 2014 (2)
- August 2014 (2)
- July 2014 (3)
- June 2014 (2)
- May 2014 (1)
- April 2014 (1)
- March 2014 (4)
- February 2014 (4)
- January 2014 (3)
- December 2013 (5)
- November 2013 (4)
- October 2013 (3)
- September 2013 (2)
- August 2013 (2)
- July 2013 (2)
- June 2013 (3)
- May 2013 (2)
- April 2013 (2)
- March 2013 (2)
- February 2013 (2)
- January 2013 (3)
- December 2012 (4)
- November 2012 (2)
- October 2012 (2)
- September 2012 (4)
- August 2012 (1)
- July 2012 (3)
- June 2012 (2)
- May 2012 (3)
- April 2012 (3)
- March 2012 (2)
- February 2012 (3)
- January 2012 (3)
- December 2011 (5)
- November 2011 (3)
- October 2011 (2)
- September 2011 (2)
- August 2011 (2)
- July 2011 (2)
- June 2011 (2)
- May 2011 (2)
- April 2011 (2)
- March 2011 (2)
- February 2011 (2)
- January 2011 (3)
- December 2010 (7)
- November 2010 (1)
- October 2010 (1)
- September 2010 (1)
- August 2010 (3)
- July 2010 (4)
- May 2010 (1)
- April 2010 (2)
- March 2010 (2)
- February 2010 (2)
- January 2010 (3)
- December 2009 (3)
- November 2009 (8)
- October 2009 (7)
- September 2009 (5)
- August 2009 (4)
- July 2009 (6)
- June 2009 (6)
- May 2009 (14)
- January 1970 (1)

<< November 2024 >>
Sun	Mon	Tue	Wed	Thu	Fri	Sat
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30