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, ®_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へと
繋げて行きたいとおもいます！！
いろいろ試す53
副業(本業は二次裏メイド)が激務になったのと秋の登山ラリーが始まったので
まったく時間が取れてませんが何とか進めていきたいと思います…
●ようやくSWDマルチドロップも使い物に･･･！
-OpenOCD-0.12.0-RC2更新-
長かった…ラズパイピコが登場してから長い戦いだったがようやく本家にも
安定した状態で取り込まれたようですね…感無量です。
↓以下RaspiPicoに書き込んだところのログ
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jtagkey2_swd.cfg -f target/rp2040_swd_flash.cfg -c "mt_flash_bin main.bin 0x10000000"
Open On-Chip Debugger 0.12.0-rc2+dev-00001-g12ce17094 (2022-10-30-22:35)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : FTDI SWD mode enabled
Warn : Transport "swd" was already selected
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x0bc12477, DLPIDR 0x00000001
Info : SWD DPIDR 0x0bc12477, DLPIDR 0x10000001
Info : [rp2040.core0] Cortex-M0+ r0p1 processor detected
Info : [rp2040.core0] target has 4 breakpoints, 2 watchpoints
Info : [rp2040.core1] Cortex-M0+ r0p1 processor detected
Info : [rp2040.core1] target has 4 breakpoints, 2 watchpoints
Info : starting gdb server for rp2040.core0 on 3333
Info : Listening on port 3333 for gdb connections
Info : starting gdb server for rp2040.core1 on 3334
Info : Listening on port 3334 for gdb connections
[rp2040.core0] halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00
[rp2040.core1] halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00
Info : Found flash device 'win w25q16jv' (ID 0x001540ef)
Info : RP2040 B0 Flash Probe: 2097152 bytes @0x10000000, in 32 sectors
Info : Padding image section 0 at 0x1001fe80 with 128 bytes (bank write end alignment)
Warn : Adding extra erase range, 0x1001ff00 .. 0x1001ffff
Info : wrote 130816 bytes from file main.bin in 4.495757s (28.416 KiB/s)
Info : verified 130688 bytes in 0.206712s (617.405 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:05コアがちゃんと2つ見えているのがわかりますね〜
また、注目すべき点はコアの数だけgdbサーバのポートも増加している点です
デバッグ時はgdbも一個ずつ起動してつなげていきます
openocdも0.12.0になってARM以外のかなりのCPUコアもサポートしています。
STM8はすでに書き込みデバッグに成功していますが新規にサポートされた
RISCVのGD32V系、また本家にサポートが取り込まれたESP32などはまだ全くの
手付かずなのでこれから挑戦していきたいと思います！
というところでねむいさん特製ビルドのOpenOCDはこちらになりますので
どしどしお使いください…！
●で、CodeLiteとGDBを使ったデバッグはどうなったの？
…正直まだ検証が進んでません…
10年同じ事やってたのでtarget extended-remoteってなんだよってとこから
再開ですしSTM32の検証がやっと終わってほかのcortex-M、あとARM7TDMIも
見ていこうと思ってますがすべてのCPUで安定して動かせられるパタンが中々
見つからず苦戦しています。
・今できてること
→ステップ実行(ステップイン/ステップアウト)
→ブレークポイント
→変数読み取り
・InsightではできたがCodeLiteでできなくなったこと
→IOViewでペリフェラルを直感的にたたけなくなった
(gdbのprintコマンドでせこせこ変えるしかない)
→main関数内の最上位でステップアウトをうっかりやらかすと死ぬ
→ブレークポイントを設定しないでrunさせたら死ぬ
→調子おかしくなったと感じてstopしてもgdbにコマンドがなぜか通らず死ぬ
→とにかく機嫌損ねたら死ぬ
死んだらこちらも能動的に殺しにかかってtaskkillコマンドでOpenOCDごと
強制終了してつなぎなおしてます。Insight時代からやってましたがよく
わからなくなったら全部終了で再開するのが最適だと感じてます。
画像はNuvotonのnano130のデバッグ終了時の画面です…いささか強引ですが
これが一番楽…とこんな感じでLPC系のマイコンとかも確認を進めていきます。
●avrdudeがものすごく中身変わっていた
avrdudeがすさまじい勢いで修正がかかりまくりどんどん進化してます
当然途中で大変更が発生することもあり、これで深刻な影響を受けるのは
たいていビルドする人間です…orzビルドが通らなくなったorz
今回readline周りが大幅変更でまともにビルド通らず動かずで難儀しましたが
何とか安定して動かすことができました…細かいことは省きますがreadlineが
dllとして追加になりました。もちろん自前ビルドです。
以下avr128da48に書き込んだ時のログ
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
C:/Devz/AVR/avrdude/avrdude -v -p avr128da48 -P usb -c pkobn_updi -U flash:w:main.bin
avrdude: Version 7.0-20220508
Copyright (c) Brian Dean, http://www.bdmicro.com/
Copyright (c) Joerg Wunsch
System wide configuration file is C:¥Devz¥AVR¥avrdude¥avrdude.conf
avrdude: input file main.bin auto detected as raw binary
Using Port : usb
Using Programmer : pkobn_updi
avrdude: found CMSIS-DAP compliant device, using EDBG protocol
AVR Part : AVR128DA48
RESET disposition : dedicated
RETRY pulse : SCK
Serial program mode : yes
Parallel program mode : yes
Memory Detail :
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
fuse0 wdtcfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse1 bodcfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse2 osccfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse4 tcd0cfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse5 syscfg0 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse6 syscfg1 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse7 codesize 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse8 bootsize 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuses 0 0 0 0 no 9 16 0 0 0 0x00 0x00
lock 0 0 0 0 no 4 1 0 0 0 0x00 0x00
tempsense 0 0 0 0 no 2 1 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 1 0 0 0 0x00 0x00
prodsig 0 0 0 0 no 125 125 0 0 0 0x00 0x00
sernum 0 0 0 0 no 16 1 0 0 0 0x00 0x00
userrow usersig 0 0 0 0 no 32 32 0 0 0 0x00 0x00
data 0 0 0 0 no 0 1 0 0 0 0x00 0x00
eeprom 0 0 0 0 no 512 1 0 0 0 0x00 0x00
flash 0 0 0 0 no 131072 512 0 0 0 0x00 0x00
Programmer Type : JTAGICE3_UPDI
Description : Curiosity nano (nEDBG) in UPDI mode
ICE HW version : 0
ICE FW version : 1.21 (rel. 37)
Serial number : MCHP3280031800001375
Vtarget : 3.31 V
PDI/UPDI clock Xmega/megaAVR : 100 kHz
avrdude: partial Family_ID returned: " "
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9708 (probably avr128da48)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
To disable this feature, specify the -D option.
erasing chip
avrdude: reading input file main.bin for flash
with 3392 bytes in 1 section within [0, 0xd3f]
using 7 pages and 192 pad bytes
avrdude: writing 3392 bytes flash ...
Writing | ################################################## | 100% 1.09s
avrdude: 3392 bytes of flash written
avrdude: verifying flash memory against main.bin
Reading | ################################################## | 100% 0.60s
avrdude: 3392 bytes of flash verified
avrdude done. Thank you.
> Process Exit Code: 0
> Time Taken: 00:02
正直大変更前と見た目は全く変わらないので見栄えがしませんがいろんな人の努力で
どんどん機能がパワーアップしていくわけですね…
avrdudeの10月末最新のバイナリもアップロードしました。
こちらもどんどん使ってくださいませ〜！
いろいろ試す52
●CodeLite+GDBを使ったARMデバッグ環境移行加速す！
oh...myｺﾝﾌﾞ･･･とうとうこの日がやってきた…
InsightだとGCC12からサポートされたdwarf5フォーマットのelfが読めない…
ARM-GCCのバグのせいかdwarf4形式のリンカオプションつけてもdwarf5･･･
orz
というわけでねむいさんのぶろぐ旗揚げから13年間続けてきたInsightによる
デバッグ法に別れを告げ、かねてより評価中のCodeLiteによるGDBデバッグ
環境移行と同手順書作成に本腰を入れております！
移行で一番の障壁はworkspaceの概念でしたが…幸いにもディレクトリを遡る
相対アクセスが問題なくできたのでmain.elfを相対参照するようにしたら
デバッグするたびいちいち設定しなおす必要もなく同一のworkspaceファイル
の使いまわしができそうです！
CodeLite.exeはなんでかgnumake3.81から直接召喚できなかったのでwindowsの
CMDでの機能で代用しました。ちゃんと引数付きで呼び出しもできたので
ここで上で説明したworkspaceファイルを相対アクセスで開きます。
実際のデバッグ画面です。
ソースレベルでステップ実行とかの基本は当たり前の余裕ですね。
InsightではWin10では即堕ちして使いものにならなかったCPUレジスタ参照は
バリバリできています。
F7,H7の浮動小数点レジスタも楽勝です♨
…なのですがなんでかこれらレジスタ表記は10進数(一部は16進数)固定で、
進数の切り替えができません。Insightでは柔軟にできてたのでここに
ついては要改善ポインツですね。
また、周辺I/Oのレジスタ値を直接参照するIOView機能とかも一応使えます。
IOViewは周辺レジスタをconst宣言しているせいか、変数参照ウインドウから
直接値を変えられませんでした。
constでも値を自由に変えられちゃうInsightのほうが逆にダメだったのかも。
回避策としてOutputウインドウからコマンド直接入力で値を変えられます。
Outputウインドウと銘打ってますがGDBのコマンド入力も受け付けています。
そして特筆すべきはInsightとは違いGDBから完全に独立したGUIとして働くので
ARMだけではなく他のCPUコアでもそれ用のGDBさえあてがえば普通に使えます！
先月紹介したSTM8Lもご覧の通りばりばりデバッグ可能です！
ていうかSTM8Lの記事ぶん投げっぱなしですが来月がんばります！！！！
となるとESP32とAVRのデバッグ環境もCodeLiteで一括化できそうなので、特に
5年くらい放置してるESP32とかはやる気出てまた活動再開できそうな感じです☆
ARMマイコンビルド/デバッグ環境構築手順もCodeLite+GDBデバッグを主眼にした
2022年版に書き替えている最中ですのでこうご期待！
また、待ちきれない方に先んじてWin10環境下でCodeLite+GDBのデバッグ環境
対応のプロジェクトに更新しております。現在以下のものが対象です!
・STM32H7-Disco
・STM32F7-Disco
・STM32F4-Discovery
・STM32G0ベアメタル
●ARM-GCCがまたアップデートしていた。
まず、前回のいろいろ試すでアップデートされたGCCでビルドすると…
前回記事にしていたにかかわらずこれ気づかんかった…
ちゃんと検証してなかったのバレバレの私orz
これかなり致命的なバグでしたね…私のおきぱのプロジェクトがほぼビルド
不可能状態でした…すみません。
これ前回のいろいろ試すにも警告書いときます。
現行のGCC11.3ものは緊急修正が加わってちゃんとビルドできるようになってます。
が、冒頭のdwarf5の問題でInsightデバッグができなくなってますので要注意！
●AVRDUDEにパッチを投げたお話
これも9年越しの話なのですがねむいさんはJTAGKEY等のFT2232系のISP/JTAG
書き込みで、1セクタサイズ以下のサイズのバイナリを書こうとしたら正常に
書き込めないバグを見つけておりました。しかし、そんな超限定された条件、
例えば128kByteの容量を持つatmega1284p(フラッシュセクタサイズ256Byte)に
たった202バイトの容量のLチカプログラムを書き込むやつがいるだろうか？
という原因からか9年放置されていました。
が、オワコン化したかと思われたavrdudeがgithubに移行したとたんバリバリ
更新がかかりまくるようになり、9年前の問題が再び目に留まったのでわたしも
この問題に決着をつけるべく参戦を果たしました！！！
(☝お前AVR辞めたんちゃうんかいという突っ込みは一切なしで)
その後、管理者の人のコードレビューと別の修正が合体して正式にコミット
されています。
リンク先の議論にもありますがねむいさん的には符号付整数で比較を
行うと符号拡張で符号なし整数では思わぬでかい数字が入ってしまって
思ったような評価ができないのを危惧したのですが最終的に符号なし
整数同士の評価で終わるようにしてくれて実際に問題なく書き込みが
できるようになったのでよしとしましょう。
いろいろ試す49
●OpenOCDでマルチコアデバッグするやり方
竹本様よりコメントでお題をいただいたのでトリプルコア搭載のLPC4370ボード、
LPC-Link2を使って実践してみました。
まずねむいさんのOpenOCDバイナリの/tcl/targetlpc4370_lpclink2_spifi.cfgを
編集します。デフォルトはm4コアしか有効にしていませんがm0subを有効にします。
�，鉢△良�分が編集した部分です。
m0appは電源投入直後は寝ているので今回は省きます。
なお順番が重要でm4コアを必ず先頭に持ってきておきましょう。
まずOpenOCDを起動したらm4コアにアタッチします。insightでつなぎます。
insightではTCPポート3333のm4コアがつながります。
openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/jtagkey2.cfg -f target/lpc4370_lpclink2_spifi.cfg -c "reset halt" -c"arm semihosting enable"
C:/Devz/ARM/insight/bin/arm-none-eabi-insight --eval-command="target remote localhost:3333" --eval-command="tbreak main" --nx main.elf
Open On-Chip Debugger 0.11.0+dev-00365-g9a9e9e2c6 (2021-08-31-11:31)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "jtag". To override use 'transport select '.
Info : clock speed 2000 kHz
Info : JTAG tap: lpc4370.m4 tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd), part: 0xba00, ver: 0x4)
Info : JTAG tap: lpc4370.m0_APP tap/device found: 0x0ba01477 (mfg: 0x23b (ARM Ltd), part: 0xba01, ver: 0x0)
Info : JTAG tap: lpc4370.m0_SUB tap/device found: 0x0ba01477 (mfg: 0x23b (ARM Ltd), part: 0xba01, ver: 0x0)
Info : lpc4370.m4: hardware has 6 breakpoints, 4 watchpoints
Info : lpc4370.m0_SUB: hardware has 2 breakpoints, 1 watchpoints
Info : starting gdb server for lpc4370.m4 on 3333
Info : Listening on port 3333 for gdb connections
Info : starting gdb server for lpc4370.m0_SUB on 3334
Info : Listening on port 3334 for gdb connections
Info : JTAG tap: lpc4370.m4 tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd), part: 0xba00, ver: 0x4)
Info : JTAG tap: lpc4370.m0_APP tap/device found: 0x0ba01477 (mfg: 0x23b (ARM Ltd), part: 0xba01, ver: 0x0)
Info : JTAG tap: lpc4370.m0_SUB tap/device found: 0x0ba01477 (mfg: 0x23b (ARM Ltd), part: 0xba01, ver: 0x0)
Warn : Only resetting the Cortex-M core, use a reset-init event handler to reset any peripherals or configure hardware srst support.
Warn : VECTRESET is not supported on this Cortex-M core, using SYSRESETREQ instead.
Warn : Set 'cortex_m reset_config sysresetreq'.
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
target halted due to debug-request, current mode: Thread
xPSR: 0xc0000000 pc: 0x555d36cc msp: 0x675f04e0
Info : JTAG tap: lpc4370.m4 tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd), part: 0xba00, ver: 0x4)
Info : JTAG tap: lpc4370.m0_APP tap/device found: 0x0ba01477 (mfg: 0x23b (ARM Ltd), part: 0xba01, ver: 0x0)
Info : JTAG tap: lpc4370.m0_SUB tap/device found: 0x0ba01477 (mfg: 0x23b (ARM Ltd), part: 0xba01, ver: 0x0)
Warn : Only resetting the Cortex-M core, use a reset-init event handler to reset any peripherals or configure hardware srst support.
Warn : VECTRESET is not supported on this Cortex-M core, using SYSRESETREQ instead.
Warn : Set 'cortex_m reset_config sysresetreq'.
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
target halted due to debug-request, current mode: Thread
xPSR: 0xc0000000 pc: 0x555d36cc msp: 0x675f04e0
semihosting is enabled
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : accepting 'gdb' connection on tcp/3333
Info : JTAG tap: lpc4370.m4 tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd), part: 0xba00, ver: 0x4)
Info : JTAG tap: lpc4370.m0_APP tap/device found: 0x0ba01477 (mfg: 0x23b (ARM Ltd), part: 0xba01, ver: 0x0)
Info : JTAG tap: lpc4370.m0_SUB tap/device found: 0x0ba01477 (mfg: 0x23b (ARM Ltd), part: 0xba01, ver: 0x0)
Warn : Only resetting the Cortex-M core, use a reset-init event handler to reset any peripherals or configure hardware srst support.
Warn : VECTRESET is not supported on this Cortex-M core, using SYSRESETREQ instead.
Warn : Set 'cortex_m reset_config sysresetreq'.
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
target halted due to debug-request, current mode: Thread
xPSR: 0xc0000000 pc: 0x555d36cc msp: 0x675f04e0, semihosting
Info : Found flash device 'win w25q80bv' (ID 0x001440ef)
Info : New GDB Connection: 1, Target lpc4370.m4, state: halted
Warn : Prefer GDB command "target extended-remote :3333" instead of "target remote :3333"
Error: JTAG-DP STICKY ERROR
Error: Failed to read memory at 0xfffff000 接続時のログになりますがTCPポート3333に加えてインクリメントされた
値の3334が追加されます。この3334がm0subのコア用のポートとなります。
お次はgdbを別口で起動します。
"target extended-remote localhost:3334"とします。
m0用のプログラム走らせてないのでsticky-errorは出てますが
m0コアにはしっかりアタッチできております！
こんな感じでマルチコア当たり前になった昨今ですがOpenOCDを駆使して
バンバンデバッグしていきましょう！
20230927追:
KYF39でもうできなくなってしまいました！！！！F**U**CK!!!
ねむいさんは元来よりSBIネット銀行を利用しております。
利用状況に応じて振込手数料が無料になる回数が増えるスマートプログラムなるものが
あるのですが今年の４月に大改悪しやがりましてスマホでSBIのアプリを入れてスマート
認証NEOなるものを導入しないと自動的に最低ランクになってしまう事態となりました！！
まぁ素直にスマホにインストールすればと思いでしょうが、ねむいさんが持っている通信
端末KYF39は旧世代の人間向けのガラホでこれは普通の方法ではSBIアプリをインストール
できません！！FUCK!!
というわけでこいつに無理やりSBIアプリをインストールしてスマート認証NEOを設定する
方法を紹介します。windows10環境下で行います。
ここから先は自己責任でお願いします！
(注:私も手探りで行いましたので内容は適宜増強していきます)
1.APKをダウンロードする
まずはAPKをダウンロードしないと話になりません。
KYF39はgoogleplayが使えないのでapkcomboというサイトからapkをダウンロードします。
https://apkcombo.com/ja/zhu-xinsbinetto-yin-xing/jp.co.netbk/
それとSMS認証突破するためにSMSforwarderが必要なのでこれも落とします。
https://apkcombo.com/ja/sms-forwarder-auto-forward-sms-to-pc-or-phone/enstone.smsfw.app/
2.APKインストールまで
すみません超手抜きですがとりあえずこちらの方のわかりやすい手順に倣います。
KYF35をお使いですがandroidなのでやってることは一緒です。
SBIアプリとSMSforwarderのインストール順は特に気にしなくてもよいですが
設定は必ずSMSforwarderから行います。
3.SMSforwarderの設定を先に行う
SMS認証のメッセージを自分のPCのメールアドレスから出すようにフォワードさせます。
メールの送付先は送信に使ったメールアドレスにしておきましょう。
なんでこんなめんどくさいことするかというとKYF39デフォルトの+messgaeで見ようとするとなんと今までやったSBIスマート認証NEOの設定がキャンセルされたことに
なってしまい、先に進めなくなるからです！！！！
4.SBIスマート認証の設定を行う
ログイン名とパスワード、認証用PINコードの設定を行います。
SMSforwarderがちゃんと機能していればPCのメールアドレスにsms認証の内容が
来ますのでそれを打ち込み認証完了です！！！
SBIの管理画面からもちゃんとスマート認証NEOが登録されています。
できた…長い戦いだった…
なお、残念ながらKYF39からは残高確認ができずエラー画面となりますが
肝心の振込操作の時の認証操作については何も問題はないのでご安心ください。
そんなわけで時代から取り残されるとこんな不便な目に遭遇するというほとんどの
方にとってはどうでもいい旧世代型レプリロイドのぼやきでした。かしこ。
大緊急事案！！！１！Raspberry Pi Picoはぢめました！！１！！１
●なにっ
超小型linuxPCの代名詞となったRaspberryPiですがNanoに加えてPicoなるものも
ラインナップに加わりました！！
秋月電子通商さんで550円ですでに販売されており、すでに手に入れられた方も
いるかと思います。ねむいさんも早速購入していぢって見ることにしました！！！
基板としてはRaspiNanoよりも一回り小さいサイズとなっております。
MPUはARMのCortex-M0plusのデュアルコア構成、Raspberry財団のロゴが
レーザーマーキングされた特製のものとなっております！
しかもM0+のコアながら100MHz越えの高速クロックで動く代物です！！
※細かいスペックは次回以降に紹介します。
●とりあえず動かしてみる
USB-microコネクタから給電するとフラッシュに何も書いてないときもしくは
BOOLSELボタンを押しながら給電するとマスストレージとして見えます。
binファイルではなくuf2(USB Flashing Format Data)をドラッグアンド
ドロップすることにより内蔵フラッシュに書き込まれるようです。
RaspiPicoの公式ページにはGettingStartとしてこのD&Dで始める方法が紹介
されており動作確認用のuf2ファイルも落とせます。
これでLチカを確認できます。
●プログラムのビルド方法は？
同じくGettingStartedに方法が書いてあります。OS間で共通する項目は
SDKを使いCMAKEとPythonでmakefileを生成してビルドするということです…
…CMAKEってねむいさん嫌いなんですよね…記述がちょっとでも抜けてたら
思った通りに動作しなくて…Raspiなので基本的にLinux系OS下のビルドを前提と
しています。
幸いにもWindows環境下のビルド指南もしております。
もちろんCMakeとPythonとVisualStudioCodeが必要です。が、ねむいさんは
中途半端にMSYSのOpenOCDビルド環境を持っているのでそちらと折半して
ビルドしてみました。
…
(格闘すること2時間後)
あああもうめちゃくちゃだよ
make一発で出来るようにシンプルなライブラリの構成にしてほしかった…！
しかも一度に全部のプロジェクトをビルドしやがるのでものすごく時間がかかります。
※ねむいさん式RaspiPicoビルド環境は次回以降に(またかいな
●ビルドしたやつをどう書き込むのか？
ビルドしたプログラムを書き込むだけなら上記のUF2ファイルをマスストレージ
モードでD&Dで書き込む方法がありますがねむいさんがそんなので済ませるわけは
ありません！！！
Cortex-M0+コアなのでOpenOCDが使えるはずです…がデュアルコアかつSWDオンリー
なので無理か…と思いきやRaspberryPi公式でOpenOCDをRP2040用にFork
しており、こちらはなんとマルチドロップSWDとRP2040のフラッシュ
書き込みドライバの対応済です！！
画像の上部に写ってるｲﾗｽﾂは気にしてはいけない。
RP2040用の書き込みcfgも作成してRaspiPico専用OpenOCD+JTAGKey2を使って
RaspiPicoにelfファイルを書き込みせしめることに成功しました！！！！
ログはこんな感じになります。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd-pi -s C:/Devz/ARM/OCD/tcl -f interface/jtagkey2_swd.cfg -f target/rp2040_swd_flash.cfg -c "mt_flash blink.elf"
Open On-Chip Debugger 0.10.0+dev-gf8e14ec97 (2021-02-07-14:35)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : FTDI SWD mode enabled
Info : Hardware thread awareness created
Info : Hardware thread awareness created
Info : RP2040 Flash Bank Command
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x0bc12477
Info : SWD DLPIDR 0x00000001
Info : SWD DPIDR 0x0bc12477
Info : SWD DLPIDR 0x10000001
Info : rp2040.core0: hardware has 4 breakpoints, 2 watchpoints
Info : rp2040.core1: hardware has 4 breakpoints, 2 watchpoints
Info : starting gdb server for rp2040.core0 on 3333
Info : Listening on port 3333 for gdb connections
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00
Info : RP2040 B0 Flash Probe: 2097152 bytes @10000000, in 512 sectors
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
Info : Writing 16384 bytes starting at 0x0
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:01
そんなわけでとりあえずほんとに基本だけ紹介してみましたが次回以降は
RP2040のMPUスペックやメモリ構成などの深い部分に突っ込んでいこうと思います！
それに先立ってRaspiPico(RP2040)用のOpenOCDバイナリを公開いたします。
ねむいさんのいつものOpenOCDバイナリに書き込み用cfgとともに同梱しておりまので
どしどしご利用ください！！！！
↑RaspiPico専用OpenOCD:openocd-pi.exe
同じく専用cfg:target/rp2040_swd_flash.cfg
AVR再びはぢめました(ATTINY104とATTINY202を使ってみる)
●AVRは生きていた！
ねむいさんが東海自然歩道とか熊野古道とかを進軍しているうちに時代は
変わり、同じく8bitマイコンの世界も大きく変わっておりました…
今から三年前、ねむいさんはMicrochipに吸収されたATMELが擁していた
AVRに別れを告げて32bitマイコンの世界にどっぷりつかりこんだつもりでしたが…
AVRはMicrochipの庇護下で命脈を保ち、さらに現代風にリニューアルして
復活をしていた！！
秋月電気通商さんでAVR-0世代のATTINY202が発売されたのを機にねむいさんも
かつて背を向けたAVRに再び向き合うことにしました…！
そのまえに
●まずは旧世代のATTINY104
ATMEL時代の最後の嫡子ATTINY10xシリーズもついでに触ってみることにしました。
同じく秋月さんからATTINY104版のAtmelXplainedの在庫があったので
ATTINY202を買うついでにゲッツしました。
Xplained系は1000円台で純正デバッガmEDBGがついているのでお得です☆
ATTINY10xシリーズは旧世代のAVRシリーズであり、私が過去使用していた
XMEGA以前のAVRシリーズと同様のアーキテクチャーとなっています。
Lチカ程度なら余裕ですｎ…
なんとAVR-GCCがATTINY104に対応していなかった！！！orz
ATMEL STUDIOみたいな出来合いのツール使うのならば全く問題がないのですが
ねむいさんはコマンドラインビルド教なのでこれはきつい。
結局ﾏｶｰの人がやった手順をなぞってavr-gccをATTINY10xに対応させて
ビルドしました。
書き込みはAVRDUDEを使ってXplainedに内蔵されたmEDBG(tpi接続)経由で
かきこみをおこな…i…
tpiで書き込めねぇ！！！！orz
Xplained系のATMEL評価ボード内蔵のmEDBGはAvrdudeではjtag3という
デバイス扱いで繋ぎに行くのですがなんとソースコードレベルで
jtag3のtpiモードに対応してなかったorzもう6年以上たってるのになんで…
ATMELSTUDIOからならちゃんと読み書きできるんですけどね…
atmega1284pなのは気にしないでください。大昔の1284pのプロジェクトから
転用してATTINY104のプロジェクトこしらえたもので…
さて、ねむいさんはAvrdudeでどうしても書き込みしたかった。
Avrdudeのソースコード追ってくと手持ちのライタで書き込みができそう
だったのはLUFAとFTDI系でした。
まずはLUFAのAVRISPmk2化したATUSBKEYでtpi書き込み成功!!
(↑最初リセット繋げてなくて焦った)
お次はftdi、ねむいさんはJTAGKey2を作っているのでそれを使用しました。
TPIの結線はこちらのJTAGKey2紹介記事のリンク先回路図、
SWD接続の部分を参照の事。結線は以下の通り読み替えてください。
TPICLK = SWCLK
TPIDATA = SWDIO
RESET = TMS
リセットはRESETじゃなくてTMSなんですよねAVRだと。
そしてJTAGKey2でも危なげなく書き込み成功。
GUIツールはこれを使わせてもらいました。
なお、Avrdudeにもパッチ当てないとATTINY104で読み書きできないのでご注意を。
ねむいさんのavrdudeのバイナリはもちろん対応済です☆
●お次はATTINY202だ！
ATTINY202はAVR-0と呼ばれる新しい世代のAVRマイコンです。
AVR-0/1シリーズではプログラムメモリの規模は8ビットマイコンの力を最大限に
引き出せる64KByte以下に収まりATXMEGAと同じアーキテクチャとなりました。
そして旧世代AVRの弱点だったプログラムメモリのアクセスの煩雑さはデータ領域の
アドレスに割り当てることによって完全に克服をしました！！！！！
詳しい内容は先達の方々のブログ記事に習いました。ありがとうございます。
・なんでも独り言様
・GHz2000様
avr-gccはATTINY202に当然対応しています。なぜかATTINY104はぶっち
されていますが！！そしてAVR-0シリーズはXMEGAと同じ感覚で組めるので
ATXMEGA128A1のプロジェクトを転用して作ってみました。
また、ATMEL STARTなるATMELの忘れ形見のようなサイトのツールで
周辺やクロックの初期化コードを生成することができます。
クロックを20MHzに上げてGPIOをOn/OFFにするプロジェクトをササっと作って
いよいよ書き込みを行います。新世代のAVRはuPDIというXMEGAのPDIを進化
させた1wireのデバッグ・書き込みインターフェースで書き込みを行うわけですが、
今回は最初に紹介したATTINY104XplainedのmEDBGを使います☆
Xplainedの基板の裏にATTINY202はっつけてみました。
XplainedのmEDBG(ATMEGA32U4)はPE6がuPDIの信号線となっています。
このPE6をATTINY202のRESET(uPDI)に接続します。
別のAVRでも使えるようにXplainedのNCの部分をuPDI信号とします。
そして…
…
まぁ一筋縄でいくわけがなく、ねむいさんが買ったATTINY104-Xplainedはtpi専用の
ファームとなっており、uPDIを使うためにはいったんATMEL STUDIOをインス
トールしてtpiのファームをuPDIのファームに変える必要があります。
具体的にはmedbgupdi.hex&binをmedbgtpi.hex&binにリネームし上書きします。
その状態でatfwというツールでアップデートします。
atfw -a medbg_fw.zip -t medbg -s (ここにXplainedのシリアルナンバを記述する)
ATMEL STUDIOからは見えた！勝った！
そしてAvrdudeでもちゃんと書…
…書けねぇ！orzなんか無限ループしてるorz
これもAvrdudeのバージョンアップでエンバグしてしまったらしく、変更箇所をもとに
戻したら書き込みができるようになりました。めでたしめでたし♥
そんなわけでまだ私が若くぴちぴちだった頃、はぢめてAVRを触れた頃を思い
出しながらAVR-0シリーズも弄っていこうと思います！まだわかくてぴちぴちですが。
ああ最後になりますが宣伝ですがATTINY104とXplained-updiにも対応した
AVRDUDEのバイナリはこちらになります！どしどし使ってください☆
いろいろ試す24
今年の暑は夏いですね････
頭が沸騰して凝固しないように少しでも文章を残す訓練をしないと･･･
●LPC11U14の悲劇
マジかよ･･･ユーザーマニュアルにはROMディバイダあるって明記してあるのに･･･
というわけで実機で調べてみました。ねむいさんの持っていたLPC11U14Expressoは
最々初期のLPC11U14が乗っています。
0x1FFF1FF8にはROMドライバのアドレスが格納されています。実アドレスは
0x1FFF1E38となっています。
LPC11UxxのROMディバイダへのポインタが格納されているアドレスはその先頭
から16バイト先にあります。つまり0x1FFF1E48に有効なアドレスが格納されて
いない場合ROMディバイダは使用不可能となります！
ア"ア"ア"ア"ア"ア"ア"ーーーーーーーッ！！！！
･･･
NxPのLPCマイコンはこう言う罠がたくさん張り巡らされていますのでユーザー
マニュアルとか鵜呑みにしないで海外のフォーラムも積極的に巡って情報を
収集してください。
そいえば2年位前ねむいさんが指摘したLPC1500のIAPのアドレスが間違ってる件も
2016年現在まだ治ってない･･･NxP(xは伏字)さんにメッセ送ったのに･･･。
●STM32Primer2を使ったGNSSロガーのリポ電池を変更
ねむいさんはトレランのトラックログ取り用にSTM32Primer2にハード的改造を施し、
それをGNSSロガーとして使用しております。電池もSparkfun製の1000mAhの
リポ電池に乗せ買え12h以上稼動できるようにしていました。
そして2010年から約6年間もの間戦い続けてきたそのリポ電池もかなりへたってきたので
交換する運びとなったわけです。
･･･がしかし！！！なんと昨今の規制強化のせいか850mAh以上の大容量のリポ電池が
軒並み販売終了となっていて購入する事が出来なくなっておりました！！！
探しに探しまくってこちらの通販会社さんから1000mAhのリポ電池を購入する事に
しました。最悪中華直販から輸入も考えたのですがチャイナボカンされたら困るので
国内から購入できる店があって助かりました♥
で、来たのはこちら。
6年前に購入したSparkFun製のものより薄く少し長くなっています。もちろん保護
回路付コネクタ付です。
元からついているコネクタは不要なのでJSTのRCYコネクタに付け直しました。
これで電池の脱着が自由に出来ます。･･･以前はテストのために直付けしたので
6年間そのままにしてましたが今回の電池交換でようやくです。
ぁーちなみにハーネスの力がかかる部分をポリイミドテープでガチガチに固定して
ますがこいつ意外と剥がれません！wifiモジュールをポリイミドでガチガチに固定してた
EnchantMOONのこと｢こんなん振動ですぐ取れるやん｣とさんざ馬鹿にしてましたが
前言撤回ですすみません！！でもよい子は真似しちゃだめだよ！
もちろん交換後も無事正常起動しました。
2016年真夏の炎天下の近畿自然歩道でバリバリ活躍しております！
たぶんねむいさんが世界でSTM32Primer2をいちばん長く使い続けてる女だと
思います･･･！もちろんあと30年は電池交換し続けて使い倒しますよぅ！
●FatFsに大量のぱっち
今年の四月にExFatに対応したChaN氏のFatFsですが、ねむいさん含めた有志からの
使用報告を受けパッチがパチパチ当たってます。現在はpatch7まで行っていますが
ねむいさんもそれに即追従してアップデートしております。
私が特に力を入れているSTM32F7をはじめSTM32F4系、STM32F1系も順次最新の
ものにアップデートしております。皆様どしどしご利用ください★
●ウィルキンソンドライコーラ
･･･
甘味抜いたタブクリアだこれ
●おそロシアふたたび
Latticeの提供しているプログラミングツールはFT2232H系のデバイスに対応して
いてJTAGKey2CompatibleでもEEPROMを書きかえるだけでLatticeのプログラマに
化けるナイスな対応をしてくれましたが、AlteraとXilinxのツールはかたくなに
FT2232系のデバイスには対応しておりませんでした。
しかしながらロシアから恐ろしい刺客がやって来たのです･･･！もちろんLatticeと
違ってかなりダーティな裏技なので詳しいやり方は伏せさせていただきます･･･。
こちらのロシア系BBSのリンク先にあるとあるファイルにAlteraのプログラミング
ツールにFTDI系デバイスを対応させるdllがあり、それに差し替えるだけでQuartus
からAlteraのCPLD/FPGAのプログラミングツールとして使えちゃいます！！！
↑実際に使ってるところ。書き込み速度はもちろん超★爆★速！
もうこれでUSBBlasterもどき作らなくてもいいんじゃ♥
そして問題のXilinx....
ねむいさんは過去に何度もXに挑戦し敗れてきましたがおそロシアのおかげでついに、
ついに攻略せしめました！！！！
注：ただし以下の条件を全て満たす必要があります。
１．FT2232Hのみ有効。FT232HやFT2232Dは不可！
２．FT2232Hにぶら下がるEEPROMは93LC56もしくは93LC66のみ有効。
93LC46はユーザー領域が足らず不可！
３．JTAGKey2 Compatible Rev.5を使用する場合、メインモジュールの
DLP-USB1232Hに搭載されたモジュールが93LC56or93LC66である事。
これは何が来るか分からないのでばくちですね･･･しかもQFNパッケなの
で引っぺがすのは普通の人にはちょっと無理でしょう。
かわりにFT2232H Minimoduleがオススメです。これ93LC56乗ってますし。
↑コツですがMProgを使ってEEPROMのデータを書きこむときにシリアルナンバを
"有効"にしておきます。この後FTDI_User_Area_Writer.exeを起動しMprog/FTProg
からは書き込めないユーザ領域にデータを書きこみます。
やったぜ。Digile○ntのJTAG-HS2として認識されました♥ちなみにISE14.7は
プラグインの調達の必要もなくIMPACTから普通に使えます。
実際にSPARTAN3をつなげてJTAGチェインを見てみます。
やったぜ！
もちろんふつうにコンフィグレーションできます♥
2010年からずっと奮闘してきた内容ですがようやくつっかえていた小骨が取れた
感じです♥EEPROMを書き換える少しの手間はありますがこれでねむいさん謹製の
JTAGKey2Compatibleが更に強力なフラッシュ書き込み/デバッグツールとして
活躍していけると思います！！
JTAGKey2互換回路をもっと使ってみる3 -決着をつけてやる！-
とりあえず回路図見たい奴は此処や！
●モロ!
2010年に始まり2013年に一応の決着を見たはずのJTAGKey2互換回路製作ですが･･･
ねむいさんは未だモロにこだわっていた。尤もここでいうモロは未加工の紳士画像を
虹裏に張り付けせしめる野蛮な行為ではなく、FT2232HのLVTTLの出力を電圧レベル
トランスレーター74LVCE1G125の5V動作時のCMOS入力に直接モロに入力せしめる
乱暴な行為を指します。
JTAGKey2互換回路において、モロで何が悪いかというとターゲットの電圧が5V系で
動作してるケースです。このとき74LVCE1G125のVIHは3.5V以上となり、FT2232Hの
LVTTLの3.3Vの出力では規格を満たすことができません。
逆に74AHCT541等の高速なバッファを挟んで正規に5VCMOSレベルまで上げてみまし
たが今度はAHCTバッファの大きな伝搬遅延が影響してFT2232Hの特徴である30MHz
動作が出来なくなってしまいました。
そんなわけで私は5V系で電圧・動作温度にマージンをかなり取ってモロった時の動作に
問題が無いことを確認し、規格は満たしてないけど私の回路図と指定した部品使えば
5V系でも実力値で問題なく使えます！…とお茶を濁していました。
しかし心の奥底でルールに反した事をしているとわだかまりを残したまま、TTLレベル
入力でなおかつ1.4〜5.5Vの電圧範囲で動き、それでいて伝播遅延も少ない夢のような
デバイスの到来を期待しておりました…。
●ｱﾁｬﾓ･･･
時は流れ、半導体製造プロセスも進化したおかげか5V動作時にTTLレベルの入力電圧
範囲を持ち、それでいて速度もそこそこ早く動作電圧範囲もそこそこ広いまさに待ち望
んでいたバッファICがリリースされておりました！TIから2014年秋口にリリースされた
LV系レベルシフタSN74LV4T125です！
以前からワンゲートロジックのSN74LV1T125は既に出ていたましたがSN74LV4T125は
4回路ぶんコミコミでなおかつ出力電流と伝搬遅延特性が改善されています。
電圧範囲は1.60~5.5Vとちょっと電圧下限の保証が低いけどこれなら勝てる！！
しかし…
遅延で1ビットずつずれてやがる…orz
ちなみに正常に認識した時はこのような感じになるはずでした。
なんか包帯ぐるぐる巻きの猪狩さんに気を取られているうちに佐山聡似の不気味な飴玉
レスラーに不意打ちを受けてさらにチョビ髭ノッポなキックボクサー崩れのレスラー(？)
に追い打ち喰らって｢あちゃ〜〜もろ････｣とか言われたような気分です。
やはりTTL入力を実現するため追加されているはずの内部ゲートの遅延がかなり
足を引っ張り結局74AHCT541を経由させたのと同じになっちゃいました。
そんなわけで安きに逃げるのは止めて既存のFT2232Hを使用している+5V動作を
保障しているJTAGアダプタたちは実際にどのようにして電圧レベルの変換を行い、
かつ速度も保証しているのかじっくり調査をしてみることにしました…。
●あくまでもモロにこだわる
夜逃げしたAmontecの過去の資料を穴の開くほど調べてみるとオリジナルJTAGKey2
のサポート"電圧"は確かに1.4V〜5.5Vでした。
この"電圧"と言うのはターゲット電圧(Vtgt)そのものを指し、JTAGインターフェース
のI/Oの電圧レベルではありません。AmontecJTAGKey2の紹介文をよく読んでみると、
"5V"ではなくわざわざ"5VTTL"と明記されています。5VTTLの出力は5VCMOSの
入力を満たすことができませんのでオリジナルのJTAGKey2はVtgtが5Vであっても5V
フルスイングのCMOSレベルの出力を出せていなかった可能性があります。
ほんとにそうなのかは販売元のAmontec及びAmontecの中の人にI/Oの電圧特性に
ついて詳細を聞けばよいのですが残念ながら夜逃げして早数年経った今はそれはかない
ません。しかもいくつかMLに残された中の人の軌跡を手繰ってみると中の人はサポート
下限は1.4Vのはずなのに1.2Vとのたまっていたり5VCMOSサポート！とおもいくそ
のたまっていたり議論中に突然Amontecの製品の宣伝をしだしたり挙句の果てに"問題は
モニタとイスの間にある!(=お前もう出てけ!)"と言われたり夜逃げしてからは"あいつ
もう死んだんじゃねーの？"とか言われたりﾎﾞﾛｸｿです。最早あまりのクソコテっぷりに
Switzer版ぴるすにしか見えないんですけぉ…
ねむいさんも彼を墓から引きずり出して殴る蹴るの残虐行為はしたくはないのですが、
オリジナルのJTAGKey2の電圧/速度スペックについてはほんとに額面通りであるのか？
懐疑的にならざるを得ませんでした。
とにもかくにもI/O電圧のレベルの上限は5VCMOSではなく、5VTTLレベルであること
は明確となりましたので一歩前進です。5VTTLレベルの出力規格2.4V以上をみたし、
なおかつFT2232Hの出力(3.3V-LVTTL)と74LVCE1G125たちのVIH(0.75VDD)を満たす
ためにはVtgtから何らかの形で電圧を落とし74LVCE1G125に掛かる電圧(Vrefとします)
の上限値を4.0V付近にクランプしてやれば解決です。
また乱暴なことを…と言いたい方もいらっしゃいますかと思いますが実はこの技、5V系
なVtgtで受けつつTTLレベルの電圧をやり取りするために実際に商業向けの商品にも
使用されているれっきとしたものです。それが使われている例をご紹介します。
↑xilinx platformcable データシートより引用
xilinxのプラットフォームケーブルUSBI/IIはデータシートに入出力バッファについて
の極めて有用な解説が記載されています(ここまで細かい資料って昔あったっけ????)
↑xilinx platformcable データシートより引用
プラットフォームケーブルはJTAGの出力にはUHSBufferなるNC7SZ125が使用され、TDO等の
入力には3.3V動作の超高速コンパレータで約1V前後のスレッショルドで取り込まれています。
(※プラットフォームケーブルIIは単なるロジックで受けているようです)
↑xilinx platformcableII データシートより引用
さらにVrefを生成するための回路は至って原始的で3.9Vのツェナーダイオードと抵抗で
Vtgtを強制的に3.9V付近にクランプさせUHSBuffer等に供給するVref上限を3.9Vまで
としていました！もちろん5Vをぶち込むとそこで80mA以上消費され、ダイオードと
抵抗にかなりの発熱を伴うのは容易に分かりますがなんて男らしい実装だ…！
さらにUHSBufferたるNC7SZ125は2000年代初頭にすでに存在している高速ロジックIC
なのですが、こいつの推奨動作電圧範囲の下限は1.65Vとなります。つまりプラット
フォームケーブルが保証しているはずの1.5VLVTTL/CMOSはこのロジックICの推奨範囲
から逸脱して使用されているわけで勿論設計された当初は74LVCEシリーズなんて存在
しなかったので結構ルールから外れた(でも最大定格範囲内の動作を守っている)結構
苦しい使い方されていたのが判明しました。
オリジナルJTAGKey2でも中の人が言っていた"UHSBuffer"とやらのスペックを見ると
当時の状況からはこのNC7SZ125以外に選択肢は考えられないので"最大定格範囲を
超えない"ようにしつつ推奨動作定格を破って動かしていた可能性が極めて高いと推定
しました。おそらくVtgtも何らかの形で4.0V付近にクランプしてVrefを作っていた
はずです。さすがにツェナーダイオード+抵抗の超乱暴実装ではないはずですが…。
まさか…。
また、CMOSの特性上VDDが低下すると伝搬遅延時間も大幅に増加していきます。
↑xilinx platformcableII データシートより引用
プラットフォームケーブルのデータシートではそれについての注意事項がありますが、
オリジナルJTAGKey2にはそんな記述すらないのですがTCK=30MHzの最大スピードで
動作せしめられるようなものは3.3V系のごく限られたターゲットのみでそれ以下の
電圧や速く動くデバイスがそもそも存在しない5V系では結局は良くても最大10MHz
くらいしか出せなかったのではないかと推測します。
●私はもうﾃｨｷﾝじゃない
そんなわけでだいぶ実態が分かってきました。ねむいさんが取れる選択肢は究極
の二択になります。
一つ、冒頭のSN74LV4T125を使用して30MHz動作と1.65V以下の保証を捨てる。
->1.5VCMOS/LVTTLを使用する場面や30MHz動作できるターゲットがほとんどないので
そいつらをあきらめてSN74LV4T125で組むと自作のハードルがかなり下がります。
5VCMOSでも規格を満たします。初めてドングルを作る人向けです。
一つ、オリジナルのJTAGKey2のロジックレベル保証を忠実に守る。
->1.5VLVCMOS/LVTTLから5VTTLに至るまでの電圧範囲をサポートせしめる！！！
2015年現在存在する新しい超高速ロジックICなら低電圧領域でも速度がある程度
保証されます。その代り回路は複雑になり、使い方にも注意が必要です。
ねむいさんはもちろんオリジナルJTAGKey2の電圧範囲を忠実に守ります！！！
そんなわけでJTAGKey2Compatibleのキモにあたる部分の解説をおさらいを
兼ねて改めてしていきましょう。
TCK,TDI,TMS,SRST,TRSTはDIODES-Zetex社の74LVCE1G125です。
1.4Vから動作するので1.5V系も正式にサポートです★
TDO,RTCK,SRST_inはNexperia(旧NxP)社の74LVC2T45です。こいつは1.2Vから動作する
すごい奴です。この図だけ見るとパスコン乗せてないように見えますが
PDFにはちゃんと乗せてますのでご安心ください。
オプション扱いだった74AHCT541は廃して今回新たに4V出力のレギュレータを追加し
ました。これで5V系のシステム相手でも5VTTLの電圧レベルをサポートできます！
4V以下ではLDOの特性上内部消費電流が増加しますがこの東芝のTCR2EF40は内部
消費はmA以下のオーダーなので発熱も全くなく電圧クランプとしての役割を十分に
果たしてくれます。さらに最低動作電圧は約1V付近と一般的なLDO比べて十分低い
ので1.5V系の時の動作でも電圧が暴れず安定して使用できます♥
勿論全てのLDOがこのような使い方ができるとは限りません！しっかりとデータシート
の特性グラフとにらめっこして目的に最適なものを選んでいきましょう！
●ありがとうV戦士モロ
2年前作ったJTAGKey2CompatibleRev.4にレギュレータを追加しただけですので
見た目はまったく変わってません。74AHCT541乗っかったままですが
どこにも繋がっておらずもはやただのオブジェと化しています。
レギュレータは赤丸でかこった箇所につけました。現在は1608サイズで10uFで
しかも温度特性もそこそこのよいMLCCが売られているので早速使っています★
3.3Vの挙動については回路構成はRev.4以前とまったく同じですので5V系と1.5V系
のきわきわの動作を見ていきます。
前回と同じ条件でATMEGA1284Pをターゲットデバイスに選び検証します。今回は電圧
レベルの問題で引っかかるのはJTAGKey2内部ではなくJTAGKey2の出力バッファと
AVR間です。AVRを選んだ理由は前回と同じものを使ったから条件があわせやすいのと
VIHが通常のCMOS(0.7~0.75VDD)よりも大きい0.8VDDを要求しているからです。
VDD=5.65Vの厳しい条件で温度を振って書き込みや消去が正常にできたらねむいさんの
勝利です！！！
(注:1.5Vの時はAVRの動作補償範囲からはずれ、JTAGのTCK周波数許容値が
下がってしまうので今回は一律10MHzではなく4500kHzで検証しています。)
勝った･･･！
手抜きではないのですがATMEGA1284Pの動作保証下限1.8Vを割って1.5Vでも
問題なく動作可能です♥これで1.5VLVCMOS~5VTTLレベルの電圧レベルでは
完全に動作することが確認できてさらに5VCMOSレベルも問題なく動作する実力が
あるのもわかりました♥
ちなみにATMEGA1284Pの内部CR発振器は結構根性があって一度発振できたら1.35V
くらいまで下げても余裕で動作するのがわかりました。電池一本で動きますよ。
さすがにJTAGのTCKの周波数は大幅に下がって1MHzくらいじゃないと駄目ですが。
動作可能なI/O電圧レベルを表にするとこんな感じです。最もパフォーマンスが
出るのは3.3VLVCMOS/LVTTLの時です。5VCMOSでは上述のとおり規格を一部
満たしていませんが動作する実力が確認されたので×ではなく△印つけています。
尤も相手がCMOSならば入力電流もMAX10uA位しかないでしょうから3.8V以上は
余裕で保てるので+5VCMOSでも問題ないですね。
そんなわけで長きに渡る戦いに終止符を打たせていただきます。ですがこれから先、
技術革新が進みTTL入力コンパチでなおかつ伝播遅延が3.3Vでも3nSec以下のすごい
バッファICが出たらまたJTAGKey2Compatibleの改良に取り組みたいと思います！
JTAGKey2Compatible Revision5
↑OpenOCDでSWDしたいときの追加回路もついでに追加しています。
OpenOCD小ネタ12 -HLA向けのcfgファイルの統合-
お盆前に行われたOpenOCDのHLA系コンフィグファイル大変更への対応を
幾つかのターゲット向けの試用実例と交えて解説します。
とその前に！
最近再び似た質問を多数いただくようになったので･･･
●STLinkがOpenOCDで動きません。
NxP系マイコンのCheckSumValidationと同じく何度も言ってますが
何度でもおさらいです。質問が続く限り何度でもなんどでも な・ん・ど・で・も
説明します！
注:STLink/V1はもう持ってないのでサポート外です。STLink/V2とSTLink/V2-1系向けです。
20140902追：
2014年9月現在、Windows8.x系環境下でSTLink/V2-1がOpenOCDから
利用できません。これはlibusbがWin8.x環境下でUSBコンポジットデバイスを
正しく扱えてないことに起因するものだそうです。
libusbに修正かかるまで辛抱強く待つかXP/Win7に戻すのです！！
STLink/V2の方はコンポジットじゃないのでWin8でも問題なく使用可能です。
20141114追：
Windows8.x環境下でのOpenOCDサポート開始です
１．基本的な結線は本当に正しいか
STLink/V2系はSRST,Vtgt(ターゲットのVCC),SWCLK,SWDIO,GNDが必須です。
SWCLKとSWDIOを"てれこ"にしてたりGND繋げてなかったとか論外ですが
(そういったケースもありました…私に直接返信はなく質問された方の
twitter上の発言でそれ知ったのですが…＃)まず第一にGND,SWCLK,SWDIOの
結線がターゲットのMCUと正しくなされているかを回路図を良く見て
テスターで導通をしっかり確認してください。
２．SRSTは繋がっているか
現在ではNucleo/Discovery等のメーカ製評価ボード向けの特製cfgはすべてSRSTを
使用するように設定されています。したがって私の特製cfgもそれに準じております。
stlink-v2.cfgを直接呼び出す使い方を中途半端に真似ると引っかかるので
ご注意ください。Nucleo/Discovery等のメーカ製評価ボードから自作のボードに
環境を変えた際にSRSTの接続を忘れ上手く動かないといった連絡を特に戴いています。
回路図を良く見てテスターで導(ry
３．Vtgtは繋がっているか
また、Vtgtの接続もほぼ必須です。これも"２．"と同様ですが特にNucleo/
Discovery等のメーカ製評価ボードからデバッグ線を引き出して自前のボードと
繋げる際に発生します。
ネット上では情報が倒錯しOpenOCDではVtgt必要ないと断言している記述も
あるのでご注意ください。
ねむいさんは一貫してVtgt繋げろです。
STLink/V2は接続の際にまずSWCLK,SWDIOの電圧を読みに行ってVtgtの電圧
よりも相対的に高い電圧とみなすとその後の一切を弾くのでコケて絶対先に
進めません。これはファームウエアレベルでこういう動作をしますので
特定のソフトに依存はしません。
メーカ製ボード上ではVDDがSBDで切られてVf分のドロップで3.0V前後と
若干低くなった状態で動作しているので気づきません。しかしながら自作の
ボードではほとんどが3.3Vで使用されるともいます。このときSWCLK/SWDIOの
電圧はデバッガ側より必ず大きくなるのでコケます。
また、以前も触れましたが一部のボードではコスト削減のためVtgtにつながる
抵抗が実装されていないものもあります。
ケアレスミスで時間を浪費しないように回路図を良く見(ｒｙ
･･･
STLiink系ばっかりに力入れるわけにはいかないので本題に入ります。
●分かれていたコンフィグファイルが今一つに！
これです。目的はSTLink/V2やTI-ICDI等のHLA(HighLevelAdapter)も
従来のFTDI/JLink等と同じコンフィグファイルを使用できるようにする修正です。
もともとHLAは各メーカが提供する独自のデバッグ用APIをOpenOCDでも利用できる
ようにと組み込まれた機構です。したがってターゲットMCUへのローレベルな
アクセスができない、クロック周波数の設定等のアダプタ側でも細かい制御も
できないといった制約があります。
ですのでその挙動の違いから使用可能なコマンドも分けられており、従来は
各MCU向けのOpenOCDコンフィグファイルも通常のものとHLA系に分けなければ
なりませんでした。
しかし今回の修正でHLA系で使うとエラーになっていたadi_v5系のローレベルの
コマンドがエラーとならずオーバーライド(スルーとも言う)できるようになり、
hla専用cfgは晴れてお役御免となったわけです。
さて、変更されて箇所は分かりましたがそれを実際にどう反映させればよいかと
いうと･･･OpenOCDを呼び出す際の引数として、もしくはcfgファイル内に
"transport select"コマンドを追加で付与します。
以前はHLA系アダプタを使用する場合はトランスポートが決め打ちだったので
STLink/V2やTI-ICDIのcfgファイルに直接記述されていた物が外に追いやられた
形になってます。EFM32TG822F32の例を取って新旧のOpenOCD引数比較をします。
下記の記述はこちらのデバッグ手順に準じますので事前に把握をお願いします。
旧：
OCD_ARG = -s $(OCDIR)/tcl ¥
-f interface/stlink-v2.cfg ¥
-f target/efm32tg822f32_hla_flash.cfg
新：
OCD_ARG = -s $(OCDIR)/tcl ¥
-f interface/stlink-v2.cfg ¥
-c "transport select hla_swd" ¥
-f target/efm32tg822f32_swd_flash.cfg
こんだけです。TI-ICDIの場合はJTAG接続専用なので"hla_jtag"になります。
STLink/V2,STLink/V2-1はSWD専用なので"hla_swd"です。
メーカ製出来合いのボードの場合、OpenOCDのボート向けcfgで対策されたのが
ほとんどなのでこちらで修正する必要はないです。
Nucleo-R334板(STLink/V2-1付)の例を示します。
旧：
OCD_ARG = -s $(OCDIR)/tcl ¥
-f target/nucleo-f3_flash.cfg
新(旧と全く同じ)：
OCD_ARG = -s $(OCDIR)/tcl ¥
-f target/nucleo-f3_flash.cfg
因みにcmsis-dapの場合も現状SWD専用なのでswdが自動で選択されるので特に
変更は不要です。トラ技ライタ(LPC11U35)にCMSIS-DAPで繋げる例を示します。
旧：
OCD_ARG = -s $(OCDIR)/tcl ¥
-f interface/cmsis-dap.cfg ¥
-f target/lpc11xxx_swd_flash.cfg
新(旧と全く同じ)：
OCD_ARG = -s $(OCDIR)/tcl ¥
-f interface/cmsis-dap.cfg ¥
-f target/lpc11xxx_swd_flash.cfg
さらにJTAGKey2等の汎用のJTAGの場合は何も指定しない時はデフォルトで
JTAG接続となるので余計な指定は不要です。
STM32F407ZGT6にJTAGKey2で繋げる例を示します。
旧：
OCD_ARG = -s $(OCDIR)/tcl ¥
-f interface/ftdi/jtagkey2.cfg ¥
-f target/stm32f4x_flash.cfg
新(旧と全く同じ)：
OCD_ARG = -s $(OCDIR)/tcl ¥
-f interface/ftdi/jtagkey2.cfg ¥
-f target/stm32f4x_flash.cfg
JLINKやVersaloon,FT2232系でSWDしたい場合は宣言は必須ですがこの3つに
関しては私のcfgレベルで対策済なので私が提供するバイナリとcfgを
使う限りは変更不要です。STM32F407ZGT6にVersaloonで繋げる例を示します。
旧：
OCD_ARG = -s $(OCDIR)/tcl ¥
-f interface/vsllink_swd.cfg ¥
-f target/stm32f4x_flash.cfg
新(旧と全く同じ)：
OCD_ARG = -s $(OCDIR)/tcl ¥
-f interface/vsllink_swd.cfg ¥
-f target/stm32f4x_flash.cfg
現在のOpenOCDでは以下の4つのtransportが存在していますが、hla系は
上記の要領で多少の変更を追加するだけで対応可能となっています。
transport select jtag (transportを何も指定しないときのデフォルト)
->FT2232系,JLINK系,Versaloon,その他多くのJTAGデバイス
transport select swd
->FT2232系,JLINK系,Versaloon,CMSIS-DAP
transport select hla_swd
->STLink/V2,STLink/V2-1
transport select hla_jtag
->TI-ICDI
なお、今回の統合でSWD接続においてレグレッション・テストを行って
いなかったようでSWDでエラーが発生してしまいました。私はお盆前に自作の
パッチを適用したバイナリを公開していましたが現在はこの問題に気付いた
方が別のアプローチからパッチを提出しマージされております。
LPC17xx系でDAPIDの問題が残ってますがマイナーな問題なのでじきに
修正されると思います。
現在はすべてのtransportでスムーズにOpenOCDが利用できます。
あとは微妙に残ってるJTAG依存な処理の完全切り離しとSWDのSRSTコント
ロールの最適化が達成できたらOpenOCD導入のハードルは下がると思います。
というわけでおきぱにあるOpenOCDバイナリもどしどしご利用ください！
OpenOCD小ネタ11 -EFM32 ZeroGeckoとJLinkのSWD接続正式対応-
以前ちらっとお見せしましたがEFM32のZeroGeckoシリーズの
評価ボードをだいぶ前に手に入れて、評価しております。
MCUにはおなじみトカゲのマークがあります。Cortex-M0+コアを持つ
EFM32ZG222F32が搭載されています。
ボードは低消費電力のアプリ作成を意識したものになっていて搭載されて
いる液晶もメモリ液晶と呼ばれる超低消費電力なものとなっています。
最初に書き込まれているプログラムは、メモリ液晶を利用したインベーダー
もどきなゲームを遊ぶことができます。
なおこのゲーム、一機死んだら即ゲームオーバーなかなりシビアな代物です！！！
今回の記事に合わせ、私が基本としているLED&UARTなEFM32評価ボード向けの
GCCプロジェクトも作成しております。
低消費電力モードは使わず極めてシンプルな代物です。
また、以前もふれましたがOpenOCDからもEFM32ZGシリーズも書き込みが
できるように対応しております。EFM32自身はSW-DPしか持たないので
書き込み/デバッグするためにはSWD接続可能なアダプタが必要となりますが
現在ではSTLink/V2,JTAGKey2,Versaloon,そして後で述べるJLinkがSWD接続
対応のデバッガアダプタとしてOpenOCDから使用可能になっておりますので
不自由はしないでしょう。
こちらは素組みのEFM32ZG板をSWD接続版のJTAGKey2でデバッグしてる
ところです。もうおなじみの画面ですね。
話は評価ボードに戻しますがこちらにはJLink-OBと呼ばれる他社向けの
MCU評価ボード専用のJLinkが搭載されております。LPC-Link2等でもほぼ
同じ仕組みでオンボードでJLinkをエミュレーションしていますが従来、
OpenOCDからはJTAG接続だけが可能でした。
したがってSW-DPしか存在しないEFM32ではOpenOCDで書き込みデバッグする
際はオンボのJLinkは無効にしてSTLink/V2やVersaloonのSWD版で使用
せざるを得なかったのですが、少し前にJLinkも
正式にSWD接続に対応し、単体でフル活用できるようになっております♥
オンボJLinkでOpenOCDです。JLink純正のドライバじゃないと外部に
デバッグプローブを引き出すことはできませんが私の場合はJLinkエミュが
可能なLPc-Link2を所持してるので通常はlibusb-1.0のみで十分だと思ってます。
ここでOpenOCDでEFM32シリーズを操作するためのコツですが…EFM32は
リセット直後の短い時間の間だけSWDの信号線が別の独自のデバッグ
プロトコルとして挙動するのでSRSTと組み合わせて操作することが
できません。したがって"connect under reset"は使用不可能になります。
誤って低消費電力モードにしてしまうとOpenOCDからの操作ではもう
元に戻せなくなりますので、くれぐれもご注意ください。
しかしながらEFM32板のオンボJLinkはsegger純正ドライバとEFM32が
提供するデバッグツール"energyAware Commander"から独自プロトコルの
操作が可能なため、初期状態に戻すことができるので心配はいりません。
ここまではEFM32とオンボJLinkについて述べてきました。私はJLink化が
可能なLPC-Link2を持っていますのでLPC-Link2にJLinkのファームウエアを
再び書き込みこちらも同じようにSWDで接続出来るか試してみたいと思います。
↑ターゲットはトラ技ARMライタという名のLPC11U35板です。
ライセンスの関係上NxP以外の製品で使うところはお見せできませんが
OpenOCDではほぼすべてのARMマイコンを書き込みデバッグできる攻守ともに
非常にバランスの良いデバッガアダプタとなりました。
20kBほどの同一のバイナリを同一のUSBポートから書き込んだときの
CMSIS-DAPとJlinkエミュとの速度の比較です。
*CMSIS-DAP on LPC-Link2
wrote 20480 bytes from file main.elf in 10.265428s (1.948 KiB/s)
verified 20204 bytes in 0.437491s (45.099 KiB/s)
*JLink on LPC-Link2
wrote 20480 bytes from file main.elf in 2.624950s (7.619 KiB/s)
verified 20204 bytes in 0.265620s (74.281 KiB/s)
CMSIS-DAPファームの時はOpenOCDの実装がせっかくのブロック転送機能を
フルに利用していない残念仕様のためやたらと遅いのですがJlinkエミュなら
バルク転送がびしばし使えるので超早いです♥但しSRST/TRSTの操作が
ちょっと怪しい所があります。
seggerの純正のツールではちゃんと操作できるので時間を見て両者の挙動の違いを
詰めて行きたいと思います。現状SRSTを必ず要する場面は限られていますので
JLinkエミュにしっぱなしの方がサクサク作業を進められると思います。
ねむいさんのおすすめです。
(※ただしNxP製品以外の書き込み/デバッグに使っちゃ駄目ですよ！)
20140820追:
F**K
今回は数日前のOpenOCDのコミットでHLA(HighLayerAdapter)系デバッガ
アダプタのcfgが一般の物に統合されたというかなり重要なことについても
お伝えしたかったのですが、JlinkのSWD対応の紹介で長くなりすぎましたので
次回じっくりと解説させていただきます。
OpenOCD小ネタ10 -VersaloonのSWD正式対応とKinetisドライバの小改修-
●祝!Versaloonが正式にSWD接続対応になった。
先日、JTAGkey2に代表されるFTDI系のデバイスがSWDに対応しました。
それに続いてVersaloon(OpenOCD内ではvsllinkと呼ばれています)の
コードも大幅に見直しがされてSWD周りのadi-v5の依存部分が完全に分離、
再構成されて晴れて正式にSWDに対応となりました。
それに伴い以前紹介していた導入手順と変更になる個所が幾つか
ありますので、皆さんが迷わないように変更すべき個所を以下に述べます。
1.LibUSBが0.1系から1.0系になった(超重要！)
Versaloonは従来からUSBのドライバとしてLibUSB0.1系APIを使用して
いましたが、今回のSWD対応で1.0系に切り替わっています。
Zadig等の自動インストーラで0.1系ドライバを適用してる場合は
LibUSBKかWinUSBに切り替えておきましょう。
2.Versaloon用cfgファイル
ねむいさんはVersaloonのswd対応用として特別なcfgファイルを提供して
おりました。その中でVersaloon用の固有コマンド"swd_delay"と
"swd_trn"が設定されていましたが、swd_trnは2に固定化されハードコード、
swd_delayはイニシャライズ時のadapter_khzの解釈に取り込まれそれぞれ
廃止になっております。自作のswd用のcfgを作成されている方は
swd_delayとswd_trnの定義は削除してください。
ソースコードを見た限りではJTAGKey2を使う場合と違ってSWCLKの
クロックの設定最初の定義以降は動的に変えられないように見受けられ
ましたが(ソース上では変更できる余地がある)あえてそうした理由も
含めてこれからさらに探ってみます。
私のOpenOCDのバイナリは既に正式にSWDに対応した版に切り替わって
いますがまだVersaloonを現役で使用されている酔狂な方は上記2点を
見直し各自対応願います！
●VersaloonのConnetUnderResetとkinetisドライバと
"今まで正常に書き込めてたのに急にうまく動かなくなった"問題をほぼ解決
してくれる心強いConnectUnderReset機構はSTLink/V2で絶賛活躍中です！
…と言いたいところですがSWD接続の場合、STLink/V2以外の殆どの
デバッガアダプタでマトモに機能していないことが判明しましたorz
それが判明した経緯は私がOpenOCDのgerritにkinetisドライバのちょっとした修正を
送ったことにあります。他のユーザさんから"Kシリーズでセキュリティ状態の
有効/解除上手く出来てるのか?"と問われ、SWD接続の方のVersaloonで試して
みると確かにセキュリティ状態が解除できませんでした。手でリセットボタンを
連打すると解除できたのを不審に感じ、
(Kinetis-Kシリーズはセキュリティ状態の解除に外部SRSTの操作が必須。
3月初めにkinetisのフラッシュドライバに大幅変更がかまされたとき
KL25とかのKLシリーズでしか試してない人がリファレンスマニュアルを
よく読まずKLシリーズに特化して機能を再実装してしまった…！
そのせいでK40とかの古いシリーズではうまくいかなくなるという
憂き目にっていうか前々々回のguranualityがらみでエンバグ直した時もそうだけど
お前らちゃんとリファレンスマニュアル読めやぁあああああああああああああ！！)
…ッ…はぁはぁすみません取り乱しました…ぇっとオシロスコープでSRSTの
動きを観測するとまったくConnectUnderResetしておりませんでしたorz
↑全くダメですこれ
ねむいさんてっきりハイレベルなレイヤでこの機構が入ってると思ってた
のですが････
なんとSWDの場合だけローレベルのデバッガアダプタ依存処理なのでしたorz
というわけでvsllink.cのイニシャライズの所にConnectUnderReset機構
ぶち込んであっさり終了です#
↑これですよこれ！
まさかと思ってJTAGKey2でSWD接続で試してみると同じ結果でしたorz
↑SWD接続orz
↑JTAG接続だとちゃんとConnectUnderResetしている…
手前にresetがHレベルにあるのにTCKが動いてますがこれはSWD-JTAGの
移行シーケンスなので電源投入直後なら特に問題はないです
(正直これもちょっと？？？ですが)
おきぱにあるバイナリは現状VersaloonにだけConnectUnderResetの
ぱっちを当てていますが、FTDI系は一筋縄ではいかずかなり手ごわいので
慎重に対応していきます。
OpenOCD小ネタ9 -STM32F33xシリーズとFTDI系のSWD対応-
![](https://dl.dropboxusercontent.com/scl/fi/vqs9w5odj1ce9j1jww5bb/20140701_001.jpg?rlkey=paivm14chzkcvv5f8pz4qk75g")
6月中旬に唐突に秋月さんちのラインナップに追加された詳細一切不明の
謎Nucleo基板Nucleo-F334R8にはこれまた詳細不明のSTM32F334R8T6
が搭載されておりました。
![](https://dl.dropboxusercontent.com/scl/fi/g7ucjhefxqa37mvi9tao0/20140701_002.jpg?rlkey=eim85rh60nrmb7g5glzdx93eg")
↑今回から撮影用でぢかめを接写に超強いTG-3に買い換えました♥
6月中旬の時点ではF3シリーズであるというほかには詳細が一切不明だったので
会社で試作部品発注したついでに購入してしまいました。
(注:Nucleo板は自費で購入です!)
ひとまずOpenOCDで引っ掛けると、デバイスIDが0x10016438というまだ
OpenOCDのフラッシュドライバには存在しない物だっため最初は書き込みエラーで
はじかれてしまいましたがソースコードにそのデバイスID追加して即書き込むことが
出来ました。因みにSTM32F3系はCortex-M4系ですがフラッシュ書き込みドライバは
F1系です。もう少しでF2系ドライバに実装しそうになってしまいましたよ。
実は最初に私がパッチを書いた当初はユーザマニュアルどころかデータシートすらも
無かったため、フラッシュのセクタサイズは0系からのコピペの飛ばしでした･･･。
が、その後にリリースされたReferenceManualには2048バイトと
書かれていたのでｾﾌｾﾌです。
![](https://dl.dropboxusercontent.com/scl/fi/hyg5v32dbeepxo1avmci7/20140701_003.png?rlkey=v5esrjt1vgh2p4xbbwnmdzuus")
話は前後しますが一週間以上前に提出したパッチはすでに公式にマージされています。
おきぱにあるOpenOCDのバイナリもF334R8版Nucleo対応のcfgを作っていますので
お持ちの方はすぐに試すことができます。便利な書き込みスクリプト付きで対応です☆
![](https://dl.dropboxusercontent.com/scl/fi/ngt5y8pmhkflodcgy6my7/20140701_004.jpg?rlkey=y6j8xbmd8x3bzgjreh5allaff")
というわけでせっかく買ったのでLチカだけじゃなくNucleo版のいつものに相当する
I2Cデバイスを動かすサンプルを移植しました。
長らくの間ねむいさんたった一人しかこのi2c液晶動かして無かったですがごく最近
ついに他の方も動作に成功したようです。私間違ってなかったですよね…！
注:7月1日現在、STM32のライブラリをPeriphDriverからHALDriver
(STM32CubeF3)に変更しております。
CubeFx系のライブラリ対応につきましては後日みっっっっちりと
解説させていただきましたので覚悟なさい！
お次は長らくの悲願であったFTDI系デバイスのSWD接続正式対応です！
以前から私はぶろぐ上にてレビュー段階のコミットを評価しておりました。
その時点で既にかなりの完成度に達しておりましたがその後adi_v5と
swd関連のソースも見直されて満を持しての今回のマージです♥
…と同時にVersaloonのSWDパッチは完全に使用不可になってしまいましたが
実は他の方が別の手段でSWDに対応させたパッチがレビュー中でして7/1現在
おきぱにあるバイナリはそちらの物を取り込んでおります。
Versaloonも以前と全く変わらない使用感になっていますのでこちらのマージも
時間の問題であると言えます☆
さて、ねむいさんのぶろぐではJTAGKey2(とその互換回路)を使用してSWDせしめる
方法をお伝えします。以前も述べていますが原理は簡単で抵抗一本でSWD化可能です。
![](https://dl.dropboxusercontent.com/scl/fi/anud60kdj6gusq7zz8yu7/20140701_005.png?rlkey=jkpouunfp2vo43dj4jef1k3cg")
たったこれだけの追加回路で完了です。一見強引な方法に見えますが出力同士がぶつ
かっても(私の回路図通りに作りこんでいれば)出力バッファの定格内なので全く問題
がありません。
上記の方法、JTAGKey2に代表されるハード的にSWD未対応な物ではresister-hack
という形でOpenOCDのcfgファイルでサポートされています。それを利用して
swdで接続しに行くJTAGKey2専用のcfgファイル"jtagkey2_swd.cfg"も
こちらでこさえております。
おきぱにあるプロジェクトではEFM32とSTM32F4のいつものがすでに
JTAGKey2のSWD接続にmakefileレベルで対応しております。
現在はまだ3つだけですが順次対応して行きます。
あとついでのついでですがEFM32のZEROGECKOのフラッシュ書き込みも
対応させました。こちらも機会があればEFM32のボードとともに
ご紹介させていただきます。
OpenOCD小ネタ7 -JTAGKey2でSWDできるじゃない！-
20140708追：
ついにSWDに正式対応しました！
20140708追：
ここ数日OpenOCDのgerritにVersaloonのSWDサポートの修正が盛んに
あげられていて、私もいろいろﾖｲｼｮしております。同時に汎用のSWDドライバも
見直されどんどん変化しております。
その矢先になんかすごいの来てました。FTDIデバイスのSWD対応です！
しかも結線がめっちゃ簡単でJTAGKey2(Compatible)系のバッファがついたもの
でも極めて簡単な回路の追加でSWDれます♥
本来FTDIデバイスのSWD対応については約一年前、libswdというのがコミットに
当たりかけていたのですが実装に関する思想をめぐりくだらない激論となり
スクラップ状態で放り投げられていました。今回の奴はそれとは別のアプローチ
で実装された物のようです。末端ユーザーの私たちとしましてはちゃんと
動作して恩恵が受けられるのかが大事です。
そんな訳で早速試してみました！コードレビューにはJTAGで言うTDIとTDOの
間にトライステートバッファをおいてnTRSTでOEを制御してターゲットの
SWDIOと接続すべしと書かれております。SWCLKに関してはそのまんまTCKに
つなげばOKです。さらに"トライステートバッファ噛ますのめどいんなら
220~470ohmくらいの抵抗でワイヤードORでもいけるかもね"とさえ書かれて
いました。
もちろん私はお気楽に510ohmのカーボン抵抗でワイヤードOR作戦です。
当たり前ですがTDIが直接ターゲットのSWDIOに来てショートしないように
抵抗を配置してください。
(私のJTAGKey2Compatibleの回路はそれでも素子の即死はしないように配慮してます)
今回の実験対象はSWDのみ接続可能なNuvotonのCortex-M0コアの
Nano130SE3です。このマイコンも以前からちらっとお見せしていますが
NuvotonネタはFM3の修正がコミットされたら一気に攻めるので今は
まだ脇役なのです。もう少しお待ちください。
JTAGkey2はVref必須故にVersaloonの+3.3Vを拝借してターゲットに
供給しております。使用するOpenOCDは現在の最新のコミットベースの
Versaloon-SWD対応版と、同じく最新のコミットベースで
上記のコードレビューからCheckoutしてきたFTDI-SWD対応版＋αの
OpenOCDバイナリをそれぞれビルドし、VersaloonとJTAGKey2で
同一のelfファイルの書き込みとベリファイ速度を比較します。
↓んでこんなん出ました。
*JTAGKey2-SWD
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/jtagkey2.cfg -c "transport select swd" -f target/nano130se_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.8.0-dev-00358-g5b3885f-dirty (2014-02-19-17:22)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : Init SWD
swd
none separate
Info : add flash_bank nuc1x nano130se3.flash
adapter speed: 1000 kHz
cortex_m reset_config sysresetreq
Info : JTAG->SWD
Info : clock speed 1000 kHz
Info : SWD IDCODE 0x0bb11477
Info : nano130se3.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x000006ec msp: 0x20004000
auto erase enabled
Info : DeviceID : 0x00113034
Info : Detect NANO130SE3AN!
Info : Nuvoton NUC: Sector Erase ... (0 to 39)
Info : Nuvoton NUC: FLASH Write ...
wrote 20480 bytes from file main.elf in 2.452780s (8.154 KiB/s)
verified 20240 bytes in 0.203096s (97.322 KiB/s)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x000006ec msp: 0x20004000
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:04
*Versaloon-SWD
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/vsllink_swd.cfg -f target/nano130se_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.8.0-dev-00350-g6c74255-dirty (2014-02-19-11:18)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : OpenOCD runs in SWD mode
none separate
Info : add flash_bank nuc1x nano130se3.flash
adapter speed: 1000 kHz
cortex_m reset_config sysresetreq
Info : Versaloon(0x15)by Simon(compiled on Sep 5 2013)
Info : USB_TO_XXX abilities: 0x0000176E:0x010001EF:0xC0000007
Info : clock speed 1000 kHz
Info : SW-DP IDCODE: 0x0bb11477
Info : nano130se3.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x000006ec msp: 0x20004000
auto erase enabled
Info : DeviceID : 0x00113034
Info : Detect NANO130SE3AN!
Info : Nuvoton NUC: Sector Erase ... (0 to 39)
Info : Nuvoton NUC: FLASH Write ...
wrote 20480 bytes from file main.elf in 1.905981s (10.493 KiB/s)
verified 20240 bytes in 0.203097s (97.321 KiB/s)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x000006ec msp: 0x20004000
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:02
ログも微妙に違いますが書き込みベリファイの速度に注目すると…
JTAGKey2-SWDが
wrote 20480 bytes from file main.elf in 2.452780s (8.154 KiB/s)
verified 20240 bytes in 0.203096s (97.322 KiB/s)
Versaloon-SWDは
wrote 20480 bytes from file main.elf in 1.905981s (10.493 KiB/s)
verified 20240 bytes in 0.203097s (97.321 KiB/s)
となり、JTAGKey2-SWDの方は書き込みでは2割ほどパフォーマンスが
落ちますがまだコードが練られてない段階ながらも十分実用レベルで
使用可能なことが分かりました♥
ついでにトライステートバッファによる制御がなくても抵抗一本でお手軽に
既存のFT2232系のJTAGデバッガがSWDにも対応できるのでなんというか
CMSIS-DAPとは一体何だったのか感すらあります。
というわけでまだまだコードの手直しが必要な段階ですがFTDIデバイスの
SWD対応はシンプルかつ強力なポテンシャルを秘めていると言えるでしょう！
LPC800シリーズを使ってみる4 -ついでにトラ技ライタも使う-
私もご多忙にもれずトラ技ライタなる基板(雑誌は付録)を買ってきましたよ。
今回は基板単体ではすぐに使うことはできずUSB-miniBコネクタと1.27mm
ピッチ*2のヘッダ、そして幅が狭いタクトSWが必要です。
上記のものはマルツで買わなくても秋月で以前購入したものでほぼ賄えるので、
秋月フリークな貴方は全く問題はないでしょう。私も以前JTAGKey2Compatibleを
作成した時にチョイスした面実装タクトSWを利用しております。
ちょっとコツが要りますが、私のぶろぐ見てる方ならこの程度の
作業は楽勝だと思います。
とりあえず最低限のパーツを付けるとこんな感じになります。あーそうそう、
…2/9はいないさんの誕生日でしたね♥うっかり写っちゃいましたね♥
ぱんつは駄目だったけどぶらなら繊細なぴいぶろ君は怒らないみたいなので学校や職場でどんどん見てほし
さて、このトラ技ARMライタはLPC11U35が載っていて、CMSIS-DAPのファームを
仕込むことによって文字通りライタにせしめることができます。正直これに
関してはLPC812-MAXのMBED版CMSIS-DAPと全く同じなので特記すべきことは
ありません。もちろんふつーにOpenOCDから使用可能です!
ターゲットは300milのDIPと化したLPC811さんです！秋月さんの8PinDIP変換を2連結
で16Pinとして使うのがミソです★
このDIP化ネタ、もはや10番煎じくらいの手あかが付きまくったネタなのですが
やらずに居られません。
前回LPC810で遊んだ時のように空中配線のやっけつです。ところで…
…
CN5にJST-EHの8Pinコネクタつける際に気付きましたが…
LPC-Link2からのコピペですかトラ偽らしい(ﾆｰｻﾝ顔で)…まぁいや
新声社亡き後誤植を継ぐ者はCQ出版だけですから(諦観
20140313追:
あのさぁ…
この程度は誤植のうちに入らぬということかー！！！
20140220追：
ねむいさんの探し方が悪いだけだと思いますがトラ技ARMライタの回路図が誤植
満載の紙媒体以外で全く見当たりません(怒)今どきPDFで回路図提供しないとか
どういう根性しているのでしょうか(ﾋﾞｷﾋﾞｷホントふざけてますね(ﾋﾞｷﾋﾞｷ
やはりカンガルー先輩をオーストラリアから召還し〆て頂かないと駄目ですね
マジで(ﾋﾞｷﾋﾞｷ
思えば過去の記事ではカンガルー先輩に対して"やる気がわかないと仕事をしない
気分屋"とかいう駄目な日本企業にありがちな駄目な経営者目線でレッテルを
貼っています。頑張って仕事して(いる仕草を見せ)ない奴は駄目な奴だ！！！
苦労して仕事をしない奴は生意気だ！！！と言わんばかりの陰湿な主張が
にじみ出ているようでそれとはまったく真逆のマトモな精神を持つカンガルー
先輩はCQ出版と袂を分けて正解だったのであろう
…とひしひしと感じます。
ちなみに現在のカンガルー先輩は本国に帰国後、己の野性に目覚めたのかビルドアップ
した筋肉超満載状態となっております。なぜこんなにムキムキになる必要が
あるのかというと巨大動物図鑑さんからの解説から考察すると上半身(上腕)で相手の
攻撃を制し破壊力がある蹴りで攻撃するという独特な戦闘法を取っている事に
あることが考えられます。ここまで述べた時点でもう気づいた方もいるかも
しれませんが…
そう、これは二代目霊界探偵の仙水忍さんが体得した霊光裂蹴拳です！
あらゆる武術を体得した上でないと使用が許されないあの！
こうなるとカンガルー先輩は暗黒天使(ダークエンジェル)である可能性まで
出てきました。魔界の穴があくまでもう時間はありません！急げ幽助！
MBED版CMSIS-DAPもなひたふさんビルドのCMSIS-DAPも特に書き込みの性能差
はなく、同様に使用可能ですが何度も言っておりますがMBED版の方はVCP
ドライバのインストールを行わないとCMSIS-DAPが認識されないのでご注意ください。
ちなみにフラッシュの書き込みは全般的に遅いです。これはOpenOCDから
CMSIS-DAPを使った時の致命的な弱点で、OpenOCD側のプログラムの構造上
PC->ターゲットのデータ送信時にブロック転送コマンドを使わずすべてちまちまと
転送を行っているからです。Versaloonもおなじような感じなのですがUSBバルク
転送なのである程度ひとまとめにしてドカンとやり取りができ速度的には
まだ何とかなっております。しかしCMSIS-DAPはHIDクラスを利用しているので
バルク転送が出来ず、インタラプト転送になります。
USBのフルスピードの場合はフレームあたり1mSec区切りとなるので、
インタラプト転送でも64バイト送れるはずなのですが、上記のとおり
ターゲットへの書き込みの際にブロック転送コマンドを使用していないため
4バイトずつデータを送っているのと全く同じになってしまい、さらに転送の
確認を行っているため実際には2mSecごとに4バイト書き込むということに
なるためどう頑張っても2kByte/Sec以下の書き込み速度になってしまうの
ですorzさらにマイコン-CMSIS-DAP間のSWDのオーバーヘッドもあるので
実際の書き込み速度は1.5kByte/Sec以上出たら御の字ですorz
(注:READの際はブロック転送をおこなっているので早い)
そう言った弱点をトラ技で解説してさらに対策とか講じるのかなと思った
のですが…OpenOCDに関しては案の定貫徹スルーで商用ツールからの使用を
解説しておりました。解決するためにはadi_v5_cmsis_dap.cにメスを入れて
送信時もブロック転送を使えるようにしなければならないのですが他の
デバッグアダプタと整合性が取れなくなってしまうので私もどうしたら
いいか今非常に困ってます…。
以前も述べましたがLPC-Link2ならばUSBハイスピードで繋がり、フレーム
間隔も125uSecごとにスプリットされるので多少速度的にはマシになります。
OpenOCDからCMSIS-DAPをまともに使いたいのなら現状では
LPC-Link2で行うべきです。
20150406追:
CMSIS-DAPが本来の力を取り戻しました。
糞遅かったOpenOCDからの書き込みも快適に行えます☆
それはさておき今回のトラ技の特集ではなひたふさんがJTAGから始まり
主流になったSWD(正確にはSWJ-DP/SW-DP)に至る流れも含め非常に分かりやすく
解説されているのでOpenOCD等のデバッガの動作原理の理解を深めたい方に
とって必読だと思います。基板はあくまでおまけですよおまけ！
おまけのおまけ
…
F**K!!!!!!
OpenOCD小ネタ2
2013年に入ってホビー向けARMマイコンを取り巻く情勢も大幅に変わりました。
導入に結構な金銭的コストが必要だったmbedが、ハードウエア&メーカーの枠が
取り外され、非常に低コストでいろんなメーカのARMマイコンに利用できるように
なりました。さらにARM社も、CMSIS-DAPというCortex系マイコンに特化した
オープンソースのデバッガハードウエアを公開したことにより同じように
GNUのツールに頼らずとも低コストで専用のデバッグ環境をそろえることが
できるようになりました。
導入の敷居を低くすることによりARMマイコン利用者のすそ野を大きく
広げる作戦に出ているようです。
んでもってCooCox等(のEclipseベースですが面倒な初期設定がすべて準備され
かつ無料で全機能が利用できるデバッグサーバ込)のIDEも使い勝手が飛躍的に
向上し環境構築のために時間を費やすorデバッガのデバッグをすると
言った無意味で無駄な行為をする必要もなくなりました。
そういうわけで使いこなせるまでに多くの時間と手間がかかるOpenOCDは最早
無料で利用できるといった唯一のアドバンテージも急速に失いつつ
あります。しかしながら、私を含めた手段が目的になっちゃった人向けに
細々とOpenOCDの解説記事を書いていく所存でございます(以上泣き言終わり)。
●STLink系のアダプタ使うとSPANSIONのFM3マイコンでeraseができない
私がFM3ドライバのエンバグをしていたちょうどその頃、jujurouさんが自身の
ブログ上にてSTLink/V2を使用したFM3マイコンの書き込みについて質問者の方と
やり取りをされていました。私は"単なる結線ミスでしょう"と思ってましたが
丁度MB9AF112KのテストをしてたのでこちらでもSTLink/V2でやってみると
なんとeraseだけできなかった…。
Versaloon(SWD版)やJTAGKey2では問題ないのにSTLink系は駄目。
書き込み動作だけはSTLink系でも可能だったのでOpenOCD側のフラッシュ
ドライバを調べてみるとeraseの操作はtarget_write_u16を使用しレジスタに
16bitのデータを送ることにより行われていました。
分かりづらいユーザマニュアルを見るとたしかにフラッシュ操作の
コマンドは真の16bitアクセスを行う必要があると記述されていました。
一方STLinkやTI-ICDI等のHLAなアダプタはターゲットのメモリの読み書きは
32bitか8bitかのどちらかしかサポートされておらず真の16bitアクセスが
不可能でした。つまりeraseしようとしてtarget_write_u16で必死に送っても
32bitか8bitかの転送コマンドAPIに置き換えられてしまい失敗していたと
いうことになります。
書き込みの時は問題なかったのは書き込み時は書き込みアルゴリズムを
転送してFM3上で実行してるのでこの制約に関係なくwriteコマンドが
成功していたからでしょう。
というわけでeraseの際もアルゴリズムをFM3上で実行するようにして
STLink/V2でも無事FM3マイコンに書き込みができるようになりました。
ついでにjujurouさんの所で質問されていた方も上記のパッチを当てたバイナリを
使用し無事に解決されたようです!めでたしめでたし。
20140227追:
公式にマージされました♥
●USB3.0のホスト(xHCI)でOpenOCDが繋がらない問題は決着か
以前いいところまで原因を追い詰めましたがUSB周りの事は全く分からずドライバを
以前のものに戻してworkaroundとしていました。しかし同様の問題を抱えた方がいた
ようで、その方は自力で解説策を見出したようです。結局ASM1042のドライバのバグが
濃厚で正直libusbx(libusb-1.0も同様)は全く悪くはないのですがlibusbx側で回避
可能なので何時になるともわからないメーカサイドの修正を待つより自分でちゃっ
ちゃとlibusbx側に対策を講じた方がよいのは私も賛同します。
というわけでパッチを当てたlibusb-1.0.dllを作成しねむいさんの環境では動作OK
かつ副作用も全くなし！以前質問を頂いた方々にも協力していただき問題は全て解消
されたとの報告をいただいたので、おきぱで公開しているOpenOCD・UrJTAG・
AvrdudeそしてFlashROMはすべてこのパッチを適用したdllとスタティック
ライブラリを反映しております…っていうか差し替えたのもうだいぶ前ですが
何も不具合報告は頂いてませんので便りがないのはよい便りということで〜
(それでいいのか)
また、USB3.0のホストのドライバ/ファームウエアも最新のものにアップデートして
おかないと不具合につながるケースがあります。
libusbxのwikiにはそのことに対する注意書きも記載されています。
USB3.0ホストが搭載されたここ最近のPCで上手くいかない方は
station-driversで最新のものに変更してから試みることも忘れずに。
●"Remote 'g' packet reply is too long"問題も決着か
長かった…ねむいさんのぶろぐに来た質問でかつて一番数が多かったこの問題も漸く
解決の日の目を見ることになったようです。
"とりあえずFPレジスタ無しをデフォルトにするから弄りたい人はtdesc
コマンドでxmlを指定してレジスタ設定してね"という流れになるようです。
さすがに昔のGDB使ってる人も少なくなりましたからこの変更は必須だと
おもいます。
LPC-Link2(という名のLPC4370評価ボード)を使ってみる
前回は2013/06中旬現在も謎に包まれたNxPのLPC4370が搭載されたLPC-Link2を
OSSで動かし、さらにLPC4370がトリプルコアであることまで突き止めました!
今回はまず安定してLPCLink2として動かすところから切り込みたいと思います。
もちろん今回もメーカ製のツールの事はスルーです！そもそも私のぶろぐに基本的な
使い方なんて期待して見に来ている人なんて誰ひとりいませんから…
●LPCLink2をJ-Linkとして"安定して"動かそう
さて、購入時にNxPが提供するdfutoolからJ-Linkファームウエアをダウンロード
するところからはぢめますがちょっとUSBの認識がおかしいのに気づきました。
↑たぶん正しいときのPOR
↑ちょっと変なPOR
気になってリセット波形を見るとLPCLink2上のLPC4370のreset信号のPORの波形が
微妙に違うときがありました。まさかPORの幅が短い時があるせいですか？と思い、
外付けのリセットSWを付けましたがやっぱり認識しない時は駄目。
それでVCC周りから回路をオシロでずーっと調べていたのですがそんな折にNxP
公式のconfiguration-toolがアップデートされ旧J-LinkファームのUSBがコケる問題が
あったことが判明!!つまりファームの問題！Tooooooo S**K!!
2013/05/31付けのファームと入れ替えることによりUSBの認識は安定するように
なりましためでたしめでたし♥J-Linkエミュとして使用されている方は早急にファームの
変更を行ってください。
つぎに本来の目的だったOpenOCDから使うことを目指しました。前回お見せした
通りJ-LinkファームでOpenOCDから書き込みデバッグできるのですが、たまにchain
読めずその時点でコケて上手くいかない状態が出てきました。
以下、STM32F407ZGT6に書き込みしようとした時のログです。
↓上手くいくとき
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jlink.cfg -f target/stm32f4x_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.8.0-dev-00024-g08d4411-dirty (2013-06-06-10:12)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
verify Capture-IR is disabled
Info : J-Link initialization started / target CPU reset initiated
Error: J-Link command EMU_CMD_VERSION impossible return length 0x7008
Error: J-Link command EMU_CMD_VERSION failed (0)
Info : J-Link JTAG Interface ready
Info : clock speed 1000 kHz
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080450cc msp: 0x10010000
Info : reduce speed request: 21000kHz to 12000kHz maximum
adapter speed: 21000 kHz
auto erase enabled
Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE
Info : device id = 0x10006413
Info : flash size = 1024kbytes
wrote 655360 bytes from file main.elf in 16.062500s (39.844 KiB/s)
verified 555708 bytes in 0.656250s (826.946 KiB/s)
adapter speed: 1000 kHz
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:19↓いかないとき
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jlink.cfg -f target/stm32f4x_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.8.0-dev-00024-g08d4411-dirty (2013-06-06-10:12)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
verify Capture-IR is disabled
Info : J-Link initialization started / target CPU reset initiated
Info : J-Link LPC-Link 2 compiled May 31 2013 17:31:46
Info : J-Link caps 0xb9ff7bbf
Info : J-Link hw version 18010000
Info : J-Link hw type uknown 0x12
Info : J-Link max mem block 38488
Info : J-Link configuration
Info : USB-Address: 0x0
Info : Kickstart power on JTAG-pin 19: 0xffffffff
Info : Vref = 58.368 TCK = 12 TDI = 1 TDO = 0 TMS = 1 SRST = 0 TRST = 1
Info : J-Link JTAG Interface ready
Info : clock speed 1000 kHz
Info : TAP stm32f4x.cpu does not have IDCODE
Warn : JTAG tap: stm32f4x.cpu UNEXPECTED: 0x00000000 (mfg: 0x000, part: 0x0000, ver: 0x0)
Error: JTAG tap: stm32f4x.cpu expected 1 of 1: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0xd0023bff (mfg: 0x5ff, part: 0x0023, ver: 0xd)
Warn : JTAG tap: stm32f4x.bs UNEXPECTED: 0xd0023bff (mfg: 0x5ff, part: 0x0023, ver: 0xd)
Error: JTAG tap: stm32f4x.bs expected 1 of 1: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
Warn : Unexpected idcode after end of chain: 33 0x209820a5
Warn : Unexpected idcode after end of chain: 65 0xffffff83
Error: double-check your JTAG setup (interface, speed, missing TAPs, ...)
Error: Trying to use configured scan chain anyway...
Error: stm32f4x.cpu: IR capture error; saw 0x0e not 0x01
Warn : Bypassing JTAG setup events due to errors
Warn : Invalid ACK 0 in JTAG-DP transaction
Polling target stm32f4x.cpu failed, GDB will be halted. Polling again in 100ms
Polling target stm32f4x.cpu failed, GDB will be halted. Polling again in 300ms
Info : TAP stm32f4x.cpu does not have IDCODE
Warn : JTAG tap: stm32f4x.cpu UNEXPECTED: 0x00000000 (mfg: 0x000, part: 0x0000, ver: 0x0)
Error: JTAG tap: stm32f4x.cpu expected 1 of 1: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0xd0023bff (mfg: 0x5ff, part: 0x0023, ver: 0xd)
Warn : JTAG tap: stm32f4x.bs UNEXPECTED: 0xd0023bff (mfg: 0x5ff, part: 0x0023, ver: 0xd)
Error: JTAG tap: stm32f4x.bs expected 1 of 1: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
Warn : Unexpected idcode after end of chain: 33 0x209820a5
Warn : Unexpected idcode after end of chain: 65 0xffffff83
Error: double-check your JTAG setup (interface, speed, missing TAPs, ...)
Error: Trying to use configured scan chain anyway...
Error: stm32f4x.cpu: IR capture error; saw 0x0e not 0x01
Warn : Bypassing JTAG setup events due to errors
Warn : Invalid ACK 0 in JTAG-DP transaction
Error: Target not examined yet
Runtime Error: C:/Devz/ARM/OCD/tcl/target/stm32f4x_flash.cfg:85:
in procedure 'script'
at file "embedded:startup.tcl", line 58
in procedure 'reset' called at file "C:/Devz/ARM/OCD/tcl/target/stm32f4x_flash.cfg", line 85
make: *** [program] エラー 1
> Process Exit Code: 2
> Time Taken: 00:02J-Linkハードウエアのイニシャライズでコケているような感じはしましたが、コケ
るときとうまくいくときに規則性があるのを見つけてOpenOCDコード内のjlink.cに
切り込みました。
ソースコードを読んだ限りではinit関数の中でJ-LinkハードウエアのI/O設定を通過
する部分があり、LPCLink2によるエミュの場合はそこを通過してしまうと逆にまずい
ことが判明。
というわけでHW-Versionを読み取りJ-LinkのハードがLPCLink2エミュの場合はその
場でinit関数を抜けるようにバイパスしたところうまい具合に動作は安定化してchain
を読みに行くときにコケることは一切なくなりました！
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jlink.cfg -f target/stm32f4x_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.8.0-dev-00037-gc60deb5-dirty (2013-06-14-23:02)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
verify Capture-IR is disabled
Info : J-Link initialization started / target CPU reset initiated
Info : J-Link LPC-Link 2 compiled May 31 2013 17:31:46
Info : J-Link caps 0xb9ff7bbf
Info : J-Link hw version 18010000
Info : J-Link hw type J-Link on LPC-Link2
Info : Vref = 3.300 TCK = 1 TDI = 1 TDO = 1 TMS = 1 SRST = 1 TRST = 1
Info : J-Link JTAG Interface ready
Info : clock speed 1000 kHz
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080449f4 msp: 0x10010000
Info : reduce speed request: 21000kHz to 12000kHz maximum
adapter speed: 21000 kHz
auto erase enabled
Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE
Info : device id = 0x10006413
Info : flash size = 1024kbytes
wrote 655360 bytes from file main.elf in 15.531250s (41.207 KiB/s)
verified 555708 bytes in 0.640625s (847.116 KiB/s)
adapter speed: 1000 kHz
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:17こちらの修正はすでにOpenOCDバイナリに反映しているのでLPCLink2のJ-Link
エミュでも安心してお使いいただけます。自前でビルドされる方向けにパッチ群も
更新しておきました。
UrJTAGも類似した箇所でコケているのでこちらも調査/修正を
20130620追：
UrJTAGも修正掛けました！
所でLPCLink2をJ-Linkとして動かすとNxPのチップにしか使えないはずなのですが
STM32やFM3とかにもOpenOCDからバリバリ書き込み/デバッグが出来てます。
のチップしか使ってはならない"っていう規約的に使用不可であることを示す文面は
どこにも見当たらないのでねむいさんみたいな使い方しても全く問題ないでしょう。
問題あったら6月上旬の時点でNxPFanﾘﾝｻﾝに〆られてますし。
20130709追:
ライセンス制限が追加され、NxPのデバイス以外で使用を禁ずると明記されました。
OpenOCDからSTM32やKinetisやFujitsuやAtmelのARMマイコンに無制限に書き込み/
デバッグできますが、もう絶対にやってはいけません！やるなよ！絶対にやるなよ！
●LPCLink2をLPC4370評価ボードとして使う
こっからが本懐です！たった2000円と少しでトリプルコアLPC4370が搭載された
マイコン評価ボードが使えるのですから…！
前回のUrJTAGによりコアが3つあるMPUということが判明しています。同時に
LPCLink無印の時みたいにMCUのセキュリティは全くかかっていないのが分かった
のでJTAGkey2でやりたい放題にできちゃいます♥
LPC4370がLPC4350の機能拡張版なのを推定し、LPC4330-Explorerの時に使った
サンプルをLPC4370向けに作り変えてみました。ひとまずM4のみのシングルコア
動作です。
ビルドしたバイナリはボード上にあるSPIFI-SPIROMにプログラムを書き込みます。
ここら辺の操作はLPC4330の時と同じですがspifiブートはリセット2回でコケる
errataは無いのでへんてこなOpenOCDのcfgは書かずに済みます
…しかしLPCLink2上のSPIROMは、openOCDのSPIFIドライバに対応していなかった
のでこちらも対応させました…と言っても単にSPIROMのIDとセクタ/容量を追加
しただけです。
↓OpenOCDのログはこんな感じです。もちろんOpenOCDバイナリ・cfgファイル
は上記の修正を反映済です。M0コアが2つ、M4コア1つが見えますね。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/jtagkey2.cfg -f target/lpc4370_lpclink2_spifi.cfg -c "mt_flash_bin main.bin 0x14000000"
Open On-Chip Debugger 0.8.0-dev-00037-gc60deb5-dirty (2013-06-14-23:02)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
cortex_m3 reset_config vectreset
none separate
adapter speed: 2000 kHz
Info : clock speed 2000 kHz
Info : JTAG tap: lpc4370.m4 tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: lpc4370.m0_0 tap/device found: 0x0ba01477 (mfg: 0x23b, part: 0xba01, ver: 0x0)
Info : JTAG tap: lpc4370.m0_1 tap/device found: 0x0ba01477 (mfg: 0x23b, part: 0xba01, ver: 0x0)
Info : lpc4370.m4: hardware has 6 breakpoints, 4 watchpoints
Info : lpc4370.m0_0: hardware has 2 breakpoints, 1 watchpoints
Info : lpc4370.m0_1: hardware has 2 breakpoints, 1 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1400350a msp: 0x200029a0
background polling: on
TAP: lpc4370.m4 (enabled)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1400350a msp: 0x200029a0
Info : Found flash device 'win w25q80bv' (ID 0x001440ef)
cleared protection for sectors 0 through 15 on flash bank 0
auto erase enabled
wrote 65536 bytes from file main.bin in 0.953125s (67.148 KiB/s)
Warn : Invalid ACK 0x7 in JTAG-DP transaction
Polling target lpc4370.m4 failed, GDB will be halted. Polling again in 100ms
Polling target lpc4370.m4 succeeded again
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1400350a msp: 0x200029a0
cleared protection for sectors 0 through 15 on flash bank 0
verified 4656 bytes in 0.031250s (145.500 KiB/s)
Warn : Invalid ACK 0x7 in JTAG-DP transaction
Polling target lpc4370.m4 failed, GDB will be halted. Polling again in 100ms
Polling target lpc4370.m4 succeeded again
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:03上記のログで"Warn : Invalid ACK 0x7 in JTAG-DP transaction"が
出ていますが、これはOpenOCDから直接レジスタを叩きcoreresetを掛けて
いるために発生しているので実害は全くありません。
↑いつものデバッグも自由自在です(LPC4370の素性がわかる範囲で)
ひとまず問題なく動くと思われるLPC4370のプログラムをこちらに置いておきますので
物好きな方は試してみてください。最初に述べた通りLPCLink2は余計な
プロテクトは全くないので失敗を恐れずいろいろ試すことが出来るので、
なかなかいじりがいがあるボードだと思います！
いろいろ試す18
GW中は副業(本業は虹裏メイド)が糞ほど忙しかったのですがおかげで給料も
貯ま…るわけがなく円安を迎えた今はひたすら安価な小物や以前に買った
物をただひたすらに消化していきまっす！
●秋月さんとaitendoさんのi2c液晶キャラクタ液晶モジュール
ぇ？昔i2c液晶の記事書いてたやんだって？さぁ？何のことですか？
これのこと？これはキャラクタじゃなくてドットマトリクスですから別物です別物！
…さて、ホビー用途では配線の手軽さから不動の地位を確立したi2c液晶ですが
秋月さんから安価なAQM0802A-RN-GBWが発売され私もi2c液晶でびぅです♥
コントローラはST7032iというi2cインターフェースに特化したものだそうです。
BOLIMYINの提供していたサンプルのおかげで危なげなく表示出来ました！
お次はaitendoさんから販売されているバックライト付きで破格のi2c液晶たちです！
もう基板に組み込んでますが、秋月さんのと同じくST7032iのコントローラICで
簡・単・表・示…
…と思いきやO-Familyさんも遭遇したF**Kな不具合にねむいさんも遭遇し,"i2cバス
リカバリ"の重要さを思い知らされる羽目になったのでした…
(※STM32F4のFatFs実装例ではすでにi2cバスリカバリのルーチンを実装しております)
これについてはいずれ解説するであろう"i2c液晶を使ってみる"でみっちりと…
●OZSSとGLONASS対応のGPSモジュール Gms-g9
去年の冬,Gms-g6aというMT3333が乗ったモデルを使用していましたが、チップ
アンテナを使用しているため、せっかくの新モデルなのに初回補足時間/感度は
あまりよろしくありませんでした。
4月末に某送料が安い方の欧州店でパッチアンテナモデルのGms-g9が
ようやく販売され、遅ればせながら私もｹﾞｯﾂした次第です。
既に使用されている方のレポートによれば消費電流もPA6Cよりはちょっと多い
(GLONASSの処理があるから)ものの十分控えめなのでSTM32Primer2のロガーと
組み合わせても私のトレラン用途には全く問題ないようです。私はすでに
Gms-g6aで予習していたのでロガー側もGN系センテンス対応済みでそのままPA6Cと
差し替えて試せそうです。
というわけでいつものユニット化してみました。いちばん右の黒いのがGms-g9です。
PA6Cよりもパッチアンテナの面積が広いので感度はさらに上がっているでしょう。
あいにく今週から梅雨に入ったのでPA6Cとの比較試験は来週以降、トレランでの実践
投入は6月末を実施予定としています。
●ILI934x Mystery
SPIモードでDeviceCodeの読み出しができるようになるまでのお話。
Seeedstudioの中の人がいかにしてデータシートに記載されていない複雑なコマンド
体系を見つけだしたのかはいまだに謎
それとねむいさんの英語力に突っ込みを入れないように！！！
●LPCLink2
LPCXpressoに密着していたLPCLinkはirukaさんの解析によると変更不可能なOTPに
よって機能が限定されており外部から全くhackすることが出来ずどっかのSTM32では
出来たDiscoveryでVersaloonが出来ないじゃない！と判明しごくごく一部の解析大好きな
好事家からはったくNxPはｾｺｲな!とスル―してｹﾞﾌﾝされておりました‥
が、
今回デバッガハードウエア単体として販売されたLPCLink2は回路図全公開、さらに
ファームウエア変え放題でしかもCMSIS-DAPやJlinkファームウエアまで用意している
という超太っ腹なボードとなっておりました！
ねむいさんも秒速で入手しその威力を早速試してみました…
電圧変換は前回紹介した74LVCxTx45系が使用されています。LPCLink2ではDIRを
入力に切り替え疑似的にOD化し、1.2〜5.5Vの非常に幅広い電圧範囲をカバー
しているようです。
…LPC4370…？
ねむいさんの目的はJ-Linkです。ほかは一切視界に入れません。THE・シカトです。
そっこう中身のファームをDFUでJ-Linkにしようとしましたがホントの最初はドライバ
不要のHIDローダーで認識されDFUをさらに読み込むようです。この時にDFU用の
WinUSBドライバを読み込ませていないとJ-Linkへのアップデートに失敗するのでご注意を。
WinUSBドライバを読み込ませてこれでJlink化完了！
…ぇっとOpenOCDとかで使ってみましたが‥JTAGKey2と比べるとワンテンポほど
反応が遅くてちょっと微妙な感じです。無理にOSSで使うよりSegger提供のツール
使った方がいいかもしれません。ファームウエア(spifiに格納される)はいくらでも
書き換え出来るのでいろいろやってみましょう。
…そう自分で作成したプログラムも…
20130603追：
やっぱりJlinkエミュレーションのファームヤバかったようで
修正版が2013.05.31にUpしてます…。
で、LPCLink2にはTargetのJTAG端子のほかにLPCLink2の心臓部のLPC4370からも
JTAGが引き出されています。LPC4370って検索しても2013年5月末現在は詳しい
資料全く出ていないしLPC4350系のメモリ多い版かしらと思って何気なくUrJTAGで引っ掛けて
みると…
なんとコアが3つありました…
CortexM4とCortexM0が2つの合計3コア…
トリプルコアなの！？
次回に続く！！
Amontec夜逃げ記念☆JTAGKey2互換回路をもっと使ってみる2
20150514追:
2015年現在、JTAGKey2CompatibleのRev.5まで
上がっています。
自作される場合はこちらを参考にしてください。
下記の記事はもはや内容が古く、正確ではありません！！
20150514追:
数年前、FT2232Hを利用したJTAGkey2Cloneの紹介をしました。しかしちょっと自分で
も回路上で疑問を感じる点が多く、かねてから再製作の構想は考えておりました。
昨今のロジックICの性能向上も相まって2013年の今、再び満を持しての再製作となり
ました…最初に書いたのもう3年前か…もう3年も経ったの…さんねんも……
ｹﾞﾌﾝ失礼、前回は単に回路図と実に抽象的な使用例を紹介しただけでしたが今回は
どうしてそういう部品選定or回路に至ったかのねむいさん的ポリシーも述べます!
●肝心な回路図は…
実は少し前から公開していたのですが…以下のリンク先"JTAGKey2"のディレクトリ内
にあるpdfファイルが新しいJTAGKey2互換回路の回路図となります。
FT2232Dを使ったJTAGKey無印の互換回路も2009年当初のままですが下記リンク先の
"JTAGKey"のディレクトリに収録していますので同じくご参考までに。
JTAGKey or JTAGKey2Compatible Circuits
神木さんのJTAGKey2互換を参考にして作ったねむいさんのJTAGKey2互換を参考に
して作ったjujurouさんのJTAGKey2互換を参考にした最終形です！
そして以前使用していた"Clone"という単語は以下の理由でそぐわないのでもう使わ
ないようにしました。これからは"互換(Compatible)"で統一といたします。
●オリジナルのJTAGKey2との差異
夜逃げしたAmontecから販売されていたJTAGKey2純正品とは機能面で差異があります。
1．暗号化EEPROM(DS2432)の有無
これはオリジナルではFT2232のB側のバスのどれかに接続され、Amontec社が
提供しているamthal.dllはここから書き込まれた情報を読み出し正規品判定を
行っています。
digilentの"JTAG HS-1"もそれと似た仕組みで判定を行っているようです。
2. LEDインジケーターの設定
ねむいさんのJTAGKey2CompatibleのLEDの設定はJTAGKey無印をベースに
しています。JTAGKey2で変更になったLED表示とは全く合っていません。
3. Lattice-ISPVMの使用可否(OE強制制御)
Lattice"さん"提供のISPVMは数年前にFT2232系デバイスからでも書き込みが
できるように神対応をして下さいました！！しかし純正のJTAGKey2からはOEの
手動コントロールが不可能(MPSSEを強制直結状態にできない)のため蓋を
こじ開けてジャンパを飛ばさない限り使用不可能です。
OpenOCDやUrJTAG等のフリーなツールでは純正/互換品に関わらず同じ"JTAGKEY"
として扱われるのでまったく問題なく使用が可能です♥
●回路解説
いくつかのブロックに分けて主要部の解説をします。
1.FT2232H周辺
JTAGKey2互換初号機と同じくDLPDesignのDLP-USB1232Hを使用しています。
面倒なUSB-HS周辺やFT2232系で必須なEEPROM等の周辺部品を搭載し
モジュール化されており非常に簡単に扱うことができます。
今だとUM-232H等のFT232Hを使ったモジュールなども使用可能と思われます。
ただTx/RxバッファがFT2232Hよりも少なく処理速度に影響しますので、
その点はご留意ください。
2.電圧変換(電圧レベルトランスレータ&バッファ)
JTAGKey2互換回路の心臓部です。ここで+1.4V〜+5.5Vまでの幅広いターゲット
電圧に対応します。前回は+1.65Vからでしたが昨今のロジックICの性能向上に
伴いサポートされる電圧範囲の保証される下限がさらに下がりました。
それ故に型番どころか製造メーカ指定まで必須となります。ねむいさんの
ぶろぐ見てる人は同じ74シリーズの同型番でも製造メーカー間で性能が
微妙に違うという昔からよく知られている事実は常識中の常識のはずなので
理解していただけるかと思います。
DIODES Inc. Semiconductor の74LVCE1G125"、
Nexperia(旧NxP)の"74LVC2T45DC"を指定して使ってください。
他メーカーの同型番は駄目です！
また、各バッファICに繋がりFT2232Hから制御されるOEの制御線は必ず+5V
(回路図中ではVbus)で攣ってください。JTAGKey2をPCと接続したときの
これらは入力/Lo出力の疑似的なOD扱いで制御するPC側アプリが多く、
+5V系で攣っていないと+2.5V付近の中間電圧が掛かってしまい動作不良の
原因を作ってしまいます。
jujurouさんが指摘していた+5V系の動作の考察についてはさらに掘り下げて
別枠で考察させていただきます。
3.ターゲット電圧検知
こちらに関してはJTAGKey互換のころと同じく元NEC現ルネサス製のデジトラを
使用しています(ねむいさん的定番部品です)。
↑Rev.4でルネサスを排除しました。使い勝手良かったのですが…さらばFB1A4M。
代替としてROHMのデジトラDTD123YKT146を指定しております。
↑Rev.5に回路が変わりました！
4.OE強制制御
切り替えスイッチで無理やりバッファのOEをGNDに落としてMPSSEで使用される
ポートをターゲットと常に直結状態にします。これは上述のとおりLatticeのISPVM
やデバッグ用途で活躍します。3Pの少信号用SWならなんでも使用可能です。
●実際に組んでみよう
今回はアイテムラボさんのパワーメッシュユニバーサル基板を採用しました。
本来ならVCCに使うべきレーンもすべてGNDに割り当て高速信号の扱いを意識して
配線を行いました…行 っ た つ も り で す ！ ！
前回はFT2232Hのモジュール上部が吹きさらしで打撃を喰らいやすい危険な
構造でした。今回からアクリル板を加工して屋根を設けました。
いい感じですね♥
10MHz越えの高速信号を外に引き出すので信号線とGNDが交互に来るフラットケーブル
は必須です。さらにSEIWA製コの字型フェライトコアを設けて外来/輻射ノイズを殺す
ようにしています。
もともとチップバリスタも基板上に実装するつもりでしたがフェライトコアだけで
100V/1uSecのインパルスノイズ耐量試験を余裕でpassしてしまったのでチップ
バリスタは未実装のオプション扱いにしました。
一からJTAGKey2Compatibleを作る場合は初めにPCと接続したときにVID/PIDが
FTDIの素のFT2232Hとして認識されます。FT2232Hモジュール上のEEPROMに
データを書き込むために先ずはFTDIのドライバを認識させてください。
JTAGKey/JTAGkey2製作用に特別にinfに書き加えたものを用意しましたので
必ずこちらを使用してドライバを読み込ませてください。
2じゃない方のJTAGKeyを作りたい方もこのドライバを使用可能です。
JTAGKey2Compatibleとして動かすためにはEEPROMのデータを書き込んで
化かさなければなりません。従来はMProgを使用してデータを書き込むように
していましたが、現在はFT_Progに統一されましたのでこちらを使用してEEPROMに
JTAGKey2になるためのデータ(xml)を書き込みます。
上のドライバにはJTAGKey/JTAGKey2用のxml
データもJTAGKey_XML.7zとして収録していますのでこれを使用し書き込みを行って
ください。FT_Progの使用法についてはFTDI公式のマニュアルを参照のこと。
書き込みが終わったらUSBケーブルPC一度抜いてさし直してください。成功したら今度
は"Amontec JTAGKey2"として認識されます。
その後はlibusb系を使いたい場合はおなじみZadigでインストールを、FTDIのドライバを
使いたい場合はそのままとしてください。
注:LibUSBKはドライバの入れ替え無しに0.1系と1.0系APIが同時使用可能な便利な
ドライバですがWindowsXP下ではあらかじめ0.1系のドライバをインストールし
ていないと動作が不安定になるようです。一度0.1系でインストールしすぐに
LibUSBKに戻せば問題なく使用可能です。この操作もZadigを使うと楽ちんです
製作したJTAGKey2の動作確認を簡単にしたい場合はOpenOCDよりもUrJTAG
が便利です。ターゲットデバイスに接続して"cable jtagkey"->"detect"の
たった二つのコマンドでJTAGチェインが見えればチェック完了となります。
さらにpodコマンドでSRST,TRSTを含めたJTAGの信号線単体の個別コントロールも
可能なのでトラブルシュートにも役立ちます♥
●ちょっとしたデザインレビュー
20150512注:
以下の検証はRev.4以前のモロが問題だった頃の回路の内容です。
Rev.5にてオリジナルJTAGKey2のサポート電圧範囲に忠実になりましたので
現在はモロで問題有りません。
20150512注:
さて、実際に信用に足るJTAG用デバッガとして使うためにはいくつかクリティカルな
条件を設け試験する必要があります。JTAGkey2互換回路では大きく分けで2つの考慮
すべき点があり、どちらも回路図中の電圧レベル変換ブロックに集中しています。
1.電圧入力レベルに関する点
FT2232HのI/Oの電圧はMAX30Mbpsの高速信号を扱うため+3.3V系のLVTTLと呼ばれる
電圧レベルで固定化されています。(FT2232D系だと3.3V〜5Vで可変だったのですが)
これを考慮してかFT2232Hは+5VI/Oトレラントとなっており+5V系の入出力に対して
耐性を持っています。ですのでFT2232Hの+3.3V出力に10kohmで+5Vにプルアップ
する程度の衝突ならびくともしません
(この荒業は疑似的なOD制御の時に役に立ちます)。
また、SRST,TRST,JTAG各信号線のゲーティングをしているバッファICのOE端子は
FT2232H側が疑似的にOD出力の形で操作しているため、常に+5Vで吊るのが正しい
です。(FT2232H,74LVCE1G125,74LVC2T45のいずれも+5Vの入力トレラントを持つ)
本回路中で使用されている74LVC2T45DCは+1.2〜+5.5V,74LVCE1G125は
+1.4〜+5.5Vまでカバーしており、何れも+5V入力トレラントも保証しています。
つまり+1.4〜+3.3Vまでの回路の場合は電圧入出力とも全く問題はありません。
しかしターゲットが+5V系のケースでは74LVCE1G125のHレベル入力下限(3.5V)を
満たしません。
こちらについてはjujurouさんの情報をもとに74AHCT541(※)を挟み、
LVTTLから+5VCMOSの電圧変換を行うことによって電圧レベルの問題は一旦は
解消としました……しかし…
(※…NxP製の物は74AHCT541と74VHCT541の特性は全く同じ)
2.信号の伝達遅延に関する点
74AHCT541を挟んだことによって同素子内部のゲートを通過する際の遅延が余分に
追加されることになりますが、最初に組んだときは204MHz動作のLPC4330と
TCK=15MHzで接続し、周囲温度も十分振って安定して書き込みデバッグできたので
問題なし！としていました。
ですが純正JTAGkey2がサポートしてるのが30Mbpsだったのを思い出し"本当に
30Mbpsで通信できるのか？"と感じ、購入後放置していた公証80MHzまで使用可能な
SPI-ROMSST25VF032B-80-4I-S2AFとFlashROMを使ってTCK=30MHzで読み出し
試験してみました。
が、リードしたデータがすべて1bitずれた状態となってしまい玉砕orz
…というわけで真面目に伝達遅延の影響について考察を開始しました。
ターゲット電圧3.3VでTCK=30MHzで通信した際に一クロックサイクルは33.33nSec
であり、FT2232HのTCKからでたクロックがターゲットのTCKに届き、それに準じて
ターゲットMISOからの出力とFT2232HのTDO(SI)に届くまでの時間の合計が
33.33nSecを超えてしまうとビットシフトした状態でデータが取り込まれアウトに
なってしまいます。
データシート記載の使用温度環境-40~+125度で動作させた場合(データシート上で
明記されてないものは一番条件が絞れてる温度範囲)のパラメータを抽出して計算
すると上図のように33.33nSecを余裕で超える遅延が発生することになり74AHCT541
を挟むと30Mbpsの通信が理論上ですら不可能なのが判明orz
74AHCT541を省くと7.0nSec分遅延がなくなるため30MHzでもビットシフトは
起こらない計算になり、実際に74AHCT541を省いたモロにするとSST25VF032Bと通信
(DeviceIDの取得,書き込み,ベリファイ)が問題なくできることを確認しましたorz
やはりモロでなければだめだったのですorz
それと配線の引き回しも非常に重要です。10cmを超えるような引き回しをすると
上記のモロでも駄目でした。また、FT2232Hモジュールからレベル変換ICを何も
挟まないガチの直結も試しましたが10cm以上を超えるとやっぱりだめです。
30Mbpsで安定して通信を行うためには高速クロックで動作する回路を意識しないと
いけませんね。
PicoScope3206AでTCKの波形取得してみましたが74AHCT541付きの波形は
見るからにちょっときつくなってますね…。
↑15MHzの時のSPI-ROMのTCK波形(74AHCT541付)
↑15MHzの時のSPI-ROMのTCK波形(モロ)
↑30MHzの時のSPI-ROMのTCK波形(74AHCT541付)
↑30MHzの時のSPI-ROMのTCK波形(モロ)
ここでちょっと疑問に思ったのですが市販のFT2232H系のJTAGハードウェアは
本当に30Mbpsで動かせられるのか？という点です。10MHz以下までTCK速度を
落とさないとOlimexのARM-USB-OCD-Hでは安定して書き込みできないという報告
もあり、もしかしてそれらはレベル変換にFT2232D系で使用されていた低速な
LV系バッファが使われ続けているのではないのかと訝しんでしまいます。
純正のJTAGKey2ではどうなんでしょ?？さすがにできるはずですが…???
3.モロへの誘い
で、ここで74AHCT541外したら3年前作ったのと全く同じじゃん！
とお思いの方が多い筈です。
それは引っ込みがつかなくなったねむいさん本人が一番強く感じています。
というわけで癪なのでモロで動かしたときに+5V系で本当に問題が
ないのかの実力検証を行いました。
使用MCU:
->ATMEGA1284P
動作電圧:
->+5.65V
(安定化電源にてAVRの推奨上限+5.5Vにさらに+0.15Vのマージンを加える)
試験環境温度:
->-15度~+70度
(-15度はコールドスプレーでJTAGKey2互換回路基板上をくまなく冷却,
+70度はドライヤーで同基板上をくまなく加熱)
試験内容:
->試験環境温度下でATMEGA1284pにOpenOCDを試用しJTAGモード(TCK=10MHz)
で100kByte程のプログラムの書き込み動作を行いその動作中にJTAGの
通信エラーやフラッシュの書き損じが一切出ないことの確認。
JTAGモードにした理由はAVRの場合はコア電圧/クロックに関わらず10MHzの
高クロックでAVR内のOCDブロックとの通信が可能なためです。
結果:
->全く問題なし。
現行のAVRドライバはread動作を行うとOpenOCDごと落ちるｽﾃｷ仕様なので上記
環境下でJTAGKey2をISP端子につなぎ変えたうえでAVRDUDEにてISPモードで
読み出しを行い、さらに読みだしたhexをOpenOCDでJTAGモードでフラッシュの
全領域消去->書き込み。
そこから再びAVRDUDEでISPモードで読み出しを行いhexファイルの完全一致の
確認をもって問題無しと判断しました。
てわけで電圧/温度/TCK速度とも一番厳しい状況を作り試しましたが全く問題は
ありませんでした！試験で使用したOpenOCDはatmega1284pのフラッシュ書き込みに
対応させた奴使ってます。ログは↓こんな感じです。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jtagkey2.cfg -f target/atmegaxxx4p_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.8.0-dev-00011-g70a2ffa-dirty (2013-05-11-14:47)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 10000 kHz
srst_only separate srst_gates_jtag srst_open_drain connect_deassert_srst
adapter_nsrst_delay: 100
verify Capture-IR is disabled
Info : max TCK change to: 30000 kHz
Info : clock speed 10000 kHz
Info : JTAG tap: avr.cpu tap/device found: 0x1970503f (mfg: 0x01f, part: 0x9705, ver: 0x1)
Info : JTAG tap: avr.cpu tap/device found: 0x1970503f (mfg: 0x01f, part: 0x9705, ver: 0x1)
auto erase enabled
Info : device id = 0x1970503f
Info : target device is atmega1284p
wrote 113408 bytes from file main.elf in 4.453210s (24.870 KiB/s)
Info : JTAG tap: avr.cpu tap/device found: 0x1970503f (mfg: 0x01f, part: 0x9705, ver: 0x1)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:05同じくAVRDUDEはFT2232系MPSSEに正式対応した6.0RC1をビルドして使用
しております。JTAGKey2があれば難しい設定もワークアラウンドも必要なく
ARMもAVRも余裕で書き込みできるようになっていい時代となりました♥
+5V系でAHCTバッファ挟まなくても問題なかった理由は、74LVCE1G125のVthが
実際は中間電位の+2.5Vで切られていてそれさえ跨げばちゃんとレベルが遷移
できていたからと推測します。データシート上の規約におもいくそ違反して
ますが実力/マージン共に十分あることが確認でき自分が理解して使用する
範囲ならモロでも全く問題なしと判断しました。
(↑売り物の製品の設計の時はちゃんとデータシートに記載された
指示/定格をすべて守ったうえでみっっっちり動作テストを行うのが大前提です！)
もちろん保証の範囲外なので、他のメーカの同種型番のIC等では入力に
ヒステリシスが設けられて全く動かないかもしれません。真似して製作される
方は回路図中でねむいさんが指定したICを必ず選定してください。
｢違うメーカのレベル変換ICをどうしても使うんだーぃ！｣という方はご自身で
動作検証を念入りにした上で使用してください！！！！！！！
念入りというのは回数だけ無意味に重ねるだけではなく温度と電圧くらいは
最低限振れという意味です。ベストな環境だけで満足すると
後で絶対にしっぺ返しがきますから…。
ということで74AHCT541はオプション扱いにとどめ、TCK=15MHz以下でしか
使用しなくて電圧的に心配な人だけ付けてね！ていう風にして冒頭の回路図に
最終的に落ち着く運びとなりました。めでたしめでたし。
20150210追：
+5V系の時の74LVCE1G125の挙動をもう少しガン掘るトしてみました。
VCC=+5.5Vにして入力をわざとゆっくりと上げ下げした時に実際に何Ｖで
出力信号が遷移するかという実験をしました。
先ずは立ち上がり。2.5Vできっちり信号が変化しだしているのが分かり
ますね。2.5V以降の途中で波形が乱れている件は後で解説します。
お次は立下り。こちらも2.5Vで信号が変化しだしています。
本来ならばCMOSロジックの場合はVthはVCCの中点で本実験の+5V系上限値
+5.5Vの場合は2.75VになるはずですがLoレベル寄りの2.5Vとなっていました。
実際に使われる+5.0Vで換算すると74LVCE1G125の真のVthは2.27V付近となる
ことが容易に分かります。FT2232Hの+3.3V出力直結モロでもドライブ能力を
十分に強化して電圧降下を起こさなければVthをまたいで1V近くのマージンを確保
できるので電気的には全く問題がないことが分かります
(※FT2232HのI/Oドライブ能力を最弱の4mA設定にしても30MHzでぶん
回しても問題ありませんでした)。
そんな訳でホビー用途ならAHCTバッファ無しのモロで十分であるという結論と
させていただきます。逆に売り物にする場合は今回のロジックICに限らずデータ
シートに記載されている事項をすべて守った上で周囲環境条件を十分に振って
みっっっっちり
テストしまくって最終的にどういう仕様に落とし込むかを慎重に決めてください。
大切な事なので二度言いました。
｢ねむいさんのぶろぐに書いてある通りに作ったおれはしらん｣とかいう奴に
エンジニアの資格は無いです。
また両者の波形とも遷移直後に大きく出力波形が乱れていますがこれは入力
スルーレートの規約(5V時5ns/V)に違反しているからで、遅すぎる速度の入力に
よって発振が起こっています。上記の測定結果は入力をオープン(殆どのケースで
中間電位になる)にしていると出力が発振を起こして予期せぬ誤動作に繋がる
という重要な事柄も示しています。
CMOSの入力は吊るか落とすかどっちかはっきりと！
最後にスルーレート規約も守ったうえでVCC=5Vで3.3Vドライブした時の波形の
例を。VersaloonのSWCLK波形を入力にしています。
ご覧のとおり問題なく電圧の遷移が出来ていることが分かりますね。
LPC4330を使ってみる2 -OpenOCDでSPIFI-SPIROMに書き込む-
先日秋月さんからもLPC4330-XplorerとLPC1830-Xplorerが販売されたわけですが、
ななんとデバッガハードウエアのULINK-MEもついて6200円ですって！本体+DHLの
送料合わせて1万ちかく払って半分壊れたのよこされた私はなんだったのか！？あと
たった2週間ちょっとまてばULINK-MEゲッツ出来たじゃないか！と悔やんでも仕方が
ないのでホビイストとしては手元にあるものを100%活用していこうと思います。
特に大将からご指名受けてしまい放り投げることもできないのですがFatFs実装は
あつをさんおねがいいたします(ﾊﾟﾀ
さて、LPC4330-Xplorer上ではSPIFIというインターフェースでマルチチャネル
I/O対応のSPI-ROMとLPC4330とが繋がっています。
LPC4330は起動オプションによりこのSPIFI-SPIROMから直接起動&プログラム
実行&リニアな参照ができるというなかなかニクい機能があるわけですが、
内蔵フラッシュを持たないLPC43xx・LPC18xxはどうにかしてこいつにプロ
グラムを書き込まなければなりません。有効と思われる方法は以下の2通り。
1.付属のULINK-MEを繋げてKEILのIDEを使ってプログラムをSPIROMに書き込む。
↑ULINK-MEもってないので却下。
2.DFUブートローダー経由でSPIFI-SPIROMに書き込む
↑情報が出そろってませんがいずれ試します…。
RAM上には流せられるのは確認しました。
OpenOCDは実はSPIFI-SPIROMの書き込みにすでに対応していました。もちろん公式
にはコミットはされていないので自分でパッチ当て+再ビルド必須ですが、私の試行した
限りではいい結果を得られたので上述の確実な2通りに"もう一つ"追加したいと思います。
20120927追：
公式のコミットにも上がりました！
今回はこのOpenOCDを使った方法をご紹介します。
●その前にGCCでコマンドラインビルド可能なLチカるプログラムをこさえる
前回の時点ですでにOpenOCDにつなげて最初に書き込まれていたSPIROMの内容
のバックアップは取っていましたが自分でこさえたのをやっぱり書き込みたいよねと
いうことでいつもののLPC4330版を見据えたベース作りを行います。
LPC4330のSRAM+SPIFIの構成は以下の図のようになっています。
LPC4330コアの最大周波数204MHzでアクセスできるLocalSRAMは合計で200kByte
ありますがご覧のとおりアドレスは連続になってはおらず、128kByte・72kByte分で
ぶつ切りとされています(AHBRAMは構成的に64kByte分すべて連続アクセス可能です)。
SPIFIから実行した場合,104(MHz)/2(Byte)の読み取り速度のボトルネックがあります
ので見かけの動作速度は超大雑把に見積もって30MHz以下になっちゃいますが、ひと
まず一番単純な構成でプログラムも組み易いEXECUTE FROM SPIFIなメモリプラン
を構成しLチカプロジェクトを組みました。
…やっぱLocalSRAMはSH2Aみたく1MByteくらいほしかったなーと感じますね。これ
100PinのチップですからSRAMもSDRAMも外に引き出すのがまた面倒ですし。実際に
204MHzの動作速度を生かしつつ何か作ろうと思ったらプログラムは128kByte以内に
必ず納めてフォントやテーブルなどの比較的低速でもよい大容量データは全部SPIFI
にうっちゃる等の工夫が要求されるでしょう。
SPFI-SPIROM上動作版のリンカスクリプトの冒頭はこんな感じになってます。
●OpenOCDで繋げて書き込む
現在のOpenOCD0.7.0では公式のソースにSPI-ROMとNxP固有のSPIFIドライバのパッチ
をあてて再ビルドする必要があります。私のぶろぐ上で提供しているOpenOCDの
バイナリはこのパッチを適用しています。(下述の書き込みスクリプトも同梱してます)
今回使用するデバッガハードウエアはJTAGKey2Cloneとします。後述しますがLPC4330
のエラッタにより外部リセットの直接操作が非常に重要となるのでリセット(SRST)が
使えるブツが必須です。
それとお気の毒ですがULINK-MEはOpenOCDにハードウエアレベルで対応していない
ので、一切使えません(ファームを書き換えた初代ULINKだけ可能です)!
さて、いよいよSPIFI-SPIROMにプログラムを書き込みます。SPIROMの消去を含む
操作をするためにはFlashのプロテクト解除を必ず行う必要がありました。これを省くと
書き込み時にエラーを返されて失敗します。
↑20130814追：少し前のコミットで修正されました。
↓書き込み時のメッセージは以下のようになります。
書き込み直後にSRSTを直接操作して外部リセットを2度かけています。
>> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/jtagkey2.cfg -f target/lpc4330_xplorer_spifi.cfg -c "mt_flash_bin main.bin 0x14000000"
Open On-Chip Debugger 0.7.0-dev-00001-ga4830e7-dirty (2012-09-24-10:03)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
adapter speed: 2000 kHz
Info : clock speed 2000 kHz
Info : JTAG tap: lpc4330.m4 tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: lpc4330.m0 tap/device found: 0x0ba01477 (mfg: 0x23b, part: 0xba01, ver: 0x0)
Info : lpc4330.m4: hardware has 6 breakpoints, 4 watchpoints
Info : lpc4330.m0: hardware has 2 breakpoints, 1 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x21000000 pc: 0x10000428 msp: 0x10091fe8
background polling: on
TAP: lpc4330.m4 (enabled)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x21000000 pc: 0x10000428 msp: 0x10091fe8
Info : Found flash device 'sp s25fl032' (ID 0x00150201)
cleared protection for sectors 0 through 63 on flash bank 0
auto erase enabled
wrote 65536 bytes from file main.bin in 1.062507s (60.235 KiB/s)
shutdown command invoked
Polling target failed, GDB will be halted. Polling again in 100msなんでわざわざSRSTを直接いじっているかというとLPC4330-Xplorerに乗っかってる
チップのリビジョンは内蔵されたSPIFI-ROMドライバがPOR後の外部リセットした
後の初期化で必ずコケて次の外部リセットで正常に動くというイミフなerrataに
起因してます。
こいつのせいで今までうまくいった正攻法が全く通じずワークアラウンド満載な
書き込みスクリプトにせざるを得ませんでした。
まぁ結果的に安定したからOKということにしましょう。因みSRSTを繋げてなくても
SWD接続のversaloonやSTLink/V2で書くことはできますが、この場合いちいち
主電源を入り切りする必要が生じ面倒です。
また、デバッグ中に変なステートに落ち込んでJTAGのアクセスが一切不能に陥る
こともあります。この場合はディップスイッチでブート方法を別の経路にして
電源を入れ直すとひとまずJTAGで繋がるようになるので落ち着いてSPIFI-SPIROMの
内容を全消去してください(その後はブート方法をもとに戻すのを忘れずに)。
●OpenOCD+Insightでデバッグ
最後の仕上げにOpenOCD+Insightでソースコードデバッグできる環境も作りました。
こちらもワークアラウンド満載でgdbにattachしたときにsoft_reset_haltをかけて
プログラムの先頭で停止するようなトラップを仕掛けてます。
SPIFI-SPIROM上のプログラムを直接参照できるのでとてもありがたいですね♥
もちろんいつものIOViewでGPIOのビットの状態も一目でわかります♥
ちなみにGPIOの初期設定の時にInputBufferを有効にしておかないとピンの状態が一切
読めませんのでご注意ください！(普通のプログラムでも引っかかりやすいポイントです)
●SPIFI-SPIROMからブートしてSRAM上で実行してみる
SPIFIから実行すると大幅にパフォーマンスが下がってしまうので実際に使えるレベル
で試用するならばLocalSRAMからプログラムを実行する必要があります。SRAMの構成上
プログラムと初期設定値があるデータと合わせて128kByte以内に収めないといけない
制約が出来てしまいます。したがって大容量のフォントorデータテーブル等はSPIFI
におきっぱにしておくべきです。
今回はPCと連携せずにスタンドアロンで起動し、SRAM上で実行できる環境を拵えます。
原理としてはきわめて原始的なブートローダをSPIFIに仕込む形になりますが、大まかに
いうと以下の流れで行います。
1.SPIFIのアドレス(0x14000000)からブート
2.Reset_Handlerに飛ぶ(けどアドレスはまだSPIFI上の0x1400****)
3.".text"〜".data"の領域までLocalSRAM(0x1000000)にコピー
4.PCをSRAM上に指定してジャンプ
5.BSS領域をゼロクリア・各種クロック・I/O設定
6.main()に飛ぶ
"4."の部分がミソなわけですが実際のアセンブラのコードを見てもらうと…
一見無意味なことしてるように見えますがその場(SPIFI上)でジャンプすると着地点が
LocalSRAM上になりそのままSRAM上で何事もなくプログラムを継続できる仕組みに
なるわけです。
もうお気づきの方いると思いますが大昔AT91R40807でやってたことと全く
同じですね。
また、上記のからくりを実行するためにはbin形式でSPIFI-SPIROMに書いてやる
必要があります。
LMA/VMAの情報を保持しているelf・ihex形式だと失敗しますのでご注意を。
ということでLPC4330-Xplorerもこちらとこちらに準拠したビルド・デバッグ環境を
こしらえました。
あとはどんどん上位層のプログラムを作りこんでいくだけです！
20121003追:
GCCビルド可能なLED点滅(シングルコア動作)プログラム公開します。
LPC4330はぢめました -まだLチカもできない-
積み基板どころか"詰み"基板になるのが分かっていながら人はなぜ、
何故、同じ過ちを繰り返してしまうのだろうか？
…しかしねむいさんはLPC1788にMCI版FatFsを移植を行ったので十分挑戦権が
あると自負しています！日本のアマチュアでは今度こそ一番乗りで(あつさんがすでに触ってました…)LPC4330が
搭載されたLPC4330-Xplorerの使用感を報告させて頂きたいと思います！！
この基板インド製だそうですがもう時代は中華大陸飛び越えてインドですよ
インド！
さて、この基板はNxP社肝入りのCortex-M4F+CortexM0のデュアルコアが搭載
された最新のマイコンLPC4330が搭載されています。
最大動作周波数はCortex-M系最高速の204MHzに上り(M4,M0コアの両方とも)、
クアッドSPI-ROMが使えるインターフェース"SPIFI"も搭載されています。
USB-HSのPHYもLPC4330内に搭載しており(USB0のみ)、外付けHS-PHYも必要
ありません！
もちろんねむいさんのいつものに必要なMCIインターフェースもあります！
んでもって基板の構成ですがSTM32F4Discovery宜しく音アプリを強く意識
した構成となっていてAudio-CodecやEthernet-PHYも実装されています。
さらに基板上にMicroSDカードコネクタやSPIFI用のシリアルROMも乗っていて
FatFsの移植も少しは楽になりそうですね♥
さぁケーブル繋いで通電だー！と思ったのですが…
…良く見るとコネクタがなんだか変…
写真分かりづらいですが無理やりねじこんだように金具の上側が微妙に
曲がってます…
そして付属ケーブルの口見たらこんなになってやがりました…
注：最初からこんなになってました。ねむいさん壊してないですよぅ！
もちろん刺さりませんorz
もうﾅﾝ持ってｲｪｪと叫びたくなるのを我慢してさらに基板をよく見ると
手半田で修正した跡がありDIPスイッチが溶けてLEDが焦げてました…
もうﾀﾞﾌﾞﾙｵﾄﾞﾛｷですよねほんと印度クオリティすごいってまたひｔ
インドのNGXから直接購入したので修理交換の手間と金が非常にかかって
しまうと感じ、結局自分でコネクタ・LED他の付け替え修理を行いました。
LPC4330-Xplorerに実装されたmicroUSB-Bコネクタとほぼ似た形状の奴を
taobaoで購入しており、スムーズに付け替えは完了しました。ちなみに
秋月さんちで売ってるタイプの奴はコネクタを挿す向きとピンの
並びが逆のため付け替えができません！ご注意ください。
LEDの交換ついでに3.3VのLDOもMLCCが使用可能なZLDO1117に換装して
おきました。
最初に付属していたUSBMicro-Bのケーブルは捨てて手持ちのを使います。
後はチュートリアルに従いVcomのドライバ入れて基本操作を確認しました。
NGXのチュートリアルにはUSB0サイドのUSBHIDデバイスは挿したらすぐに
動くように見られますがまずUSB1サイドをPCに刺し、その次にUSB0サイドを
PCに刺し、最後にSW2を押すとUSB0サイドのHIDデバイスとして認識される
ようになります。
またSW2を押した後は仮想COMポート上で上画像のように各種チェック
ルーチンが走るようになっています。
同時にEtherNetもアクセス可能です(192.1681.1.123固定なのでご注意下さい)
LEDの操作がブラウザ上から可能になっています。
最後にJTAGで繋いでみてOpenOCDからどう見えるか確かめてみました。
LPC4330-XplorerのJTAGコネクタがちいさ過ぎてTI-StellarisのICDI付属の
ケーブルしかピッチが合うのなかったので、JTAGkey2Cloneの代わりに急遽
これを使いました。
↓で繋いだ状態はこんな感じに…
openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/luminary-icdi.cfg -f target/lpc4350.cfg
Open On-Chip Debugger 0.7.0-dev-00001-ga4830e7-dirty (2012-09-10-17:57)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 500 kHz
cortex_m3 reset_config sysresetreq
Info : clock speed 500 kHz
Info : JTAG tap: lpc4350.m4 tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: lpc4350.m0 tap/device found: 0x0ba01477 (mfg: 0x23b, part: 0xba01, ver: 0x0)
Info : lpc4350.m4: hardware has 6 breakpoints, 4 watchpoints
Info : lpc4350.m0: hardware has 2 breakpoints, 1 watchpoints
確かにCortex-M4とCortex-M0のふたつのコアが見えてますね〜
ほんとに触っただけというかそれ以前のやっと修理したばっか状態なのでLチカ
すらも進んでませんが、豊富なサンプルをベースにいつものを作っていきます。
OpenOCDの新MPSSEドライバを試す
20130403追追:
こちらのページにてOpenOCDとInsightを用いた効率的なデバッグ方法を
紹介しております。合わせてご参考願います。
20130403追:
私のおきぱで公開しているOpenOCDバイナリはWinUSB/LibUSB両対応と
なっております。
Zadigでインストールする際にLibUSBKを選択するとドライバの入れ変え無しに
どちらの方法からでもアクセス可能でさらに便利になっております。
MLを追いかけてる人ならご存知と思いますが少し前のOpenOCDのコミットで
新MPSSEプロトコルによるJTAGkey2をはじめとしたFTDI系デバイスでアクセス速度が
さらに向上するサポートが追加されました。
Windows環境下ではLPC17xx系でフラッシュ書き込みの速度不足を感じていたので私も
すぐに飛びつきました。
さて従来のものとどう違うかなのですが、新MPSSEは使用するドライバが
LibUSB(libftdi)やFTD2XX(libftd2xx)ではなくMicrosoftの汎用USBドライバで
あるWinUSBを使用する(実際はlibusb-1.0 async API のバックエンド)ようになります。
ねむいさん今までWindows環境上ではかたくなにFTDI純正ドライバ使用して
きましたが速度的に大幅に優勢になったのとlibusbがWin7系でも十分安定した
ので今回の変更を機にFTD2XXを捨てて乗り換えることにしました。
以下いくつかのMCUで実際に書き込みの比較を行います。
FT2232系デバイスとしてJTAGKey2を使用しています。
●RCLKを効かせたLPC2388の場合
*FTD2XX
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/ftdiOCD/tcl -f interface//jtagkey2.cfg -f target/lpc2388_rclk_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00624-gaf9918d-dirty (2012-07-17-22:29)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
RCLK - adaptive
Info : device: 6 "2232H"
Info : deviceID: 67358712
Info : SerialNumber: 22222222A
Info : Description: Amontec JTAGkey-2 A
Info : max TCK change to: 30000 kHz
Info : RCLK (adaptive clock speed)
Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
Info : Embedded ICE version 7
Error: EmbeddedICE v7 handling might be broken
Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units
fast memory access is enabled
dcc downloads are enabled
target state: halted
target halted in Thumb state due to debug-request, current mode: User
cpsr: 0x00000070 pc: 0x0002b5ae
auto erase enabled
wrote 491520 bytes from file main.elf in 7.796974s (61.562 KiB/s)
verified 465140 bytes in 0.515632s (880.935 KiB/s)
requesting target halt and executing a soft reset
target state: halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x000000d3 pc: 0x00000000
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:09*WinUSB
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/jtagkey2.cfg -f target/lpc2388_rclk_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00626-g10fd274-dirty (2012-07-23-11:26)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
RCLK - adaptive
Info : RCLK (adaptive clock speed)
Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
Info : Embedded ICE version 7
Error: EmbeddedICE v7 handling might be broken
Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units
fast memory access is enabled
dcc downloads are enabled
target state: halted
target halted in Thumb state due to debug-request, current mode: User
cpsr: 0x00000070 pc: 0x0002b5a8
auto erase enabled
wrote 491520 bytes from file main.elf in 4.859437s (98.777 KiB/s)
verified 465140 bytes in 0.437505s (1038.247 KiB/s)
requesting target halt and executing a soft reset
target state: halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x000000d3 pc: 0x00000000
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:06もう全然威力が違うのがわかりますね♥
●STM32F4の場合
*FTD2XX
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/ftdiOCD/tcl -f interface//jtagkey2.cfg -f target/stm32f4x_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00624-gaf9918d-dirty (2012-07-17-22:29)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
verify Capture-IR is disabled
Info : device: 6 "2232H"
Info : deviceID: 67358712
Info : SerialNumber: 22222222A
Info : Description: Amontec JTAGkey-2 A
Info : max TCK change to: 30000 kHz
Info : clock speed 1000 kHz
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080451a0 msp: 0x10010000
15000 kHz
Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE
Info : device id = 0x10006413
Info : flash size = 1024kbytes
stm32x mass erase complete
wrote 550968 bytes from file main.elf in 4.093803s (131.432 KiB/s)
verified 550968 bytes in 0.781260s (688.701 KiB/s)
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:20*WinUSB
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/jtagkey2.cfg -f target/stm32f4x_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00626-g10fd274-dirty (2012-07-23-11:26)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
verify Capture-IR is disabled
Info : clock speed 1000 kHz
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08045c28 msp: 0x10010000
21000 kHz
Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE
Info : device id = 0x10006413
Info : flash size = 1024kbytes
stm32x mass erase complete
wrote 550968 bytes from file main.elf in 3.937550s (136.647 KiB/s)
verified 550968 bytes in 0.546882s (983.859 KiB/s)
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:21残念ながらSTM32系はフラッシュの消去が遅いので(autoeraseだとさらに遅くなるので
"stm32f2x mass_erase 0"の使用を推奨)そっちに足が引っ張られます。実際のテンポは
あまりよろしくないです。それでも100kiB/Sec越え(どっちも越えてますがー！）
また同じスクリプトファイルでも新MPSSE版はJTAGのクロックが細かく設定できるよう
になり若干JTAGのクロックも早くなります♥
20130507追:
…と思いきや実際にオシロで波形を測定してみると15MHzのままでしたorz
FT2232Hの仕様上MPSSEの最高が30MHzでその一つ下は15MHzとづづきますからLibftdiの
時はOpenOCDの周波数の表示が計算上の値を正直に出してるだけで実際にFT2232Hに
設定されるTCKの周波数とは全く違うということですねorzorz
ちなみにSTM32F1系はもっと悲惨でフラッシュの書き込み速度も遅いため
35~7kiB/Secで一律頭打ちになってしまいます。
*FTD2XX
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/ftdiOCD/tcl -f interface//jtagkey2.cfg -f target/stm32f107.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00624-gaf9918d-dirty (2012-07-17-22:29)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
verify Capture-IR is disabled
Info : device: 6 "2232H"
Info : deviceID: 67358712
Info : SerialNumber: 22222222A
Info : Description: Amontec JTAGkey-2 A
Info : max TCK change to: 30000 kHz
Info : clock speed 1000 kHz
Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0802bb00 msp: 0x20010000
7500 kHz
Info : device id = 0x10016414
Info : flash size = 512kbytes
stm32x mass erase complete
wrote 434240 bytes from file main.elf in 11.765700s (36.042 KiB/s)
verified 434240 bytes in 1.015631s (417.536 KiB/s)
Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:13*WinUSB
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/jtagkey2.cfg -f target/stm32f107.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00626-g10fd274-dirty (2012-07-23-11:26)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
verify Capture-IR is disabled
Info : clock speed 1000 kHz
Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0802bbe0 msp: 0x20010000
9000 kHz
Info : device id = 0x10016414
Info : flash size = 512kbytes
stm32x mass erase complete
wrote 434240 bytes from file main.elf in 11.640700s (36.429 KiB/s)
verified 434240 bytes in 0.765629s (553.875 KiB/s)
Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:13●FM3の場合
*FTD2XX
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/ftdiOCD/tcl -f interface//jtagkey2.cfg -f target/mb9bf618t_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00624-gaf9918d-dirty (2012-07-17-22:29)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
trst_only separate trst_push_pull
500 kHz
cortex_m3 reset_config sysresetreq
verify Capture-IR is disabled
Info : device: 6 "2232H"
Info : deviceID: 67358712
Info : SerialNumber: 22222222A
Info : Description: Amontec JTAGkey-2 A
Info : max TCK change to: 30000 kHz
Info : clock speed 500 kHz
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : mb9bfxx8.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000114 msp: 0x20010000
Rize up to Internal PLLed Clock!
15000 kHz
auto erase enabled
Info : Fujitsu MB9Bxxx: Sector Erase ... (0 to 5)
Info : Fujitsu MB9B500: FLASH Write ...
wrote 524288 bytes from file main.elf in 9.312559s (54.980 KiB/s)
verified 505904 bytes in 0.578129s (854.562 KiB/s)
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:12*WinUSB
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/jtagkey2.cfg -f target/mb9bf618t_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00626-g10fd274-dirty (2012-07-23-11:26)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
trst_only separate trst_push_pull
500 kHz
cortex_m3 reset_config sysresetreq
verify Capture-IR is disabled
Info : clock speed 500 kHz
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : mb9bfxx8.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000114 msp: 0x20010000
Rize up to Internal PLLed Clock!
18000 kHz
auto erase enabled
Info : Fujitsu MB9Bxxx: Sector Erase ... (0 to 5)
Info : Fujitsu MB9B500: FLASH Write ...
wrote 524288 bytes from file main.elf in 6.984419s (73.306 KiB/s)
verified 505904 bytes in 0.343753s (1437.215 KiB/s)
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:09FM3の場合はフラッシュの読み書きが非常に速いためRCLKを効かせたLPC2388
並みに速くなっています！
(でもCQ出版系の雑誌記事では大人の事情でわざわざこの性能を殺し、
さらにわざわざめんどくさい使い方やデバッグ方法しか紹介してませんね…)
上記3つの検証ではねむいさん特製の各マイコンに合わせたOpenOCDのスクリプトで
あらかじめCPUの最高速度まで叩き上げてこの数値を出しています。
(最高速にするために動作電圧も+3.3Vを想定しています)。
ということで今回の変更によって益々デバッグの回転力が上がることが期待されます。
また、付加的な利点としてFTD2XXを排したことによりプロプライエタリなライブラリが
なくなるのでOpenOCDのバイナリがおおっぴらに配布できるようになるという私のよう
な教える側の人にとってはARMマイコンのビルド・デバッグ手順の整備が大幅に短縮・
簡略化されることにもなり非常に手間が省けます♥ こっこれで"ねむいさんという
人のページみたけどやり方がさっぱり"って後ろ指挿されることなくなったんじゃ！！
中途半端に尺が余ったので、今までにOpenOCDの操作に関していただいた問い合わせの
中で私が｢初めて触った人が陥り易く、かつ致命的になる｣と感じた問題たちについての
回避策やtipsをご紹介したいと思います。
●STLinkでOpenOCD使ってみたいのですがLibUSBやWinUSBのドライバの
インストール方法が面倒そうででわかりません＞＜;
->zadigれ
●あんたのところの記事をもとに基板作って自作のプログラム書き込んだらJTAGで
一切アクセスできなくなってフラッシュが書き換えできなくなってしまった。責任とっ
てこさえた基板言い値で全部買い取れ。
->STM32ではWFI命令を含むプログラムを実行した後ペリフェラルのクロックが停止し
ますが同時にコアにあるデバッグユニットに供給されるクロックも仲良く停止し
てしまい、JTAG/SWD等で一切アクセスできなくなってしまいます。
回避策はWFIが実行される前に速攻HALTをかけてフラッシュを全消去して電源再投
入してやれば再びアクセスできるようになります。しかしこの方法はタイミングが
シビアすぎるのでお勧めできません。
確実な方法は、システムメモリからブートするモードにしておき、リセットかけ
ても常にブートローダーに飛ぶようにしておくとJTAG/SWDでアクセスできるよう
になってとにかくフラッシュを消去できるようになります。ブートローダーから
そのままFlashLoader等のツールでUART経由で消去しても構いません。
ここ最近で"元に戻せなくなった"と↑の質問をいただくケースが激増してます。
戻す方法はちゃんとあるのであきらめないでください。
●LPCXpresso基板のLPCLinkの部分を分離してJTAGkey+OpenOCDをデバッガにして
開発を始めてみました。でも何故かmbedやLPCXpresso(ねむいさん注：IDEの方)
で動いていたLチカのプログラムが全く動きません＞＜;
->NxPの内蔵フラッシュ付きのARMマイコンは伝統的にCheckSumValidationを持って
います。これはリセット直後にフラッシュのとある番地にあるリセットベクタの
チェックサムの値を確認し正しくなければISPに飛んでいく機構です
(ユーザーマニュアル参照)。
mbedやLPCLinkのライタは書き込む際にリセットベクタのチェックサムを計算し、
その番地の値だけ計算済みの値に改変して書き込むのでCheckSumValidation
を通過しユーザープログラムを実行することができます。もちろんOpenOCDでも
同じことが可能ですが、ベリファイの際は改変前のバイナリと比較してしまう
ため、必ずエラーになってしまいます(=ゆえにベリファイだけできない)。
ベリファイまで通したい場合は、あらかじめ計算した値をリセットベクタの指定
のアドレスに書き込んでおくことで可能となります。私が公開しているLPC系の
マイコンのプロジェクトは、すべて計算済みの値を記してあるので参考にしてく
ださい(スタートアップのアセンブラファイルに直値を記述)。
●フリーのEclipseを使った開発をしているのですが(ry
->(全身から血をふきだして死んだ)
※しかしねむいさんは有償のEclipseベースの開発環境では死にません。
死ぬのはあくまでも設定が死ぬほど面倒な素のEclipseで攻撃された時です。
あといないさんのおぱんつ画像でも一発で死にますので絶対に見せたりしな
いでください絶対ですよ絶対！！１！１
●ねむいさんの手順の通りにしているけどOpenOCDがビルドできません＞＜;
->ビルド済のバイナリを用意したのでこれからはおきぱのOpenOCDのバイナリを使っ
てください。FTD2XXのライブラリは使用していないのでGPLに引っかからずバイ
ナリを自由に利用できるようにしました!…あとご忠告ですが、最初のうちは変
な自分流のアレンジをしたりせずにあくまでも手順に沿ってやりましょうね…。
●mt_flashとかいうのがよくわかりません&見つかりません＞＜;
->大昔はtelnetでOpenOCDとコマンドのやり取りをし、マイコン内蔵のフラッシュに
プログラムを書き込む方法しかありませんでした。現在はその方法はスマート
では無く、ARMコアなルーターのフラッシュ書き換えの際の動作確認程度にしか
利用されていません。
デバッグでカットアンドトライをしてる時はとても効率が悪いです。
しかしながら上記のような"現在は不適切なor廃止された"とされる数年以上も
前のOpenOCDに関する情報が｢最新のOpenOCDを〜｣という見出しで検索の
トップを占めているのが現状で、何も知らない人がこれらの情報をもとに"最新"
のOpenOCDを使おうとしても当然うまくいくはずもなく、"使えない"、
"敷居が高い"という印象を持って離れてしまっています。
2012年7月現在"最新"の0.6.0ではWindowsはバッチファイルで、Linux系なら
シェルスクリプトでJim-Tclのスクリプトをコマンドの引数として一括で呼び出す
ことにより簡単に書き込み動作ができるようになります。mt_flashってのはその
スクリプトの名前のことで、それが記述されているスクリプトもしくはコンフィグ
ファイルがないと当然使用できません。私が公開しているOpenOCDのバイナリ
にはそれらが仕込まれたコンフィグファイルがありますので安心してお使い
ください。
ちなみにmakeと組み合わせることによりさらに効率よく開発が可能です。
長々と書きましたがここ見てくれれば間違いないのですがそうだね宣伝だね。
●"Remote 'g' packet reply is too long"というエラーが(ry
->去年の年末に｢次それ聞いたら頭にJTAGKeyぶっ挿して一ビットずつ対策方法焼き
こんでくから｣…って私言いましたよね！？
FM3マイコンを使ってみる3 -FatFsとTFT液晶表示の実装-
今月(2012年7月号)のInterface誌は予想に反して私のようなホビイストには
とてもありがたい内容となっておりました。
ねむいさんは正直Windowsネイティブな環境でもGCCでビルドや
デバッグできるのになぜか面倒なcygwinを使わせた上糞の役にも立たないLED
点滅で終わらせて実用的な作例はIARとかKEILのIDEのみで行って｢んんんｎ〜〜！！！
GCCは面倒ですぞ〜！CQ出版がお勧めするIARやKEILを使ってくだされ〜！１！｣って
販促するパタンで畳み掛けると思ったのですがどうせなら開き直ってDS-5とか
推せよとかいつも思っていたのですが今回は全然そういう事は全くなく、
オープンソースなソフトウェア(OSS)をフルに活用した記事が満載でした。
もちろんOSSにもメリットデメリットがあって邑中 雅樹氏の講演のスライド13p目に
それが集約されていると思います。タダより高くつくものはないです。
しかしながら趣味でやる場合は互いに情報を出し惜しみすることなく情報を
やり取りすることによって敷居を低くできるので横のつながりを大切にして
いきましょうね。
私も"ねむいさんのページ見てもわかりづらくてOpenOCD動かせられなかったけど
他の人のページに書いてあるやり方だったら一発で出来た"と言われないような
記事作りを心がけて行きます(←まだ根に持ってる)
…さて戯言はこの辺にしといてFM3マイコンはFatFsとシリアル&i8080バス
接続タイプのTFT-LCDドライバを使ったいつものの実装を目標と
しています。FM3のデータシートや
アプリケーションノートは情報散らばりすぎでいまいち組み方がわかりづら
かったのですが、上記IF誌に収録されていた作例にわかり易いサンプル例が
多数収録されておりそれを最大限に活用させていただきました。
●UARTとFatFs
UARTは前回行ったのと同じですが、前回jujurou氏よりコメントいただいた通り
SRAMの割りあてはSTM32F4の時のように目くじら立てるほどのことではないことが
判明しふつーに128kByteの内蔵SRAMとして使うことにしました。私が試した限りでは
すべてのSRAM領域でDMA可能でなおかつコード実行も可能でした。
というわけでChaN氏の作例にならってMFSを使ったMMC用のドライバも作り、
危なげなくFatFsも動作確認しました。ちなみにChaN氏はDMAを使用せずFIFOを
使用していますがSCKを18MHzにしたリード速度は下画像のようになりました。
STM32F107(DMA転送)の時とほぼ同じですね〜。SPIモードの場合の理論上の
転送スピードは18MHzの時約2.2MByte/Secになりますから無理してDMA化する必要が
なかったようですね。尤もFM3においては内部の遅延により+3.3V駆動の際に保証
されるSCLKの最高速度は7.2MHzにしかならないそうです。
STM32F4とかはSPIでも42MHzまで叩き出せるのにs**kです。
●シリアル接続タイプのTFT-LCD
扱いも容易でaitendoさんで手軽に購入できるようになったシリアル接続タイプの
TFTLCDも、FatFsの時と同じくMFSを利用してHALを作りました。もちろんGPIOによる
ソフトウェアSPIにも対応していますが…FM3のGPIOはAPBバスにぶら下がっていて
なおかつ1HCLK分ウエイトが掛かっているようでGPIOの出力レジスタに8bitのデータ
投げるような単純にstr命令だけが連続するような操作でもMAX12MHz、ビットバンド
領域の単純なビット操作はその半分のMAX6MHzしか出ないことが判明し、あまりお勧め
できません。
↑0xFFと0x00を交互にPDORFxに全速力でﾌﾞﾝ投げた時のI/Oトグル波形…
STM32F1(18MHz)以下ですかorz
↑ビットバンドなアクセスの場合はCortexの仕様上最短2クロックサイクル
かかるのでさらにその半分orz
TFT-LCDのRES線制御等の1ビット分だけの制御の場合はリードモディファイ
ライトが行われないビットバンド領域のアクセスの方が早いです。
ちなみにFM3にはSTやNxP系ARMマイコンにあるGPIO出力ポートのビット
セット/リセットレジスタなぞありませんorz
また、上のFatFsの話の時は7.2MHzしかSPIの速度が出せないと述べていますが
リードのことは考えずただLCDにシリアル信号をﾌﾞﾝ投げるだけなら18MHzでも
全く問題ないのでどしどし使いましょう。とくにFM3では9bitシリアルもハード
ウエアで設定可能であり、9bitシリアルにしかI/Fが対応していないTFT-LCD
モジュールなどでは速度面で重宝します。
↑ということで9bitシリアルにしか対応してないHX8340B(N)なTFT-LCDモジュールを
ハードウエア9bitSPIで動かしてみました。表示が早くなって感激です！
これでNokia6070その他9bitシリアルな液晶さんたちが救われます！ちなみに…、
いないさんの大事な部分が見切れていますがこれはPNG表示ルーチンの仕様です。
●外部バスとi8080バス接続タイプのTFT-LCD
今回のFM3基板に乗っかっているチップはA24までExternalBusInterfaceとして
アドレスバスが出せられます。
とはいえLCDを駆動するだけならアドレス線は一本だけで十分ですが…
こちらに関しては7月号の付録に収録されている松浦氏のMP3プレーヤーのLCD/SRAM
アクセス初期化部をかなり参考にさせていただき、さらにSTM32/LPC2388のように
柔軟性を上げて作り込みました。
今回の松浦氏の紹介にあるMP3プレーヤーの基板の回路に互換性をもたせてあります
ので他の方も再現できると思います(タッチパネル制御はADCを使用せず、ADS7843に
任せていますので非互換です)
↑この写真ではすでにタッチパネル制御も入れてます。
●タッチパネル制御
タッチパネルによる座標情報はタッチパネルコントローラICであるADS7843を
使用して得ています。AD7843はSPI通信の信号はかなり遅めにする必要があるので
簡素なGPIOによるソフトSPIでも十分間に合います。
さて、タッチパネルはキャリブレーションが必須ですが、キャリブレーションした
後のデータはこのFM3基板上実装されたFRAM(MB85RC16)にストアしました。
こちらに関してもChaN氏がFRAM向けのI2Cドライバとして実装されていたので
こちらを活用し、ストア・リストアするルーチンを作り込みました。
使用していて気付きましたが、やはりFRAMであってもWRITEを行った後は少し
ウェイトを挿入しないと次のWRITE操作に影響が出ることが分かり、なるべく
一つのデータにまとめて一つのWRITE操作で書き込むようにしています。
…ということでChaN氏のFatFsとファイラを実装して動かすという当初の目的が
達成されたわけですが、PWM出力と外部SRAM、あと外部SRAMとのDMA転送も試して
みたいのでもう少しコードは練った上での公開とさせていただきます。
公開しています。
STM32F0とXMEGAのFatFsのDMA化とTIのStellarisと東海自然歩道のネタが次に控えて
いて書くことがたくさんあり過ぎますがもう少しだけFM3です。
おまけ：FM3マイコンの性能やデバッグ効率を上げる小ネタです。
●FM3のパフォーマンスをアップする
HCLKが72MHz以上の時、FM3はプリフェッチバッファが有効になるそうですが
(元から有効化されてるみたいですが)この時さらに先読みした命令をストアできる
トレースバッファを有効化することもできます。FUJITSU提供のテンプレートでは
有効化するルーチンは無いので自分で挿入する必要があります。
消費電流は100mAオーバー(HCLK=144MHz時)で結構発熱しますがそれを厭わない方は
ｶﾞｼｶﾞｼ使って行きましょう。
●OpenOCD経由のフラッシュ書き込み速度を増加してデバッグ効率のアップ
現在のOpenOCDのFM3のフラッシュ書き込みルーチンは、I/Dコードバスに
ぶら下がった内蔵SRAM領域にフラッシュ書き込み操作とフラッシュに書き込む
データをJTAG/SWDで転送・実行していますが、ワークメモリの容量はハード
コーディングされています。128kByteもあるMB9BF618Tではもっと大容量の
メモリを確保可能なのでこの部分をデバイスID別に可変にするようにしました
(MB9BF618Tの場合は32768Byteにしました)。
ワークエリア増やしてもあんまし変らんだろと思っていましたがなんと
驚くべき結果が！！！！！
> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jtagkey2.cfg -f target/mb9bf618t_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00595-g445a54a-dirty (2012-05-26-12:03)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
trst_only separate trst_push_pull
500 kHz
cortex_m3 reset_config sysresetreq
verify Capture-IR is disabled
Info : device: 6 "2232H"
Info : deviceID: 67358712
Info : SerialNumber: 22222222A
Info : Description: Amontec JTAGkey-2 A
Info : max TCK change to: 30000 kHz
Info : clock speed 500 kHz
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : mb9bfxx8.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000114 msp: 0x20010000
Rize up to Internal PLLed Clock!
15000 kHz
auto erase enabled
Info : Fujitsu MB9Bxxx: Sector Erase ... (0 to 9)
Info : Fujitsu MB9B500: FLASH Write ...
wrote 1048576 bytes from file main.elf in 18.625118s (54.980 KiB/s)
verified 941740 bytes in 0.828131s (1110.534 KiB/s)
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:21なんと
wrote 1048576 bytes from file main.elf in 18.625118s (54.980 KiB/s)
となって、前々回と比べると5倍以上高速化出来るようになりました！
なんというか新生青銅聖衣を装着して敵の本拠地にカチ込まんとする
星矢さんのような"よぉしこれで全力で戦える！！！"な気分です。
一通り検証も終わったのでOpenOCDビルド時のFM3向けパッチとして公開しています。
今回のパッチはiruka氏とjujurou氏の物を合わせたのをベースにしてます。
また、OpenOCDのFM3向けコンフィグファイルと組み合わせないと性能が
出ないので上のOpenOCDのビルド&デバッグ方法をよく読み試してください。
FM3マイコンはぢめました
20140318追:
かつてOpenOCDのFM3ドライバには様々な致命的なバグが存在しておりましたが
ネムイ・トリノミアスさんという美少女の活躍のおかげでほとんどのバグは
解消され、安定して使用が可能となっております。
私のぶろぐにおいてもFM3ドライバのバグが修正済の最新のOpenOCDバイナリ
を公開しておりますので是非ご利用ください。
20131031注：
OpenOCDのFM3ドライバは致命的バグが放置されております。他の方のHP/ブログ
経由で私の所にうまくいかないできないといった質問が何度も来てるのですが、
IF誌収録のバイナリはまだ修正しきれておりませんのでご注意ください。
変なアレンジをしようとしないでまずは私のやり方をまねてください！
私が公開してるOpenOCDのWindowsバイナリは上記致命的バグをすべて修正して
おります。Linux系OSユーザーの方のためにパッチも公開しておりますのでご参考に。
20120708注：
IF誌についてたQEMUはFM3固有のペリフェラルのエミュレーションなぞわざわざ
やってないので、私のやつをビルドして使ってもQEMUでは一切動きません！S**K!
富士通製Cortex-M3なARMマイコンのFM3シリーズであるMB9BF618T。
これが実装された付録基板が付いているInterface誌6月号の明日の販売を控え、
帰宅途中に"たまたま"ふらっと寄った新大阪の某所で売られていた6月号を
購入しさっそく基板を動かして見ました。
…なんかねむいさん変てこりんなこと言ってるような気がしますが多分
気のせいです。あと国産マイコンは絶対に扱いませんといっときながらFM3は
使うのかという突っ込みに対しては中身は英国製ARMコアなのでノーカウントと
させていただきます！１１！！！！
…さて戯言はこの辺にして、今年1月ごろにはすでに基板に関する情報が
出回っていたので先回りしてデータシートやマニュアルを熟読しSystickを使用した
簡単なプログラムを作成、いわば予習はすでに行っていました。
とはいえそれ程仰々しいものでもなく、最早慣れ親しんだCortex-M3だったので
LPC1343とSTM32F107の物をベースにしたスタートアップコードやデータシート
首っ引きでリンカスクリプトをこしらえGCCでビルド・デバッグ出来る物をサクッと
やっけつました。
正直LPC1788の時の方がむずかしかったです。
そしてビルドして出来たバイナリをMB9BF618Tに書く手段ですが‥‥、
これが都合よく少し前にOpenOCDにFM3マイコンのフラッシュ書き込み
ルーチンが実装されていました。
なおかつjujurou氏が別型番のFM3マイコンにてOpenOCDからの書き込み・
デバッグをした時の成果をすでに残されていたのでこちらもありがたく使わせてもらい、MB9BF618Tのフラッシュ書き込みにも対応したOpenOCDを作成し、
万全の体制で今日を迎え撃ちました。
結果ですがOpenOCDからプログラムの書き込み・デバッグに無事に成功です！
↓書き込み時に出るOpenOCDのメッセージはこんな感じです。
> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jtagkey2.cfg -f target/mb9bf618t_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00527-gf908bae-dirty (2012-04-24-21:47)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
trst_only separate trst_push_pull
500 kHz
cortex_m3 reset_config sysresetreq
verify Capture-IR is disabled
Info : device: 6 "2232H"
Info : deviceID: 67358712
Info : SerialNumber: 22222222A
Info : Description: Amontec JTAGkey-2 A
Info : max TCK change to: 30000 kHz
Info : clock speed 500 kHz
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : mb9bfxx8.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000114 msp: 0x20000000
auto erase enabled
Info : Fujitsu MB9Bxxx: Sector Erase ... (0 to 0)
Info : Fujitsu MB9B500: FLASH Write ...
wrote 16384 bytes from file main.elf in 2.046889s (7.817 KiB/s)
verified 804 bytes in 0.421877s (1.861 KiB/s)
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
shutdown command invokedリセット時の内部発振4MHzで動いてる状態です。今後クロックアップさせる
予定なのでもう少し使い勝手が良くなるでしょうね♥
…ぇ？俺も早くOpenOCDビルドして試してみたいですって？
…ふっふっふ、とっくに対応済ですよぅ？
という所で本日試したPORTF3にぶら下がったLEDを点滅するだけのもの
すごく単純なFM3基板(FRK-FM3でしたっけ)向けのGCCでビルドできるプログラムは
こちら。
また、↑をビルドするための超分かりやすいビルド方法はこちらになります。
↑をデバッグするための超分かりやすいデバッグ手順はこちらになります。
そうだね宣伝ｄ(ry
今はLED点滅だけですがこれにUART経由の文字列出力等の基本的なのを順次アップ
デートしていきます。私はSTM32F4弄るのがメインなのでFM3にはそこまで興味は
無く、予定は大幅に伸びるでしょうけども6月の半ばにはいつものがおきぱに現れ
て皆が利用できる状態になるとおもいます。
20120425追:
●OpenOCDからのフラッシュ書き込み速度をアップさせる試み
system_mb9bf61x.c内のSystemInit(でしたっけ？)関数のPLLを使ってクロック
アップしているルーチンをOpenOCDのスクリプトに落としてみました。
ただし、汎用性を保つために大元のメインクロックは外部のシリコン発振器
からの4MHzではなく内部RC発振の4MHzを使用し叩きあげるようにしました。
↓で、こちらが昨日と同じバイナリを書き込んだ結果です。
> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jtagkey2.cfg -f target/mb9bf618t_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00529-gf28a5d9-dirty (2012-04-25-13:27)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
trst_only separate trst_push_pull
500 kHz
cortex_m3 reset_config sysresetreq
verify Capture-IR is disabled
Info : device: 6 "2232H"
Info : deviceID: 67358712
Info : SerialNumber: 22222222A
Info : Description: Amontec JTAGkey-2 A
Info : max TCK change to: 30000 kHz
Info : clock speed 500 kHz
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : mb9bfxx8.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000114 msp: 0x20000000
Rize up to Internal PLLed Clock!
6000 kHz
auto erase enabled
Info : Fujitsu MB9Bxxx: Sector Erase ... (0 to 0)
Info : Fujitsu MB9B500: FLASH Write ...
wrote 16384 bytes from file main.elf in 1.671886s (9.570 KiB/s)
verified 804 bytes in 0.421878s (1.861 KiB/s)
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
shutdown command invokedwrote 16384 bytes from file main.elf in 2.046889s (7.817 KiB/s)
だったのが
wrote 16384 bytes from file main.elf in 1.671886s (9.570 KiB/s)
と結構改善してます。比較元のサイズが小さいので分かりにくいですが、バイナリの
サイズがさらに大きくなると違いがさらに出てくることでしょう。
もちろんこちらにも反映済みです。
●毎年恒例の電源ラインは大丈夫か？
※使用したもの
・PCのUSBポート
・Interface2012年6月号付録のFM3マイコン基板(LED点滅書き込み済み)
・5mのUSBA-miniBケーブル+1mのUSB延長ケーブル
・テクトロのオシロ
※USBコネクタを指してPCのUSBポートから+5V電源を供給した時の+5Vラインと
レギュレータ出力の+3.3Vラインの電圧波形を見る
+3.3vの立ち上がり時に+5Vラインが一瞬突入で1Vほどドロップしてるけど
以前みたく上に跳ねてはいないので基板単体で見たら大丈夫だ、問題無い。
※144MHzで動作中の時の+5Vラインと+3.3Vラインの電圧波形を見る
大丈夫だ、問題無い。
※USBコネクタをPCのUSBポートから引き抜いて+5V電源を断った時の+5Vラインと
レギュレータ出力の+3.3Vラインの電圧波形を見る
大丈夫だ、問題無い。
※総評
大丈夫だ、問題無い(イーノックみたいな顔で)
…ってねむいさんが太鼓判押したら大抵悪いこと起きるんですよね〜
いろいろ試す11
●STM32L-Discovery
少し前に秋月さんからSTM32L-Discoveryが販売されましたが、遅ればせながら私も
入手しました！
これでDiscovery系のボードもほとんど手に入れましたね。
さて、いつもなら即座にVersaloonに改造するのですが、2012年に入ってからOpenOCD
の0.6.0系のサポートにSTLink・STLink/V2が加わっています。
しかも生SWD対応です！
去年まではSWDでCorex-Mx系のマイコンに書き込みデバッグするまでがかなりしんどい
方法しかなく(一度コツつかんだら後はスクリプト組んじゃえば楽勝なんですが…)、
皆さん華麗にスルーされてきましたがメーカーやサードパーティの有償のツールを使う
ことなく使い慣れたOpenOCDを利用できるようになりました。
↑STM32L-Discovery(STM32L152RBT6)にOpenOCDで書き込みしてるとこです。
書き込み用のスクリプトはいつもの場所に最新の物をまとめてあります。現在動作確認
してるのは今回のSTM32L-DiscoveryとSTM32F4-Discoveryです。
STLinkやVersaloon(SWD接続)対応のOpenOCDはこちらに。
↑デバッグも自由自在です♥OpenOCDはSTLinkのAPIを呼びだすことで通信を
成立させているようです。MLを追っていくと対応に当たってOpenOCDのdevの人たち
の苦心の様子がうかがわれます。
2013年現在はOpenOCDからSTLink/v2を動かすドライバとして、STマイクロ提供の
純正ドライバが利用できます(といっても中身はWinUSBですが)。
●ほっぽらかしていたBeagleBoard達
去年争奪戦に勝利したにもかかわらず購入した時点で満足して箱に納めてしまってい
たねむいさんですが、aitendoさんの液晶キットを購入したことを皮切りに少しずつ
手をつけ始めています。
↑せっかく奮発してHDMIケーブル買ったのに一旦DVIコネクタ咬ませて変換しとかない
とこの構成だとまともに写らんなんて考慮しとらんよ…orz
副業先のPCのでかくて新しいモニタ使わせてもらいますか…無駄に2980円がががｇ
ぁーでもS端子使うって手もありますね。
↑去年末にBeagleBoneなるさらに機能を絞ったBeagleBoardの仲間が誕生しました！
今流行りのクラウド環境を意識したモノになっていてArduinoからの置き換えを狙った
プロトタイピングに特化した作りとなっているようです。
こちらの導入記は現在まとめていますのでまた次の機会に詳しく述べたいと思います。
●モノクロドットマトリクスSTN液晶
皆さんは去年さらっと紹介した2.5元I2C液晶を覚えているでしょうか？
あの後詳細が判明した途端に5元に跳ね上がりやがりましたが、ねむいさんは
基本的な動作確認を終えシンプルi2cライブラリに加えようと画策していました。
しかし、Nokia5110に代表されるドットマトリクス方式のモノクロ液晶は動かし方が
ほとんど同じことが分かったので、私がTFTでやってるのと同様に汎用のドットマトリ
クスモノクロSTN液晶向けのライブラリを現在作っています。aitendoさんで購入で
きる一部のOLEDも同じ動作方法の物があり、こちらに組み込んでます。
こちらもまとまり次第別記事で詳しくお伝えします。Nokia5110以外のマイナーな
モジュールに関する動作方法のテクニックも同時にお伝えしますね。
↑てわけで自作ライブラリで別の5元のOLEDを駆動。
…これ焼きつき激しすぎです！
●一個忘れてました
STM32系のOpenOCDのフラッシュ書き込みルーチンで現在テスト段階なのですが、
asynchronous algorithmと言うものに換えると書き込み速度がアップするそうです。
20120226追:
公式のコミットにも来たわよ
実際にこのパッチを取りこんで試してみました。
デバッガハードウエアはJtagkey2を使ってますが、ボトルネックがフラッシュ
書き込みにあるのでSWD接続のVersaloonでも変わりません。
*Normal
> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jtagkey2.cfg -f target/stm32f4x_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00415-g338f5a1-dirty (2012-02-16-10:16)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
1000 kHz
DEPRECATED! use 'adapter_nsrst_delay' not 'jtag_nsrst_delay'
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
3750 kHz
verify Capture-IR is disabled
Info : device: 6 "2232H"
Info : deviceID: 67358712
Info : SerialNumber: 22222222A
Info : Description: Amontec JTAGkey-2 A
Info : max TCK change to: 30000 kHz
Info : clock speed 3750 kHz
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08031280 msp: 0x10010000
auto erase enabled
Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE
Info : device id = 0x10006413
Info : flash size = 1024kbytes
wrote 524288 bytes from file main.elf in 19.750000s (25.924 KiB/s)
verified 454868 bytes in 4.062500s (109.343 KiB/s)
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
shutdown command invoked*asynchronous algorithm
> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jtagkey2.cfg -f target/stm32f4x_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00423-gd8b9127-dirty (2012-02-17-21:45)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
1000 kHz
DEPRECATED! use 'adapter_nsrst_delay' not 'jtag_nsrst_delay'
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
3750 kHz
verify Capture-IR is disabled
Info : device: 6 "2232H"
Info : deviceID: 67358712
Info : SerialNumber: 22222222A
Info : Description: Amontec JTAGkey-2 A
Info : max TCK change to: 30000 kHz
Info : clock speed 3750 kHz
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08031440 msp: 0x10010000
auto erase enabled
Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE
Info : device id = 0x10006413
Info : flash size = 1024kbytes
wrote 524288 bytes from file main.elf in 12.968750s (39.480 KiB/s)
verified 454868 bytes in 4.015625s (110.620 KiB/s)
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
shutdown command invoked…てわけで25.924 KiB/sから39.480 KiB/sへの大幅アップです！なにこれすごい。
現時点で書き込み速度がRTCK使っても10KiB/s代しか出ないLPC1769系のフラッシュ
にも対応してほしいですね♥
いろいろ試す9
電子工作系のブログ記事はこれが今年で最後なので旅先から無理やり更新して
やります。明日(12/30)のAM6:30には犬山遊園に降り立ってる身です・・・‼
さて、クリスマスは虹裏向けのネタの仕込みで死にそうになってたねむいさん
でしたがaitendoさんからよさげなTFT液晶モジュールが2点追加されていましたのを
目ざとく見つけ購入だけはしていました。
今週に入ってやっとこ作業時間ができたので即効バラックをくみ上げて動作させて
見ました。
まずは320x480の解像度でなおかつタッチパネルが付いているTRULY製のTFT液晶
モジュールTFT1P2797-Eです。以前も同じコントローラIC(ILI9481)で解像度が
同じものを売っていましたが、これはタッチパネル付きで、この解像度では
taobaoでもなかなかお目に掛からない一品です。
↑早速動かしてみました。
電源電圧は3.3V単一でまったく問題ありません。よく液晶モジュールの
データシートでは慣習的に2.85VをtypとしていますがコントローラICのVioとVccが
3.3Vを許容していればなんら問題はないです。F4用の液晶はこれで決まりです！
･･･といいたいところですが、この液晶は以前のものとは違ってノーマリホワイトの
ようなので初期化手順が微妙に違います。ご注意を。
お次はお値段500円と非常にリーズナブルな液晶モジュールS95591-AAAです。
こういう2.2"でQVGAでタッチパネルつきはなかなかtaobaoでもお目にかかりません。
aitendoさんやりますね〜！
↑こっちも早速動かしてみました。
こちらはLEDのバックライト電圧が9Vとなっています。3.3Vから昇圧して定電流回路
組んでやりましょう。私はPowTech社のPT4101というLEDドライバICをよく使用して
いてこのバラックでも秋月さんの変換基板と組み合わせて使用しています。
最後にSTM32VL DiscoveryのVersaloon化について、最近のファームウェアは
SWDとして使うためのピン配置があべこべだったのが元の正しい形?に戻っています。
私のぶろぐを参考にSTM32VLDiscoveryをVersaloon化されてる方は注意してください。
↑私も久しぶりファーム変えて気づかないではまった･･･
以前と同じこと言ってる気がしますが春日井から戻ったら手順書も更新します。
てわけで去年とまったく同じことしかやらないまま今年の電子工作納めて
しまいました。
･･･
さて、尺があまってしまったのでよくメールなどで頻繁に頂く質問、いわゆる
FAQをこの場を借りて答えたいとおもいます。
＞メカトロ(含むロボット関連の競技)で使うモータドライバを組むことに
なりましたがお勧めのFETを教えてください
・・・など、モータ制御に関する質問
→これなぜか非常に良く聞かれるのですが副業の仕事内容的にモータドライバに
関する質問は｢私ぜんっぜんわかりません＞＜」としか答えられません･･･
なんせ私は1聞かれたら100答える人間でなおかつぶろぐのこと副業先の方々が
皆知ってて変なこと書かないように監視されてますから･･･
ちなみに本業の虹メに関してはやりたい放題に見えて実ははるかに
恐ろしいくらい厳しいガイドラインがあって政治・経済・野球・サッカー・
アニメ・漫画・特撮・絵師さん個人の話題そしてジャガイモの入ったカレーなど
個人の嗜好が大きく分かれる事がらの話はタブーなっています。
とくに｢｣の前ではジャガイモの入ったカレーの話題は絵師さんに絵を描くことを
強要する行為と同じくらいタブー中のタブーにあたります。
私的にはいないさんのぱんつのつぎにじゃがいも入りの野菜カレー大好物なんですけぉ･･･
すみません話反れました･･･
＞(任意のマイコン)からARMに乗り換えましたがGPIOのスピードが遅いのですが
→｢最適化｣「吐かれたアセンブラリストを良く見直して無駄な分岐・ロード・ストアが
出ないようにGPIOアクセスする部分のコードを組みなおす｣
それとCPUコアが100MHz以上で動いててもGPIOがそのスピードについてけるとは
限りませんからよくマニュアル(ARM本家の仕様書も)やデータシート穴の開くほど
読んでください。
それをマスターしたら君もGPIO高速パタパタで大空に羽ばたくことができる！！
そしてもうこんなところに戻ってくんなよー！！！１！
＞中華の電気電子系の掲示板からよくネタをパクってますよね
→はい
私の描いたJTAGKey2Cloneの回路図とかあっちで貼られてることがあったりして
面白い発見も…！
＞なんでトレイルランのはずなのに徒歩とあんまり早さが変わらないの？
→途中から疲れて歩いてるからです
＞GT-723Fを使っています。ちゃんとつないだはずなのに衛星を補足しません＞＜
→表出ろ(別にけんかするわけではない)。部屋の中では補足はほぼ不可能ですよ。
特に最近のマンションは金属線が埋め込まれた窓のガラスなのでそれがシールドに
なって外部からの電波がシャットアウトされてしまいます。
Bluetoothの電波とかももちろんダメ･･･
＞GT-723FからUARTのメッセージがまったく吐かれなくなってしまいました
→お気の毒ですが壊れました
LVTTLなI/OラインにCMOSな+5V系の信号ぶちかますと簡単に死にます。
+5Vで動かしてるAVR等と組み合わせるときは注意です。あと落下のショックにも
弱いです。静電気にもメタクソ弱いです。
ねむいさんは安価ゆえにとっかえが効いて性能の非常に高いPA6Cをお勧めします！
ユーロ安の今がチャンス！！！
＞Cortex-M3でOpenOCDデバッグしようとすると
"Remote 'g' packet reply is too long"というメッセージが出て(ry
→もうねむいさん何十回も言ってるのですが･･･＃
次これ聞いたら頭にJTAGKey2ぶっ挿して1ビットずつ焼きこんでいきますからね！
＞ねむいさんってマミゾウのパクリだよね
→そうだね
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忘れてしまわないうちに
何とかしたいですはい･･･
Windows10対応軽量シンプルな環境でARMマイコンをInsightとOpenOCDを使ってデバッグする(2020年度版)
20230711追記！！！
GCC12でビルドされたelfファイルは下記のinsightを使った
方法ではスムーズにデバッグできません！！
現在GDB+CodeLiteによる新しい時代に即したデバッグ
手順を作成しておりますので完成まで今しばらく、
いましばらくお待ちくださいませ！！！１１！！
OpenOCD for Windows is HERE!
↑ねむいさんは自前ビルドのOpenOCDバイナリ公開してます。
解説はこのバイナリを基にすすめますので4649!
この記事は前回からの続きです。前回のものよりちょっと内容が難しくなってます。
前回の内容を基に環境を構築していることが前提で話を進めさせていただきます。
今回はOpenOCDを使用し実際にARMマイコンにJTAG/SWD経由でフラッシュ書き込み
そしてデバッグを行うところまでいきます。
もちろん今回も軽量動作,NO-Eclipse,NO-Cygwinです。
※今回の記事も時代に合わせて適宜加筆修正していきます。
●必要なもの
1.ARMマイコンが実装されたターゲットボード
凡例として、STM32F4シリーズであるSTM32F4Discoveryを使用します。
私が配布しているSTM32F4向けのFatFs移植例は、デフォルトのターゲットボードが
STM32F4Discovery、デバッガハードウエアがSTLink/V2となっています。
Nucleo系板や2015年以降発売のDiscovery系板はSTLink/V2-1に変ってます。
↑とりあえず何も編集しなくてもよくなってます。
2.JTAG/SWDデバッガハードウエア
上記のCortex-M4はデバッグユニットとしてJTAGとSWDという接続方式の両方を
サポートしています。ARM7TDMIはJTAGインターフェースのみでした。
現在、ホビーユーザーが手軽に利用できるものとしてFT2232系を使ったJTAG
デバイスが主流です。
以後の解説はそれを利用したJTAGKey2互換の"JTAGKey2 Compatible"
を使用しJTAG接続にて解説していきます。
JTAGKey2 Comatibleを自作される方はこちらの解説を参考に。
SWD接続についてはCMSIS-DAPが現在の主流となっています。
NxP系の評価ボードにはmbed版としてデフォルトで搭載されているので
もはやおなじみだと思います。
その他の品種ではVersaloonや上記のJTAGKey2CompatibleでもSWD接続可能に
なっています。
2023年現在はCortex-M系マイコンが主流となり、SWD接続がデファクト・
スタンダードなっております。
3.OpenOCD
OpenOCDはターゲットMCU(ARMマイコン)と後述するgdb/insightの仲介役を
果たすフラッシュ書き込み機能を持ったサーバープログラムです。
ねむいさん謹製のビルド済みバイナリを用意しておりますので、
OpenOCDのWindowsバイナリはこちらからダウンロードしてください。
注意すべきはデバッガハードウエアに対するドライバで、上記リンクに
あるOpenOCDバイナリは下記のデバイスとドライバをサポートしています。
*JTAGKey2をはじめとしたFT2232系デバイス:(WinUSB)
*Versaloon:(WinUSB)
*STLink/v2:(STMicro純正/WinUSB)
*TI-ICDI(Stellaris Launchpad):(TI純正/WinUSB)
*J-Link(WinUSB)
*J-Link On LPCLink2(WinUSB)
*CMSIS-DAP(HIDとしてドライバレスだがmbed版はVCPドライバ必須)
*STLink/V2-1(VCPドライバ必須)
各ドライバのインストールは以前は、PID/VID調べてINFファイルを作って
…と非常にめんどくさかったのですが、現在はWinUSB向けのGUIな汎用
インストーラのzadigを使用することによりインストールが大幅に簡略化され、
手軽になりましたのでzadigでインストールを行ってください。
公式のサイトにはインストール手順も英文で懇切丁寧に書かれていますが
見る必要も無いくらい簡単にWinUSBが導入可能です。
注：このOpenOCDは32bit版ですが64bit版Windows環境でも問題なく動作します。
64bit版OpenOCDと比べて速度的な面で大差はないです。
ARMは新旧の情報がweb上のいたるところで倒錯しすぎて何が正しい組み合わせか
分からないと思います。Windows環境でOpenOCDを使われる方は私のぶろぐを
しっかり見ていただければ途方に暮れることだけは避けられるかと思います。
４．Insight(gdb-gui)
InsightはgdbのGUI版です。また、純粋なフロントエンドではなく内部にGDB
そのものが取り込まれているので別途gdb.exeを用意する必要はありません。
当ぶろぐではこれを使用しソースコードレベルのデバッグを行います。
これも詳細は後述しますがバイナリが配布されていますのでビルドする必要は
ありません。
●下準備
１．OpenOCDの準備
かつてWindows環境にてMSYS/MinGWを用いた手順を公開しておりましたが、
OpnOCD0.8.0以降はビルドするまでの手順が大幅に煩雑になり慣れてない
人にはビルドがほぼ不可能になってしまいましたので公開を廃止しました。
代わりとしましてビルド済のWindowsバイナリを公開しております。
ご利用ください。インストール箇所は前回のビルド環境構築手順に倣い、
C:/devz/arm/ocdにあるものとします。
２．Insightの準備
SourceForgeにあるNetXのページのかなり下のほうにある
"arm-none-eabi-insight-7.4.50.20111222-cvs-mingw32-netx.0.7z"を
ダウンロードし、任意のフォルダに展開してください。
こちらもC:/devz/arm/insight/binにあるものとします。
●ターゲットデバイスにプログラムをダウンロード
前回の手順を参考にSTM32F4-Discovery用のmain.elfが作成されたものとします。
デバッグ時は最適化オプションを必ず"-O0"にしてビルドしてください。
１．makeファイルの編集
前回も解説しましたが、makefileにあるOpenOCDとInsightがインストール
されているパスを指定してください。
Insightの引数は下図下段の要領で"--eval-command"で渡すように記述します。
Insight起動後のTargetの設定は一切不要です。引数の内訳は以下の通り
--eval-command="target remote localhost:3333"
-> TCP3333番ポートに接続
--eval-command="tbreak main"
-> 接続後main関数の先頭で一時停止
-nx
-> .gdbinitを作成しない&内容無視
２．PN2の設定
PN2の"TOOL"から呼び出すことが出来るように前回と同じ要領で引数つきで登録し
てください。登録するのは"program"と"debug"です。
３．書き込み
"TOOL"から"make program"を呼び出し、OpenOCDからSTM32のフラッシュ
書き込みスクリプトを呼び出しターゲットデバイスに"main.elf"を
ダウンロードします。
OpenOCDのcfgファイルのパスの指定が間違っているとエラーが出ますので
各自の環境に合わせてパスを修正してください。
４．フラッシュ書き込み用のコマンドについて補足
makefile内では以下のように記述されています。
1.OpenOCDをJTAG・SWDデバイスのcfgファイル・ターゲットMCUのcfg
ファイルを"-f"コマンドで指定して起動する。
2.同時に-cのコマンドでターゲットMCUのcfgに記述されているproc(関数)
を呼び出す。
3.procに記載されている順にコマンドが実行されフラッシュ書き込みを行う。
上記一連の動作にてgdbやtelnetからの回りくどい操作は一切要せず、簡単に
フラッシュの書き込み動作が可能です。
●ターゲットデバイスをInsightを使用しデバッグ
１．makeファイルの編集
正しくプログラムが書き込まれたことを確認したら次はデバッグです。
makeでOpenOCDとInsightを同時起動するためにちょっと工夫を凝らしています。
先に定義したディレクトリパスやコマンドを下記のように配置して、
クリック一発で呼び出しできるようにします。
２．OpenOCD・Insightの起動と接続
"TOOL"から"make debug"を呼び出すと、OpenOCDがターゲットMCUに接続、
その後Insightが起動します。
さらにOpenOCDとInsightのTCP接続まで一気に進み画像のようになれば成功です。
ここで注意ですがWin10ではInsightのメニューにあるTarget Settings関連を
いじるとInsightが固まってしまい動作不能になるため絶対に
触らないでください！
この状態で"Continue"を押すとmain関数の最初の行、一時的にmain()に張った
ブレークポイント(main()の最初の行)に飛びます。このブレークポイントは
一時的なものですぐに消えるのでリソースの無駄にもなりません。
ここまできたらあとはInsight上でステップインとかステップアウトとか
ブレークポイント張って停止させたりレジスタとかメモリとか(条件付で)
I/Oレジスタの値読み出したり自由自在です！
また、デバッグ時の重大な注意ですが、Win10ではInsightのレジスタ
ウインドウを開くと100%落ちてしまいますので面倒くさいですがコマンド
ウインドウから"monitor reg"でMCUの各レジスタを参照するようにしてください。
３．デバッグの終了
終了する時はTools->Stop Toolsで終了させたいところですがが、PN2では
ひとつのプログラムしか終了できず、Insightだけが終了してOpenOCDが
終了してくれません。
私は下記の要領で強制的にタスクを殺すwindowsのtaskkillコマンドを使った
バッチファイルを作成してこれを呼び出して"確実に"終了させています。
↓この呪文をバッチファイルにしてwindowsフォルダに突っ込んで
おきましょう。
taskkill /F /IM openocd.exe
taskkill /F /IM arm-none-eabi-insight.exe
Windows10対応軽量シンプルなARMマイコンのGCCビルド環境を構築する(2020年度版)
OpenOCD for Windows is HERE!
↑ねむいさんは自前ビルドのOpenOCDバイナリ公開してます。
解説はこのバイナリを基にすすめますので4649!
当記事はWindows環境下におけるARMマイコンの開発環境構築を目指してはおりますが
私が公開しているプロジェクトをビルド/デバッグするために必要な最小限の手順の
指南という位置づけです。
はっきり言いますが初学者向きの解説ではありません。専門的な語句の意味や
GNUMakeを駆使したコマンドラインビルドの方法を熟知している前提で話を進めます。
2019年現在は無料のEclipseベースの開発環境GNUARMECLIPSE、
STM32限定でフル機能が使えるAtollic TrueStudioとMDK-ARMの2品種、
そしてオンラインコンパイラ+ライブラリ等の強力なサポートがあるmbedとかが
充実しており、一般的な事柄を学びたい初学者の方にはそちらを強くお勧めいたします。
ちなみにねむいさんはメーカサポートが無い素のEclipseを使うと｢あわびゅ！｣と
叫びながら全身から血を吹き出して死ぬ奇病に罹っていて、且つCygwinを使うと
バストサイズが強制的に20cm減のマイナス補正を喰らい(=フラットなB(Breasts)特性
を持ついないさんと同レベルに堕ちてしまい）虹裏メイドねむいさんとしての
あいでんてぃてぃを完全に失ってしまうため、当ぶろぐでは絶対に扱いません。
※要注意※
ツール群の盛衰や時勢により時々刻々と本記事の内容は変化していきます!
●必要なもの
１．ARM用GCCコンパイラ
とにもかくにもまずはこれです。
現在はLaunchpad.netが提供し、ARM本家から配布されている
GNU Tools for ARM Embedded Processors
を強くお勧めします。表向きCortex-Mx向けとなっておりますが、LPC2388等の
ARM7TDMIもしっかりサポートしており古い品種でも問題なくビルドが可能です。
今回の手順ではダウンロードした上記コンパイラをC:/Devz/ARM/launchpad
直下に解凍するものとします。解凍後launchpadフォルダには
arm-none-eabi,bin,share,libの4つのフォルダがあるのが正解です。
Windows環境下で動くARM用GCCコンパイラとして、Bleeding Edge Toolchain
なんかもあります。いずれもABIはEABIで2015年以降流通している
最新のGCCコンパイラはもはやすべてEABIとなっています。
２．サポートツール群
ねむいさんが公開しているプログラムはコマンドラインビルドを想定しています。
IDE全盛の昨今は古臭いものとなってしまいましたがmakeコマンドでビルドする
というベタベタなクラシックな手法を敢えてとっています。
makeの他にunixコマンドのechoやrmなどを用いているので、これらのunix
ライクなコマンドをネイティブなWindows環境下で動かすことができる
Coreutilsを使用します。
a.Coreutils本体
有志の方々が作成されたCoreutilsの"Binaries"のリンク先をダウンロードし、
2バイト文字やスペースを含まない任意のフォルダに解凍してください。
b.GNUMake3.81
次にGNUMakeを同様にダウンロードしたあと解凍しCoreutilsを解凍した
場所と同じフォルダに置いてください。
c.サポートDLL群
最後にmakeをダウンロードしたページの下にある"dependencies zip file
(中身はlibintl3とlibiconv2)"をダウンロードしGNUMakeと同様の処置を
してください。
今回の手順では上記3点がすべてC:/Devz/Coreutils/bin内にあるものとします。
このbinフォルダ内にmake,echo,rm等のunixライクコマンドとdepedenciesの
libintl3.dll,libiconv2.dllが存在していることを必ず確認して進めてください。
ここで間違ってると下述のPN2からmakeを呼び出す段階でコケて失敗します。
よくやる間違いが、最初のCoreutilsを解凍して出てくるbinフォルダの中に
さらにmakeやdepedenciesの入ったbinフォルダを置いてしまうことです。
C:/Devz↑ねむいさんは上記のディレクトリ構造にしています。
├ARM
|└launchpad
| └bin (←GCCコンパイラのバイナリがある場所)
|└ocd(←openocd.exeのある場所)
└Coreutils
└bin (←make他unixライクコマンド群のある場所)
以下この構成で話を進めます。
ちなみにAVRToolChainでもARMと同じような感じのディレクトリ構成にすると、
同じ感じでコマンドラインビルドが出来ますのでおすすめです。
※以前はWinAVRのutils配下にあった同様のファイル群の使用を推奨していましたが、
WinAVRは開発が停止し数年経ち、フリーで利用できるAVRToolchainに主流が移行
したのでもう一切使用しませんし使ってはいけません。
２.５．sh.exeが見つかりません対策(必ずしも必要ではない)
ネット上で手に入るARMマイコンのGCCプロジェクトの中ではWinAVRのmakefileを
ベースにしたものがいくつか存在し、そこにはshell関数などのbashに依存した記述が
数か所あります。この記述が含まれているとまともにビルドができません。
当ぶろぐで公開してるプロジェクトはmakefileからbash(/bin/sh)に依存して
いる記述はすべて排しておりますが、他の方のプロジェクトをビルドする際の
回避措置として紹介します。
こちらからwin-bash.zipをダウンロードし、解凍して出てきたwin-bash.exeを
Coreutilsのbinフォルダに突っ込んでください。次にmakefile ファイル中に
記載されているはずのSHELLの設定を以下のように書き換えてください。
SHELL = sh
↓
SHELL = win-bash.exe
bash.exeは自身のファイル名によって特殊な動きをするので横着してwin-bash.exeの
方をsh.exeとリネームしてしまうと逆にビルドが通らなくなります。ご注意ください。
３．エディタ
メモ帳でｾｺｾｺ編集してコマンドプロンプトからmakeを実行してもいいですけど
makeを引数つきで呼び出せられるエディタを使えばIDEのように使えます！
ねむいさんのお勧めはProgrammers Notepad2(PN2)です。素のEclipseは(ry
ビルド時の解説はこのPN2を使用して解説します。
注：必ずStable2.3以降を使用してください。
また、日本語入力に対応するために下記の要領で多バイト文字の設定を
”Shift-JIS”に変更しておいてください。
それとPN2のインストール先は無用なトラブルを避けるためスペースや2バイト
文字が混ざるディレクトリは避けてください。
４．デバッガソフトウエア&ハードウエア
ARM用のデバッガはホビーユーザーご用達のGDBサーバであるOpenOCDを
使用します。次回の記事で使用法を紹介します。
また、MCUとJTAG/SWDで通信するハードウエアはFTDIのFT2232系JTAG-I/Fを
使用するのが私の中でスタンダードになっています。
これらに関しても次回詳しく紹介します。
●下準備とビルド
※以後はエディタとしてPN2をインストールして使うことを想定して解説します。
１．ソースコードの展開
今回の凡例として、STM32F4向けの液晶表示プログラムをダウンロードして
ローカルに落としたzipファイルをローカルフォルダに展開します。
このときディレクトリパス(アドレス)にスペースや２バイト文字が絶対に
入らないようにしてください。
２．makeファイルの編集
PN2がインストールされている場合、拡張子pnprojのアイコンをダブルクリック
すると下のような画面になると思います。"makefile"をクリックしてmakefileの
編集画面を出しましょう。
OpenOCDとarm-none-eabiのファイル名は特殊なことをやらない限りは
もう変えないようにしてください。
下画像の要領でそれぞれの環境に合わせてARM用GCCコンパイラ、サポートツール
群、デバッガのディレクトリパスを設定していきます。パスの区切りは"¥"
ではなく"/"を使用してください。
ディレクトリパスはスペースや２バイト文字が絶対に入らないように
してください。大事なことなので二度言います!!
makefileの書き方の作法は此処では解説しないので
各自詳細は調べて下さい。
３．PN2の設定
PN2をインストールしたての人は、makeコマンドをPN2の"TOOL"から
呼び出すことが出来るように以下の要領でmakeコマンドを引数"all"
つきで登録してください。
その後、"build","clean"の引数についても同様に登録してください。
重要：Windows環境変数のPATHは設定する必要はありません！
下手に設定しているとビルドが通らなくなることがあるのでご注意ください。
４．ビルド開始
デフォルトでは評価ボードの設定はSTM32F4Discovery向けになっています。
また、各評価ボード設定時の各ピン配置を知りたい場合は同梱のdoc/Boards.txtを
参照してください。
設定が終わったら"Tool"から"make all"を呼び出しビルド開始です。
ビルドが完了したらメモリ使用量などの情報がコンソール上に現れます。
もしコンパイルエラーなどが発生しビルドが止まったら赤色で強調表示されるので
エラー箇所の特定も簡単です。
上記の液晶表示プログラムはデフォで下記のライブラリ/ドライバを
有効にしてます。
-libjpeg
-libpng
-giflib
-FONTX2ドライバ
-抵抗膜式/容量性タッチパネルドライバ(特定のボード限定)
-HelixMP3デコーダ(特定のボード限定)
-HelixHE-AACデコーダ(特定のボード限定)
数分ほど時間がかかります。Warningが出ますがビルド時の設定喚起の
ためにソースコード中に"#warning"プリプロセッサを敢えて入れてる箇所が
いくつかありますので気にしないでください。
エラーが出てビルドが止まった場合は各種設定を見直しましょう。殆どの場合、
makefile中でPATHの設定を誤っています。
ちなみに"make all"はコンパイルしたオブジェクトを全部消してまっさらに
してからビルド、"make build"はすでにオブジェクト吐かれたソースはスルー
してビルド(ソースコードを一部書き換えてカット&トライしたいときに最適)です。
"make clean"はその名のとおり生成されたelfやhexファイル含めてアセンブラ
リストファイルやオブジェクトをまるっと消去してしまいます。
お次はターゲットCPUへの書き込み&デバッグですが…次回に続きます。
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さんもこういうの見習ったらｲｲﾅｰ
･･･絶対ありえないですが…
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作ってみたいなんて方はねむいさんに連絡ください。
mbedとかLPCXPresso1768版とか超楽しそうスね(涙目)
TFT-LCD Shieldの開発に当たって、ねむいさんもついにArduinoを購入しました！
最初はEtherpodのプラットフォームだけで動かすことしか考えてませんでしたが、
HP200LX持ってないのにmorphyone作ろうとして盛大にコけたどこぞのぺ○野郎のこと
が頭よぎったので、ちゃんとArduinoを理解してライブラリも作れるようになるために
購入しました…。まぁSTM32ですでにできたことをAVRに移すだけですから驚くほど
簡･･･た…
ごめんもう白旗上げていいかな…(※xmegaの二の舞)
ところでxmegaで思い出しましたがxmegaでFatFS(のMSPI)をDMA化出来たという話を
全く聞きません。情報もってる人がいたら教えてください…
20120907追:
xmegaでFatFsのDMA化できるじゃない！
さて、前フリはこれくらいにしといて本題に入りますが、Cortex-M3の系統の
ARMマイコン、LPC1768を使用したハイエンドかつ安価な評価ボードがいくつか
出ています。
mbedやLPCXpresso(LPC1768版)等がそれに当たりますが、ねむいさんはそれの
どれにも手をつけず、taobaoで液晶買った時についでに中華LPC1768ボードを
買っていたのでした！！
↑のLPCXpresso1768版出るなんて知ってたら買ってなかったのですが…
くやしい…でも…
過ぎたことは仕方ないので私も通電してみることにしました。
↑KeilのMCB1700互換なミニボードだそうです。周辺が全くない代わりに
ほぼすべてのI/Oが外部に引き出されています。
↑即LPC1769に交換ッッ！！１!LPC1768を凌駕する120MHzで動きますッ！
恐らく私が日本国内で初めてLPC1769を動かした女になるでしょう(多分)
R&D dailyの綿谷氏がとうの昔にされていましたorz生意気言ってごめんなさいッ
マイクロマウスの開発されている方たちはなんとうか本当に格が違いますね…
さて、基本の'き'であるLED点滅から始めてみたいと思いますが、上述のとおり
MCB1700互換なので、NxPのサイトにある、
"LPC17xx CMSIS-Compliant Standard Peripheral Firmware Driver Library (GNU, Keil, IAR)"
というExample付きのCMSISライブラリがそっくりそのまま使えます。
GNU用のExampleはこれまたCodeSourceryの使用を前提にされていて、
ねむいさん的にも好都合です。手順に従い、程なくバイナリを生成出来ました。
バイナリの書き込みはもちろんJTAGKey2Clone+OpenOCDから行います。
LPC17xx系統の対応状況は現在JTAG接続のみです。NxP製のARMマイコン特有の
CheckSumValidationに注意してスクリプトファイルを作り、JTAG接続にて書き
込みました。書き込みの過程はこんな感じです。
↓
> "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey2.cfg -f C:/Devz/ARM/OCD/tcl/target/lpc1769_rclk_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.5.0-dev-00450-g450aaad (2010-07-22-09:39)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter_nsrst_delay: 200
jtag_ntrst_delay: 200
none srst_pulls_trst
500 kHz
Info : device: 6 "2232H"
Info : deviceID: 67358712
Info : SerialNumber: 22222222A
Info : Description: Amontec JTAGkey-2 A
Info : max TCK change to: 30000 kHz
Info : clock speed 500 kHz
Info : JTAG tap: lpc1769.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : lpc1769.cpu: hardware has 6 breakpoints, 4 watchpoints
RCLK - adaptive
Info : JTAG tap: lpc1769.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc
flash 'lpc2000' found at 0x00000000
auto erase enabled
wrote 8192 bytes from file main.elf in 1.328142s (6.023 KiB/s)
verified 4968 bytes in 0.531257s (9.132 KiB/s)
requesting target halt and executing a soft reset
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x01000000 pc: 0x000000e0 msp: 0x10007fe0
shutdown command invoked
現状LPC17xx系のアーキテクチャのすべてを理解はしていないのでLPC2388
みたく高速書き込み/ベリファイはまだ出来ませんが、そちらも使い込むに
つれ対応していきます。
↑LED点滅プログラムが動いてるところ。
↑JTAGkey2Clone+OpenOCD+Insightでのデバッグも自在です。
↑NxP提供のCMSISのExampleはLPC1768向けになっており、
それをそのままビルドしているので,動作周波数はまだ100MHzです。
まぁつかみはこんな感じでしょうか。私が行った最初のとっかかりのプログラムを
自分用環境に移植したものを
置いておきます。ご利用は自己責任で〜
おまけ
じっと見てたら気づいたけど何かに似てる…
LPCXpresso(LPC1114)はぢめました
20120130追：
OpenOCDで書き込みとデバッグできるようになったから熟読すべし
なんてうかうかしてるうちにXpressoのLPC1768版登場ですって奥さん！ねむいさんは
中華製1768ボードを買ってしまいましたので今すげぇ涙目です！！！
(でもいいんだ、こっちの方が自由度あるし！！全然負け惜しみじゃないし)
さて、LPC1768の件も語ることが多いので次回にゆだねるとして、今回は巷で流行りの
LPCXPressoを使用してみました。今回はLPC1114版の方を使用します。
まずは環境作りなんですが、いつもの通りCodeRedが提供しているEclipseベースのIDE
はガン無視でコマンドラインからのビルド環境を構築しました。
構築にあたりtodotani氏、Lynx-EyED氏、microBuilder.euほかのページを参考にさせてもらいました。
構築と言ってもやってることはLPC2388やSTM32でやってたことと全く同一で、リンカ
スクリプトとスタートアップコードをLPC1114用にこさえるだけです。Cortex-M0も
CMSISライブラリが提供されていてSTM32のものと似たような構成にすれば間違いなく
正しく初期化し、動作するものを作ることができます。
私はさらにこれに加えてNxP製のARMマイコンに特有のCRPのセクションを追加
しました。
(まだありますけど後述)普段は使用しないのですが万が一のこと考えてです。
CRP無効にしていますがもちろん他のプロテクションレベルにもできます。
親切心を装って"とりあえずこのプログラム書き込んで試してみて"なんてCRPLevel3
の地雷を故意に仕込むことも可能なのでとてもお勧めですが絶対にやってはいけません！
んでもってLPCXpressoのIDEに同梱されていたLED点滅のサンプルをビルドし、
書き込みます。
書き込みの際にはLPCLinkではなくてSTM8S-DiscoveryのST-LINK部分を
改造したVersaloonを使用してみました。
なんと少し前にLPC1xxxシリーズもSWD接続・フラッシュ書き込み対応に
なっています！！
…でもまだちょっと不安定。さらなる改善を期待します。
LPC2388で経験されている方も多いでしょうが、大切なことなので2度言いますが
NxP製ARMマイコン書き込みの際に注意しなければならないのは電源投入->リセット後
必ず実行されるビルドインされたブートローダによるVectorCheckSumチェックです。
これはどういうものかというと特定のアドレスまでの(大抵はVector領域)の
チェックサムをとった値とさらに別の特定のアドレスの値をたして0に
(2の補数をとる)ならなかった場合、フラッシュ上のユーザプログラムを
実行せず強制的にISPのアドレスにすっ飛ぶという仕組み。
(これにCRPも絡みますが細かいことは各自UserManualで確認のこと)
OpenOCD等でLPC系のARMマイコンのcfgファイルに"calc_checksum"と言う単語が
あるのはそのためです。calc_checksumを有効にしているとフラッシュの書き込み
アルゴリズムの中でVector領域のチェックサムの2の補数を取った数がLPC2388なら
0x00000014に書き込まれます。
これによりユーザプログラムが実行できるわけですが、今度は0x00000014に
違う値が書き込まれていることになってしまうため、べリファイが通りません…
…OpenOCDの仕様上どちら立たずなのでしょか…
JTAGkey2Cloneの時も述べましたが、どうせほとんど変更とか無いですから
スタートアップにあらかじめ自分で計算して書き込んでおけばcalc_checksum無し
でもダイジョブで、かつOpenOCDからベリファイも使用できるようになります
すみません脱線しました。
話を戻すと、上記のVector領域のチェックサムの2の補数を置くべき場所はLPC1114
では0x0000001cになります。ここにあらかじめ計算しておいた値を書いておけば
良いです。LPCExpressoにビルドインされているLPC-Linkフラッシュライタは自前で
計算&書き込みできます。VersaloonもVSProg上では"-A"のオプションを付けること
により対応可能になりますがOpenOCDで使うときの為スタートアップコードに
書き込んでおきました。
SimonQian氏のサイトを見てると、もうそろそろOpenOCD0.5.x系にも対応するよ〜
…な記述がみられますね…。自分の使いやすい環境で開発するのが一番なので今後の
対応を期待しています！
てわけで基本のLED点滅のソースを…ご利用は自己責任で…
次はLPC1769でもやってみましょか…
ペプシバオバブ
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と一部動作互換です。
動作不安定なトコ以外は。なんとかならないだろうか…。
つづく
JTAGKey2Cloneをもっと使ってみる
20150514追:
2015年現在、JTAGKey2CompatibleのRev.5まで
上がっています。自作される場合はこちらを参考にしてください。
20150514追:
よし
やっと日記書く余裕ができた…MTM05に参加された皆様、本当にお疲れ様でした。
日記はぢめてもう1年たったことだし、ねむいさんもていどひくいと言われないような
仕事をしたいものです。本業の虹メの方がスレの途中で寝落ちしまくっててていどひくいどころ
じゃない状態なのは置いといて。てかいつもスレに参加してくれてる人ごめんなさい…。
さて本題、前回はJTAGkey2のクローンを作成し、LPC2388のフラッシュプ
ログラミングでRTCKの威力を確認しましたが、今回もう少し設定をなぶってみました。
CQ-FRK-NXP-ARMの基板は12MHzの外部クロックが乗っているのでOpenOCD接続時に
デフォルトの内部4MHzRC発振からそちらで動くように切り替えると速度が速くなる
わけですが、PLL使って最高速の72MHzまで叩き上げるとさらに速くなるはずです！
(もう十分早いけど)
↓というわけで試して比較してみました。
●Ext12MHz,With AdaptiveClocking(RTCK),CCLK=12MHz
> > "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
> openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey2.cfg -f C:/Devz/ARM/OCD/tcl/target/lpc2388_rclk_flash.cfg -c "mt_flash main.elf"
> Open On-Chip Debugger 0.5.0-dev-00267-gef72484 (2010-05-26-21:28)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> adapter_nsrst_delay: 100
> jtag_ntrst_delay: 100
> trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
> RCLK - adaptive
> RCLK - adaptive
> fast memory access is enabled
> dcc downloads are enabled
> Info : device: 6 "2232H"
> Info : deviceID: 67358712
> Info : SerialNumber: 22222222A
> Info : Description: Amontec JTAGkey-2 A
> Info : max TCK change to: 30000 kHz
> Info : RCLK (adaptive clock speed)
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : Embedded ICE version 7
> Error: EmbeddedICE v7 handling might be broken
> Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units
> target state: halted
> target halted in ARM state due to debug-request, current mode: User
> cpsr: 0x60000050 pc: 0x000038bc
> flash 'lpc2000' found at 0x00000000
> auto erase enabled
> wrote 131072 bytes from file main.elf in 2.671892s (47.906 KiB/s)
> verified 118132 bytes in 0.921881s (125.139 KiB/s)
> requesting target halt and executing a soft reset
> target state: halted
> target halted in ARM state due to breakpoint, current mode: Supervisor
> cpsr: 0x600000d3 pc: 0x00000000
> shutdown command invoked
>
> > Process Exit Code: 0
> > Time Taken: 00:05
●Ext12MHz,With AdaptiveClocking(RTCK),CCLK=72MHz
> > "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
> openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey2.cfg -f C:/Devz/ARM/OCD/tcl/target/lpc2388_rclk_flash.cfg -c "mt_flash main.elf"
> Open On-Chip Debugger 0.5.0-dev-00267-gef72484 (2010-05-26-21:28)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> adapter_nsrst_delay: 200
> jtag_ntrst_delay: 200
> trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
> RCLK - adaptive
> RCLK - adaptive
> fast memory access is enabled
> dcc downloads are enabled
> Info : device: 6 "2232H"
> Info : deviceID: 67358712
> Info : SerialNumber: 22222222A
> Info : Description: Amontec JTAGkey-2 A
> Info : max TCK change to: 30000 kHz
> Info : RCLK (adaptive clock speed)
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : Embedded ICE version 7
> Error: EmbeddedICE v7 handling might be broken
> Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units
> target state: halted
> target halted in ARM state due to debug-request, current mode: User
> cpsr: 0x60000050 pc: 0x000021bc
> flash 'lpc2000' found at 0x00000000
> auto erase enabled
> wrote 131072 bytes from file main.elf in 2.609392s (49.054 KiB/s)
> verified 118132 bytes in 0.234377s (492.212 KiB/s)
> requesting target halt and executing a soft reset
> target state: halted
> target halted in ARM state due to breakpoint, current mode: Supervisor
> cpsr: 0x600000d3 pc: 0x00000000
> shutdown command invoked
>
> > Process Exit Code: 0
> > Time Taken: 00:05
CCLKを72MHzに叩き上げたことによってベリファイ速度が滅茶苦茶速くなってます…
さすがですね〜。RAMへのダウンロードも同じくらい早いでしょう。
一方フラッシュ書き込みそのものはMAX50kb/Secで頭打ちのようです。これはフラッ
シュ消去/書き込み時間が固定でそこがボトルネックとなっているからでしょう。
STM32の方も同様の理由で頭打ちになってMAX20kB/Secが精一杯ぽいです。これももう
少し早くなると思うんだけどなあ…まだいじる必要があるのか…
あと気をつけなければならないのがOpenOCD用スクリプトのフラッシュ書き込み時の
CCLKの設定ですが、こちらも適切な値に設定していないと正しく書きこまれません。
例としては↓こんな感じです。
RTCK対応のLPC2388用OpenOCDコンフィグは既に72MHz動作対応済みです。
そして今日はもう一件JTAGKey2Cloneを使った重要な事柄があります。
先月発売されたInterfaceには付録としてSH2Aの基板が付いていました。これにはH-UDI
とかいうJTAG用の端子が備わっていて同時期にリリースされた某JTAGデバッガを接続
してデバッグができるようになってます。"た"の人曰く最初はIF誌で同JTAGデバッガの
回路図全公開の予定だったらしいのですが大人の事情で非公開となったそうです。
でもFT2232デバイス(FT2232H)を使っているのは自明かつMPSSEでJTAGとして使える
ピンは固定なのでJTAGkey2Cloneのハードウエアが余裕で使えるんじゃないかと
言うことで実験野郎してみました。
…と思ったらすでにされてる方がいました。
てか某掲示板では動かすまでいろいろアドバイス頂きありがとうございます…。
dllをこう使えばディスクリプタ合わせるためのEEPROMの書き換えすら要らんのか…すげ
てわけでJTAGKey2Cloneまんまで動きましたワーィ
これでSPIROM何発ぶっ飛ばしても無駄な出費払わずにいつもの使って復帰できますね♥
JTAGKey2(無印やクローン含む)があればAltera,xilinx,ARM,SHの開発に使いまわせられます！
でもねむいさん国産マイコンは仕事でうんざりするほど使ってるからSH2Aとかこれ以上
触るつもり全く無いんだし！
おまけ
毎年気になる電源ライン
↓立ち上がり
こっちはふつーですね・・・
↓立ち下がり
あーっとこれは…
1.2Vはスパッと0Vまで落ちてますが3.3Vラインが0.6〜0.4V付近で長時間たむろって
ます…
リセットICの電源も+3.3Vから引いてますがこれは誤動作しやすくなるやもしれません。
1.2Vが立ちあがらないUSBが繋がらない云々の件は3.3Vラインの残存チャージが原因の
一つと見てよいですね。
対策は3.3VレギュレータのVoutからVinにチャージを引き抜くようにショットキバリア
かましてやれば良いでしょう。syslab氏もすでに試されていて実際に効果ありの
ようですね。ていうか基板設計するときにもっときっちりオシロで波け…
…まぁいいや…もうARM9のボードで遊ぼう…淘宝网で買った液晶も
たくさん残ってますし
ねむいさん遊んでる暇あるの！？
届いたわぁ･･･ARM9(LPC3250)のボードが…！
今は別の案件で忙しすぎて触ってる暇すらないけどMTM05終わったk頃くらいに
androidとか動かしてみたいなぁと画策してます…。
ちなみにEmbedded Artisitsさんより直接購入しました。日本国内で代理店通して
同スペックのボード買うとどうしても割高になってしまうので…。
20190726追：上のボードは前の職場にすてｔｹﾞﾌﾝｹﾞﾌﾌﾝ寄贈してきました
ついでにこれも購入しました…しかしOpenOCDでLPC1114/1343書き込み/デバッグ
出来るようになるまで上記のLPC3250のボードとともに塩漬け…。
ついでに"た"の人のARMデバッガCortex-M3対応も期待。
上のARM9のボード購入にあたってJTAGKeyCloneの機能アップ版である
JTAGKey2Cloneの制作を行いました。
お手本にしたのは最初にJTAGKeyCloneを作ったときと同じく神木さんの作例です。
20130422追:
JTAGkey2Cloneの回路図改良しました
JTAGKey2は中のチップがFT2232Hになっています。超高速信号を引き回すことに
なるので、FTDIチップ周りは神木さんのものと同じく出来合いのモジュールを
使用しています。
氏の作例と違う部分はレベルシフタICをJTAGKeyCloneで使用したときとおなじもの
を使用し、FT2232H <-> レベルシフタ間を+5V電圧系で駆動させている点です。
FT2232HのVCCIO上限は+3.3Vなので通常なら思いきり制約に違反している
ところですが、FT2232Hとレベルシフタの+5V入出力トレラント性を大いに利用して
レベルシフタの入力(つまりFT2232Hの+3.3Vな出力)を+5Vでプルアップするという力技で電圧変換の問題をクリアして
います!!
20150218追:
↑の出力プルアップ作戦は470ohmでプルアップしてもFT2232Hの出力バッファの
引き込み能力の方が勝ってしまうため全く意味がありません。
結局出力は3.3Vのままで規約違反です。でたらめ書いてましたすみません。
代わりに+5VCMOSレベルとの動作の際の電圧遷移がどうなっているかを
調べましたので参考にしてください。
20150218追:
20150514追:
電圧レベルに関してケリをつけました！！！！！！
20150514追:
また、前回のJTAGKeyCloneを作った時はDAISENの変換基板に頼っていましたが、
今回はメッシュアース基板を利用してレベルシフタを基板に直付け・UEW線で引き
まわして高速な信号も扱えるようにしています。
↑こうしてみると1608サイズのパスコンが相対的におっきく見えるほと小さいですなぁ…
こうして作り上げたJTAGKey2CloneはJTAGKeyCloneと同じ感覚で使用ができます。
OpenOCDで使う場合なら、jtagkey.cfgと指定しているのをjtagkey2.cfgに変える
だけで使えます。JTAGKey2の売りはUSB-HighSpeedで各種シリアル転送がさらに
高速になった上にRTCK(AdaptiveClocking=自動クロック追従)がサポートされて
いる点なわけですが、これはLPC2388のようなRTCK端子が出ているデバイスで
真価を発揮します。
以下に各条件でOpenOCDからLPC2388に100kB程のデータをフラッシュ書き込み/
ベリファイした時の速度の比較を記載しておきます。
(以下無駄に長いので覚悟してください)
●JTAGkeyClone(FT2232D)/LPC2388_Ext12MHz X'tal
> > "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/lpc2388_flash.cfg -c "mt_flash main.elf" -c "continue" -c "resume" -c "shutdown"
> Open On-Chip Debugger 0.5.0-dev-00145-g2a17fd9 (2010-04-08-13:41)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> adapter_nsrst_delay: 200
> jtag_ntrst_delay: 200
> trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
> 500 kHz
> fast memory access is enabled
> dcc downloads are enabled
> Info : device: 4 "2232C"
> Info : deviceID: 67358712
> Info : SerialNumber: 11111111A
> Info : Description: Amontec JTAGkey A
> Info : clock speed 500 kHz
> Error: JTAG scan chain interrogation failed: all zeroes
> Error: Check JTAG interface, timings, target power, etc.
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : Embedded ICE version 7
> Error: EmbeddedICE v7 handling might be broken
> Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units
> 100 kHz
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Warn : srst pulls trst - can not reset into halted mode. Issuing halt after reset.
> target state: halted
> target halted in ARM state due to breakpoint, current mode: Supervisor
> cpsr: 0x000000d3 pc: 0x00000000
> Warn : Bad value '00000000' captured during DR or IR scan:
> Warn : check_value: 0x00000009
> Warn : check_mask: 0x00000009
> Error: JTAG error while reading cpsr
> 500 kHz
> flash 'lpc2000' found at 0x00000000
> auto erase enabled
> Info : Padding image section 0 with 0 bytes
> Error: Target not halted
> Error: failed erasing sectors 0 to 10 (-304)
> Command handler execution failed
> make.exe: *** [program] Error 1
>
> > Process Exit Code: 2
> > Time Taken: 00:04
↑JTAGKeyCloneでは外部クロックだとフラッシュの書き込みが出来ません！
●JTAGkeyClone(FT2232D)/LPC2388_Int4MHz RC
> > "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/lpc2388_flash.cfg -c "mt_flash main.elf" -c "continue" -c "resume" -c "shutdown"
> Open On-Chip Debugger 0.5.0-dev-00145-g2a17fd9 (2010-04-08-13:41)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> adapter_nsrst_delay: 200
> jtag_ntrst_delay: 200
> trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
> 500 kHz
> fast memory access is enabled
> dcc downloads are enabled
> Info : device: 4 "2232C"
> Info : deviceID: 67358712
> Info : SerialNumber: 11111111A
> Info : Description: Amontec JTAGkey A
> Info : clock speed 500 kHz
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : Embedded ICE version 7
> Error: EmbeddedICE v7 handling might be broken
> Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units
> 100 kHz
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Warn : srst pulls trst - can not reset into halted mode. Issuing halt after reset.
> target state: halted
> target halted in ARM state due to breakpoint, current mode: Supervisor
> cpsr: 0x000000d3 pc: 0x00000000
> 500 kHz
> flash 'lpc2000' found at 0x00000000
> auto erase enabled
> Info : Padding image section 0 with 0 bytes
> wrote 131072 bytes from file main.elf in 7.468798s (17.138 kb/s)
> verified 117280 bytes in 2.812518s (40.722 kb/s)
> shutdown command invoked
>
> > Process Exit Code: 0
> > Time Taken: 00:14
↑JtagKeyCloneでは内部4MHz RC(電源投入時のデフォルト状態)でフラッシュ
書き込みするのが無難なようです。
●JTAGkey2Clone(FT2232H)/LPC2388_Int4MHz RC
> > "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
> openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey2.cfg -f C:/Devz/ARM/OCD/tcl/target/lpc2388_flash.cfg -c "mt_flash main.elf" -c "continue" -c "resume" -c "shutdown"
> Open On-Chip Debugger 0.5.0-dev-00145-g2a17fd9 (2010-04-08-13:41)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> adapter_nsrst_delay: 200
> jtag_ntrst_delay: 200
> trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
> 500 kHz
> fast memory access is enabled
> dcc downloads are enabled
> Info : device: 6 "2232H"
> Info : deviceID: 67358712
> Info : SerialNumber: 22222222A
> Info : Description: Amontec JTAGkey-2 A
> Info : max TCK change to: 30000 kHz
> Info : clock speed 500 kHz
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : Embedded ICE version 7
> Error: EmbeddedICE v7 handling might be broken
> Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units
> 100 kHz
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Warn : srst pulls trst - can not reset into halted mode. Issuing halt after reset.
> target state: halted
> target halted in ARM state due to debug-request, current mode: User
> cpsr: 0x60000050 pc: 0x00002028
> 500 kHz
> flash 'lpc2000' found at 0x00000000
> auto erase enabled
> Info : Padding image section 0 with 0 bytes
> wrote 131072 bytes from file main.elf in 6.750044s (18.963 kb/s)
> verified 117280 bytes in 2.640642s (43.373 kb/s)
> shutdown command invoked
>
> > Process Exit Code: 0
> > Time Taken: 00:13
↑JTAGKey2Clone(FT2232D)の時と比べて少し早くなってますね。
●JTAGkey2Clone(FT2232H)/LPC2388_Ext12MHz X'tal
> > "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
> openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey2.cfg -f C:/Devz/ARM/OCD/tcl/target/lpc2388_flash.cfg -c "mt_flash main.elf" -c "continue" -c "resume" -c "shutdown"
> Open On-Chip Debugger 0.5.0-dev-00145-g2a17fd9 (2010-04-08-13:41)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> adapter_nsrst_delay: 200
> jtag_ntrst_delay: 200
> trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
> 500 kHz
> fast memory access is enabled
> dcc downloads are enabled
> Info : device: 6 "2232H"
> Info : deviceID: 67358712
> Info : SerialNumber: 22222222A
> Info : Description: Amontec JTAGkey-2 A
> Info : max TCK change to: 30000 kHz
> Info : clock speed 500 kHz
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : Embedded ICE version 7
> Error: EmbeddedICE v7 handling might be broken
> Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units
> 100 kHz
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Warn : srst pulls trst - can not reset into halted mode. Issuing halt after reset.
> target state: halted
> target halted in ARM state due to debug-request, current mode: User
> cpsr: 0x60000050 pc: 0x0000373c
> 500 kHz
> flash 'lpc2000' found at 0x00000000
> auto erase enabled
> Info : Padding image section 0 with 0 bytes
> wrote 131072 bytes from file main.elf in 5.843788s (21.904 kb/s)
> verified 117280 bytes in 1.015632s (112.768 kb/s)
> shutdown command invoked
>
> > Process Exit Code: 0
> > Time Taken: 00:10
↑JTAGKeyClone(FT2232D)では不可能だった外部12MHzのクロックでの
書き込み/ベリファイが出来てます。スピードも速くなってます。
●JTAGkey2Clone(FT2232H) with RCLK/LPC2388_Int4MHz RC
> > "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
> openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey2.cfg -f C:/Devz/ARM/OCD/tcl/target/lpc2388_rclk_flash.cfg -c "mt_flash main.elf" -c "continue" -c "resume" -c "shutdown"
> Open On-Chip Debugger 0.5.0-dev-00145-g2a17fd9 (2010-04-08-13:41)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> adapter_nsrst_delay: 100
> jtag_ntrst_delay: 100
> trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
> RCLK - adaptive
> fast memory access is enabled
> dcc downloads are enabled
> Info : device: 6 "2232H"
> Info : deviceID: 67358712
> Info : SerialNumber: 22222222A
> Info : Description: Amontec JTAGkey-2 A
> Info : max TCK change to: 30000 kHz
> Info : RCLK (adaptive clock speed)
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : Embedded ICE version 7
> Error: EmbeddedICE v7 handling might be broken
> Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units
> target state: halted
> target halted in ARM state due to debug-request, current mode: User
> cpsr: 0x60000050 pc: 0x00002040
> flash 'lpc2000' found at 0x00000000
> auto erase enabled
> Info : Padding image section 0 with 0 bytes
> wrote 131072 bytes from file main.elf in 5.859412s (21.845 kb/s)
> verified 117280 bytes in 2.640642s (43.373 kb/s)
> requesting target halt and executing a soft reset
> target state: halted
> target halted in ARM state due to breakpoint, current mode: Supervisor
> cpsr: 0x600000d3 pc: 0x00000000
> shutdown command invoked
>
> > Process Exit Code: 0
> > Time Taken: 00:09
↑書き込みは少し早くなっていますが、RCLK有効でもベリファイ速度はCCLKの関係で
頭打ちになってますね。
●JTAGkey2Clone(FT2232H) with RCLK/LPC2388_EXt12MHz X'Tal
> > "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
> openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey2.cfg -f C:/Devz/ARM/OCD/tcl/target/lpc2388_rclk_flash.cfg -c "mt_flash main.elf" -c "continue" -c "resume" -c "shutdown"
> Open On-Chip Debugger 0.5.0-dev-00145-g2a17fd9 (2010-04-08-13:41)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> adapter_nsrst_delay: 100
> jtag_ntrst_delay: 100
> trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
> RCLK - adaptive
> fast memory access is enabled
> dcc downloads are enabled
> Info : device: 6 "2232H"
> Info : deviceID: 67358712
> Info : SerialNumber: 22222222A
> Info : Description: Amontec JTAGkey-2 A
> Info : max TCK change to: 30000 kHz
> Info : RCLK (adaptive clock speed)
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : Embedded ICE version 7
> Error: EmbeddedICE v7 handling might be broken
> Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units
> target state: halted
> target halted in ARM state due to debug-request, current mode: User
> cpsr: 0x60000050 pc: 0x0000373c
> flash 'lpc2000' found at 0x00000000
> auto erase enabled
> Info : Padding image section 0 with 0 bytes
> wrote 131072 bytes from file main.elf in 2.765643s (46.282 kb/s)
> verified 117280 bytes in 0.921881s (124.236 kb/s)
> requesting target halt and executing a soft reset
> target state: halted
> target halted in ARM state due to breakpoint, current mode: Supervisor
> cpsr: 0x600000d3 pc: 0x00000000
> shutdown command invoked
>
> > Process Exit Code: 0
> > Time Taken: 00:04
↑ううん早い
JTAGkey2Clone+RTCKの組み合わせではJTAGKeyCloneと比べるとフラッシュ書き込み
ベリファイとも約2.7倍ほど早くなってます。LPC2388はROM容量が大きいので早いに
越したこたぁ無いですね♥これでLPC3250を迎え入れる体制ができました！
…あ、わかってます、遊ぶのはやる事やってからです…！！
ついでにLPC23xx系のマイコン使うときのTipsですが、このマイコンは電源を起動する
とフラッシュに書かれたプログラムとは関係なく先ず内蔵のブートローダーが立ち上が
ります。大まかな流れとしては以下のようにしてブートシーケンスを行うようです。
P2.10ピンの状態を読みに行く,P2.10=Lowの時
->ISP起動
P2.10=Lowではない時
->0x14にかかれたチェックサムが有効かどうか確認
チェックサム有効
->ユーザープログラム起動
チェックサム無効
->ISP起動
(本来これにCRP他も絡みますが詳細はUserManualのp606以降を参照してください)
したがってフラッシュロムに何も書かれていないとP2.10LowでなくてもISPが
起動します。このときにJTAGから書こうとするとISPのアドレスに飛ばされて
しまってうまくいかない時があります。がた老氏も同じ問題に遭遇されていましたが私も
JTAGKey2Clone使った時に初めて気づきました(JTAGKeyCloneでは出なかった)。
この問題はinit後即soft_reset_halt->フラッシュ書き込みで回避できました(OpenOCD-0.5.0)。
確証が完全にとれたらcfgファイル更新しときますね。更新しましま。
んでもって現在のOpenOCDのLPC2xxx系のフラッシュ書き込みはチェックサムを計算
して0x14番書き込んでくれる機能がありますがこれやってしまうとベリファイで引っか
かってしまいます(難儀だ)。
どうしてもベリファイしたかったらフラッシュメモリの0x14番地に割り込みベクタの
チェックサムを前もって計算してスタートアップに書き込んどくとOpenOCDからも
ベリファイすることができます
(割り込みベクタなんてほぼ固定ですしこれでも良いと思います)。
もちろんこれやる時はcfgファイル中の"calc_chacksum"は消しておくように！
XMEGAを使ってみる3
Versaloon関連で飛んできた人はこちらへ
年度末になると何でか糞忙しくなりますね〜…私はというと企業研修で来ている知り
合いの学生の子(去年11月下旬からSTM32初めてあっという間にマイクロマウスまで
製作ってた!!)に私のブログの内容をしてねむいさんていどひくいと罵られたり、
お客さんの現場で生暖かい目で見つめられながらハーネス打ちかえたり、私より一回
り年下の弟が私より一回り年上の彼女連れてきたりするなかで隙を見てマイコンの
勉強をやってきてます…。
LPC2388やSTM32系のMCUで動かしてきた大きめのTFT液晶、EGO028Q02や
YHY024006AをATXMEGA128A1にも導入すべく準備を進めてきました。
前回、現行のATXMEGA128A1にはPORTLが存在しないため4PORT-EBIが実質上
使用不可能と書きましたが、メモリアドレスを2つ(アドレス線は一本)しか使用しない
上記液晶たちは話が別です。FPGAボードを接続する前の肩慣らしに先ず4PORT-EBI
でTFT液晶を制御する試みを行いました。
ATxmegaのEBIに供給されるクロックはシステムクロックの2倍なので最高64MHzの
クロックスピードで動作させることができます。
高速のSRAMは恩恵を受けられるでしょうが、LCDからしてみると早すぎです。
read時だけウエイトを0->4に落とす等の細工をしています。
長々と書きましたが4PORT-EBIは無事機能して,YHY024006Aに画像やフォントを
表示することができました。
↑まだFatFs積んでないので容量の都合上このサイズの画像しか表示できないです。
ァァ残念だー(棒
あとATXEGAで試してみたい機能はADC,RTC,事象システム,FatFs(SPIをDMAにする)
搭載、それと今回試したEBIを今度は3PORT-EBIモードで大容量SRAMというか
それが乗っかったFPGAボードと接続する。そんな感じでしょうか
また、すｚ氏やいえなが氏も現在進行系でXMEGAを触られているのでお二方の
作品の完成もたのしみですね。
と、いつもならここで力尽きて日記が終わるわけですが…ていどたかい虹裏メイドを
目指すねむいさんもうちょっと頑張ってみます！！次いつ更新できるか分からないし！
私も多分にもれずSTM8S-DiscoveryというSTM32ボードを購入しましたが、以前から
目をつけていたVersaloonという汎用JTAGライタ/デバッガに改造を試みました!!
このVersaloonに使用されているマイコンはSTM32の48pin,ROM62kb,RAM20kB,
ペリフェラルとしてUSBが存在する物のようですね。そしてSTM8S-DiscoveryにSTLink
として乗っかってるSTM32F103C8T6はVersaloonになる条件をすべて満たします。
んでもっておあつらえ向きに書き換え用のJTAGの端子も出ているのでまずはUrJTAGで
様子を見てみました。
↑とりあえずJTAGKeyを繋げる…
↑ふつーのSTM32ですね〜…ちゃんとJTAGで見えます(ﾆﾔ･･
次にOpenOCDからフラッシュのバックアップを取ろうとしましたが…
↑やっぱしダメか…
というわけで一度STM32のフラッシュを書き換えてしまうともう2度とSTM8Sを
Discoverすることが出来なくなってしまうわけです。しかし！ねむいさんは
STM32のボードを購入したつもりなので容赦なく消しましたｵﾗｰ！！
次にVersaloon用の回路(後述のRelease1の回路構成)に作り替えます。必要なものは
12MHzのクリスタルです。STM8SにつながっているSWIMを構成している一部のピンは
VersaloonとDFUの動作を阻害するので必ず足上げしたりジャンパカットしてください。
注：基板の改造は必ず情報の1次ソースで提示されてる回路を参照してご自分で
判断を行ってください！！実験色が非常に強いのでここでは詳しく書きません！！
↑ねむいさんは横着なので基板からSTM32を外さずに無理やり上記の改造をしましたが
真似される奇特な人は基板から外して別に組んだ方がいいですよ?
ちょろっと出てるUEW線は用が済んで外したTDIとTDO。
↑使わなくなったSWIMのピンはDFUモードに入るためのモード
設定ピンに再利用しました。
中途半端に起立しているチップ抵抗がやっつけ感漂う…
VersaloonはDFUによりセルフアップデート出来る構成をとっています。
それに倣って最初はDFUを書き込みます…。
STM32F107系に慣れてしまった身ではとてももどかしいです。
JTAGで書くに越したことないですが、持ってない人は必要なピンだけジャンパ
引き出してシステムメモリからブートして書き込むって方法もあります…。
↑DFUが立ち上がりDFUDemonstratorが立ちあがったところ。
ここまで来たら勝ちです！
現在、Versaloonはいくつか種類があり、製作者のSimonquan氏のページから
ソース、回路図、ホスト側プログラム、OpenOCDへの対応方法などの情報は
すべて提供されています。
今回私はRelease1の回路を構成しRelease1用のファームをビルド、そして
DFU経由でVersaloon本体を書き込みしました。
↑出来上がったVersaloonを別のSTM32ボードと接続して、vsprogにて
JTAGモードとSWDモードそれぞれの方法で認識させたところ。
↑vsprog(gui)で書き込みもできます。STM32だけではなく
AVR/MSP430/PSOC/STM8Sも書き込めるようです。
↑SWDに対応するパッチを当てたOpenOCDを使用してSWDでデバッグ。
今は動作確認の為のやっけつの仮組ですが目的のSWDで使えそうなのがわかったので、
STM32を別の変換基板に移し替えて汎用のJTAGデバッガ/ライタに仕上げるつもりです。
今回の実験に使ったVersaloon用のDFUとVersaloon本体のプログラムをこちらに。非常に
実験色が強いので完全自己責任のご意見無用とさせてもらいます。
いろいろ試す3
ハロウィンネタ&他のキャラの誕生日お祝いネタの仕込みで本業(二次裏)が糞ほど忙しく
なってます。しばらくこっちは更新できそうもないので今のうちに書けることを…。
●この前のTFT液晶の在庫数が
一気に減ってたaitendoさんの900円液晶、私がこのブログに使用記を公開したあたりから在庫数が一気に
減ってました。皆様子見だったのですね〜…。
もうじき在庫ゼロになりそうな勢いです。
私はLPC2388向けにサンプルコードを公開してましたが、STM32はUSBライブラリが(ry
のおかげでまだ二の足踏んでます。まぁRCは出てるから時間の問題とは思いますが…。
あとSTマイクロ側がUSB-OTGのデュアルロール機能のサンプルとか公開してくれたら
神なんですけお…USBホスト関連のスタックは今でもそれ作るだけでお金になる
ようだから無対価で手に入るの(=枯れる)はずっと先になりそうです。
●STM32F107でUSB_DFU_Bootloader使う件
んでもって前回行ったSTM32F107/5系のブートローダーが機能しない件の回避策
ですが、ねむいさんはブートローダーをDFU一本に絞ることにしました。
したがって以後は下図のような構成でマイコン遊びを続けていきたいと思います。
20091102変更:
BOOT0とBOOT1を取り違えるという最悪なミスに気づいたので修正orz
20091216変更:
PB5は10kohmでも問題ないことが分かり修正orz
STM32F103系と違ってdfu使うための領域とかスタートアップの設定とかを
気にしなくてよくなったのは良い点だと思いますね。errataさえなければ！
●シンプルi2cマスタライブラリ
ライブラリ固め
AVRでの使用例とか
LPC2388での使用例とか
●OpenOCDのビルド方法が少し変わった
現在、zus氏のOpenOCDのビルド方法をそのままやるとビルドエラーで失敗します。
svnからgitに変わったのでgitで最新のソースを落とせとのこと。
gitでの取得のコマンドはsvnと微妙に違って
git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd
だそうです。けっこう時間かかります。
んでもっていつものフラッシュ書き込みやってみました。
STM32F107VCT6の例です↓
> "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-dev-00405-g1e5daf5-dirty (2009-10-22-11:15)
$URL$
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
1000 kHz
jtag_nsrst_delay: 100
jtag_ntrst_delay: 100
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
Warn : stm32.bs: nonstandard IR mask
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: 0x080061a4 msp: 0x20010000
Info : device id = 0x10016418
Info : flash size = 256kbytes
stm32x mass erase complete
Info : Padding image section 0 with 0 bytes
Warn : not enough working area available(requested 16384, free 16336)
wrote 95952 byte from file main.elf in 5.906250s (15.865079 kb/s)
verified 95952 bytes in 1.921875s
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:10…OpenOCD+Jtagkeyをほとんどフラッシュ書き込み機としか使っていない私。
●FreeRTOSがV6.0.0になってた
なってました。私が使用しているMCUには特に大した変更の影響はないみたいですが…。
いまはSTM32F107VCT6に重点的になっててLPC2388の更新したのずいぶん前に
なっちゃってましたので動作確認がてらにソースの見直しをしました。
LPCUSBを使用したUSB-CDCのソースコードも一本化して可搬性あげるよう
努めてます。
他のMCUにも言えることですがBare-MetalとFreeRTOSで分けていたソースは
#define切って同じファイル使いまわせるように直していくつもりです。
今見返すとつぎはぎだらけでひどかったorz
LPC2388用FreeRTOSのサンプル
LPC2388もある程度遊んだらクローズしてSTM32に集中したいです。今後はSTM32にFreeRTOSの組み合わせが日記のネタの要になるでしょう。
●STM32 Primer2の電源ICがすぐぶっこわれて云々の件
私が検証記事を載せた数日後に公式も同様な見解を述べています。
ううむ、私の読みが完全に当たってしまった…ってわけですか…。
電源IC壊れちゃった人はこの際私みたく別のLDOに変えちゃうのもいいかもしれま
せんね…。(もちろん自己責任で)
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:05STM32F103VBT6の時は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ありました…。
…なんだこれ？？？…やっぱサンプル品だから仕様外の物もあるってことでしょうか？？？
SPI-ROMの使い道がいまいち…
DDT誌に勧められるままに購入し、取り付けたSPI-EEPROM（M25P40)ですが、Lattice
の石はチップ自身にコンフィグROMが内蔵されているため、コンフィグ速度が遅い
外付けのSPI-ROMはぶっちゃけ出番がありません。しかも書き込み方法がispVMから
ではないとできないのでやっぱり使い道がありませんoｒｚ。
でもせっかく買っちゃったのでそれっぽく使ってみることにしました…。
20110527追：
ispVMがFT2232デバイスに正式対応になりました！
もちろん外付けSPIROMの書き込みも可能です！！
SPI-ROMの書き込み方法はispVMを使用しJTAG経由でSPI通信を行って
行うわけですが、私はJTAGkeyしか持ってないので(コンフィグもSVFでやってるし)
それと同等の機能を持つソフト経由で書き込む必要があります。
酔漢氏が作成されたasagaoはズバリそのものな機能があってこちらを
使わせていただくことにしました。
以下の検証内容はこちらの記事で紹介してることが全て出来ていることが前提です！
それとSPI-ROMは付けとくように！
基本的な操作方法はasagaoのマニュアルに従ってくだい。
また、一番難解なLFXP2_5E用のターゲット設定ファイルは、
私がすでに作成していますのでこちらを使用してください。
※USE AT YOUR OWN LISK
設定ファイルを読み込み、"Target Device"を"CQ-FRK-LXP2"に設定すると、
ちゃんとJTAGのチェインが繋がっていれば上記画面のように表示されます。
"detect"ボタンを押したところ。SPI-ROMのIDを読みだし表示できています。
ここまできたらあとはもう書いたり消したり自由自在です。
勝ったっッ！(愚地克己顔で)
"Erase All"したところ。
適当なhexファイルを選んで書き込み。残念ながら最速の6MHzでも遅い。
書き込み完了。Blank Checkもちゃんと機能しています。
…これでSPI-ROMを無駄にしなくて済みましたが、こいつの実際の使い道…
どうしましょうか…
コンフィグ用途に使用するのは(内蔵フラッシュと比べて)遅いし、この基板の
コンフィグモードだとコンフィグ後はCCLKがユーザI/Oとして使用できなくなる
(=自由にSPIROMにアクセスできなくなる)ので基板をリワークしてセルフダウンロード
モードにするか、もしくはCCLKピンと別のGPIOとを直結してやる必要があります。
I/O数は有り余っているのでSPI-ROMを使い倒したい方は後者の方法がベストでしょう。
LPC2388でUSB-MSC(MassStorageClass)を使う1
"有益＝ソースコードそのまま流用できる"なんて根性でやってると痛い目にあいます。
ええ確実に。…そんな根性をしていた時期が…私にもありました(刃牙顔で)
重箱の隅までは理解しなくてもいいけど最低限どうやって桶屋が儲かってるのかくらい
は知っておいた方がいいとおもいますよマジで！CQ誌提供のGCCサンプルソースとかも
(ワザとじゃないだろうけど)明確な間違い仕込んでたりしてますんで遊びであっても
くだらないことで時間や金を消費しないように気をつけましょうというお話。
とくにLPC2388は…、
.org 0x1fc
__: .word 0x43218765
のたった二行をスタートアップに仕込まれただけで文字通りゴミ基板になるしでも
こんなあくどいことするやつさすがにいないだろけど…私はそんなことしないよ？…ふふふ
…さて本題、ここ最近はLPCUSBを使用してUSB Mass Storage Class(以下MSC)をLPC2388
で何とか実現できないかと模索しています。SPIアクセスのサンプルはすでにあるのですが、
せっかくSDIO(MCI)があるのでこれで使えるものにしていこうかな、と。
現状こんな感じです。
なんか微妙な…ディスク容量が…うまく表示されてない…
SDHCも認識できているようです。が…実際の動作は？？
このMSCをchan氏のmp3プレーヤーと結合させてSDカード取り外さずにデータ書き込め
たら手間が省けてうれしいのですがはてさて…
WorkInProgressですがソースも置いときます。検証段階ゆえに自己責任+ご意見無用で…。
次回に続く
現状USB関連の書籍を買ったり借りたりしておべんきょ進めてますが…私はぶっちゃけ
おべんきょとセンセイが大嫌いです…しかしUSBを必ず物にして恐怖症を克服したいです…
追：
OpenOCDのWindows用実行形式ファイルがftdiのライセンスがらみでダウンロードできなく
なってしまいましたが、ZUS氏がビルド方法の詳細な解説をされています。
私も氏のページを参考にビルドしたもので書き込み・デバッグ・メモリダンプができるのを
確認しました(OpenOCD ver 0.3.0 r2578)。また、JTAGkey互換デバイスを使っているのなら
ベステクさんところで配布してるバイナリを使わせてもらうという手もあります。
追2：
OpenOCDのソースはsvnではなくgitを使用して取得するようにしてください。
いろいろ試す２
LPC2000系って海外の掲示板に情報わんさかあるから詰まった時はそっち見た方が速か
ったりして解決した瞬間にあんだけ足止め食らったのはなんだったんだと自分のア●さ
加減を恨んだりすることも毎度のこと…。
まぁお気楽ご気楽なアマチュアであっても情報戦マジ大事と感じる次第ですなぁ(ｷﾘｯ
…ねむいさん的には本文と関係ない与太話書いてる時が一番楽しいです。
苺は抜きで。
IF誌に載ってたOLED表示プログラムの方も同じ修正を施しました。
最終的には全部の機能合体できたらいいなと考えてます。
おまけ
前回製作したLAN基板にmicroSDカードスロット(165円)つけました。これで死角は無し！
●JTAGkeyをimpactから使う
FT2232を使用したJTAGデバイスは自作方法が急速に広まっています。しかしそれにつ
れて「作ったけど動かない&動かし方がわからない！」云々の叫びが谺してるような
気がします。きっと空耳でしょう。
私はかみき氏ベースのJTAGKey互換回路(+VID&PIDもAmontecのと全く同じ)組んでるの
で幸いデバッガ周りではほとんど躓いたことはないです。
…それは置いといて前にMAI電子さんから破格値で販売されているxilinxのFPGAボード
を運よく購入できました。DWM誌2007年7月の付録のよりも容量が２倍多いです。
早速JTAGでアクセスしてデバイスが見えるかどうか試してみました。
アクセス方法はFenrir氏が作成されたcblsrvのJTAGkey(と互換回路)対応版を使用して
impactのcableserver経由で行います。
Fenrir氏やNakagawa氏が公開されている物は私の環境(ゲストOS:Win2000、ホストOS:XPPRO,
VirtualBox使用)では残念ながらそのままでは動作しなかったので、Nakagawa氏が盛り込ん
だ修正の中でビットシフトしている部分だけ外して動作出来るようにしてます。
(こうやらないと動かないのは私の環境だけでしょう)。
認識するとこんな感じです。
書き込みも非常にスムーズ。もうLPTポートは要らない！？
cblsrv経由で使用できるのはバウンダリスキャンモードだけっぽいです。コンフィグ
ROM・FPGAへの書き込みだけならば速度も速いし(XCF04Fで50秒前後)これで充分。
このボード使って某デジットのタッチパネル液晶とか駆動できるようにしたいです。
VHDLのおべんきょｇ(ry
●OpenOCDのリビジョンが既に2570まで達していた(2009.07.30現在)
安定版は0.2.0が公式からリリースされています…がftdlのライセンスの絡みで実行
形式バイナリは公開されていません。0.1.0のバイナリも削除されています。
これからは自分で構築しなければならないようですね…非常にめんどい…。
OpenOCDは現在加速度的なスピードで開発が進められています。ネットで散見される
ARM系の開発環境構築法にはOpenOCDの設定・使用法も記されていますがあっという間
に陳腐化してしまって書いてるとおりにやるとうまくいかないこともあるようです。
OpenOCD使いこなしてる人はどのようにして風が吹いて桶屋がもうかるのかを理解し
てるでしょうからcfgなり何なりを変えるだけで対処できるでしょうが…初めて
触れる人には新しい情報と古い情報がごっちゃになってて非常に敷居が高く感じて
いるかと思います。ﾅﾑﾅﾑ。がんばれよ！(←他人事)
とりあえず2009.07.30現在一番新しいr2570のを試してみました。手持ちの幾つかの
ARM基板でフラッシュの書き込みができたのを確認しました。
(注：cfgファイルはOpenOCDの世代交代によってどんどん変わっています。そのままでは
使えないものもあるので十分吟味のこと)
-LPC2388の場合
> "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/lpc2388_flash.cfg -c "mt_flash main.elf" -c "continue" -c "resume" -c "shutdown"
Open On-Chip Debugger 0.3.0-in-development (2009-07-28-19:41) svn:2570
$URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $
For bug reports, read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
500 kHz
jtag_nsrst_delay: 100
jtag_ntrst_delay: 100
dcc downloads are enabled
500 kHz
Info : device: 4
Info : deviceID: 67358712
Info : SerialNumber: 11111111A
Info : Description: Amontec JTAGkey A
Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
Info : JTAG Tap/device matched
Warn : EmbeddedICE version 7 detected, EmbeddedICE handling might be broken
100 kHz
Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
Info : JTAG Tap/device matched
Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
Info : JTAG Tap/device matched
Warn : srst pulls trst - can not reset into halted mode. Issuing halt after reset.
target state: halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x000000d3 pc: 0x00000000
500 kHz
flash 'lpc2000' found at 0x00000000
auto erase enabled
Info : Padding image section 0 with 0 bytes
Warn : Verification will fail since checksum in image(0x00000000) written to flash was different from calculated vector checksum(0xb8a06f60).
Warn : To remove this warning modify build tools on developer PC to inject correct LPC vector checksum.
wrote 98756 byte from file main.elf in 6.125196s (15.745032 kb/s)
> Process Exit Code: 0
> Time Taken: 00:09-STM32F103VBT6の場合
> "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-07-28-19:41) svn:2570
$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
Info : device: 4
Info : deviceID: 67358712
Info : SerialNumber: 11111111A
Info : Description: Amontec JTAGkey A
Info : 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)
Info : JTAG Tap/device matched
Info : 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)
Info : JTAG Tap/device matched
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08001ec0 msp: 0x20005000
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.515641s (16.113136 kb/s)
verified 8508 bytes in 0.421888s
Info : 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)
Info : JTAG Tap/device matched
> Process Exit Code: 0
> Time Taken: 00:03-AT91SAM7S256の場合
> "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/sam7x256_flash.cfg -c "mt_flash main.elf" -c "reset run" -c "shutdown"
Open On-Chip Debugger 0.3.0-in-development (2009-07-28-19:41) svn:2570
$URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $
For bug reports, read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
dcc downloads are enabled
fast memory access is enabled
Info : device: 4
Info : deviceID: 67358712
Info : SerialNumber: 11111111A
Info : Description: Amontec JTAGkey A
Info : JTAG tap: sam7x256.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3)
Info : JTAG Tap/device matched
5 kHz
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x60000013 pc: 0x001005f4
2000 kHz
background polling: on
TAP: sam7x256.cpu (enabled)
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x60000013 pc: 0x001005f4
flash 'at91sam7' found at 0x00100000
cleared protection for sectors 0 through 15 on flash bank 0
auto erase enabled
Info : Padding image section 0 with 3 bytes
wrote 3636 byte from file main.elf in 1.468797s (2.417476 kb/s)
verified 3633 bytes in 0.109378s
Info : JTAG tap: sam7x256.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3)
Info : JTAG Tap/device matched
> Process Exit Code: 0
> Time Taken: 00:04JTAGでフラッシュに書けるようにしとくと何かと便利ですね〜。とくにJTAGkey(と互換回路)
はARMだけでなく先にも述べたとおりFPGAの書き込み等にもいろいろ使用できるので
アマチュアな人たちには必携のアイテムだと思います。
これAVRSPライクなアプリから操作してAVRに書き込みできるようになったら私的
には最強のツールになるのだが…。
●Intel X25-M(新型)を買った
購入して数日で不具合が発覚して涙目ですorzさらに4日間OSのシステムドライブと
して使用した後ベンチを取るとランダムライトの(512k,4k)速度が大きく落ち込んでい
るのが発覚orz
購入直後
4日後
X25-Mの速度低下現象は以下の手順で確実に回復(端的に)。
１．ドライブのバックアップ取る。(バックアップツールはこれ使ってます)
２．AHCI->IDEモードに切り替え、生DOSからHDDeraseのSecure Erase(enhanced)実行
３．電源断->再投入後AHCIに戻しさらにバックアップを復元する
４．わーい♥
ファームの修正で速度低下を恒久的に防止できるようになると良いですね(涙目で)
2電源レベルシフタICを使う
ARMやロジックデバイスの記事(つうか今までほとんどそればっかだ)を書くときは
JTAGKey(の互換回路)のことに触れる機会がとても多くあるのですが、そのたんびに
かみきさんの作例を引用させてもらうのは非常に忍びないので自分でもJTAGkey
互換の回路図起こしました。私が実際にARMやFPGAの書き込み・デバッグの際に
使用しているものです。
以前にも触れたとおり、ほぼかみき氏の物と同じですがなるべくJTAGkeyに似せる
べくEEPROMを外付けにしてVID,PIDを書き換えられるようにしてます。
(これやっとくとOpenOCD使うときいちいちcfg書き換えなくてすむし)
FTDIのドライバEEPROMの設定一式は"おきば"にありますので真似して作られる奇特
な人はそちらも参照のこと。
回路図は配線ミスがないか私のほうで念入りにチェックしてますが、それでも
見落としがあるかもしれません。ご利用の際は自己責任でお願いします。
…やばい、前置きがえらくまともになってしまった…もう疲れてきたよパトラッシュ…
でも後もうチョットだからね待ってていないさん…(ﾊﾟﾀ)
何で長々とJTAGkey互換回路の話ししたかというと、この回路中に信号レベルを変換
できる2電源レベルシフタIC(と5Vトレラントな1,2ゲートロジック)が使われているからで、
これが間に挟まってると1.65V〜5Vの信号までなら異なる信号レベルの問題も
気にすることなく書き込み・デバッグできるからなのです。
で、実際にこれはどの程度使えるものなのかということを検証していきたいと思います。
今回のお題：
上記2電源レベルシフタICを利用したI/Fを用いて、低電圧駆動時のAVRマイコンに
安全かつ確実に書き込みができるかどうかの検証。
実験装備：
１．今回の実験のために特別な回路で特別に動く｢USBaspx改改｣を実験用AVRライタの
ハードウエアとしてこしらえる。V-USBのバージョンアップに合わせて地味に更新中。
２．PC側の制御ソフトはavrspxのVID,PIDの記述を最新のものに
書き換えてリコンパイルした物を使用。
３．テスト用マイコンとしてATTINY2313(rev.C)を使用。試験回路はこちら。
万が一の事態に備えて19.2MHzのクリスタルを装着&使用できる状態にしている。
４．ATTINY2313のヒューズ設定は出荷時のまま。プログラムはIOパタパタさせるだけの
プログラムに、無駄にprintfライブラリのリンクをさせて2kバイトギリギリの容量に調整。
実験内容：
３．の実験用回路に１．のAVRライタを接続し、ライタ側のdelay設定は｢-d5｣にした
状態にて各電圧ごとに｢書き込み｣&｢ベリファイ｣を10回試行し、すべて正常に行えるか
どうかを確認する。
また各試験電圧時のTCKの波形を2電源レベルシフタICの入力・出力について記録しておく。
結果：1CH:レベルシフタ入力 CH2:レベルシフタ出力(測定したのだいぶ前です)
まず3.3Vから。ぜんぜん余裕です。
次に2.5V。まったく問題なし。
目標の1.8V。ぜんぜん余裕でした。波形もきれい。
ちなみに備え付けのクリスタルの駆動(19.2MHzの高速)に切り替えても1.8Vの電源電圧
で正常に書き込み・ベリファイできてます。
まとめ：
●やっぱ専用のレベルシフタはすごいね〜。
●今は通販で容易に手に入るので物怖じせずにどんどん使っていこう。
ＥＸ：
このまま1.8Vよりも電源電圧を下げてくとどうなるのか？
注：危険ですから絶対にまねしないでください!!!!!!
メーカーが保障してない電圧範囲でAVRマイコンの書き込み動作をすると、
以後デバイスが使用できなくなる可能性があります!!!
特にチップリビジョンがB以前のATTINY2313はRSTDISBLを0にしたりSPIENを1に
したりするとパラレルライタでも回復不可能になります！！！！
リビジョンC以降はダイジョブです
結果：
1.6V。まったく余裕ですな。
しかし19.2MHzのクリスタル動作だとここでダウン。以後は内蔵ＲＣ発振で。
1.4V。異常なし。ど根性AVR。がんばれ！がんばれ！
1.2V。何！？まだいけるというのか！？
1.1V。あ、とうとうベリファイエラーでた。でも今までよくがんばった。すごいぞAVR。
1.0V。もはや同期すらできない(-d20とかでもだめ)。内部基準電圧が1.1V(typ)だから
物としてもここが限界でしょう。2電源レベルシフタICの出力波形もかなりなまってます。
しかしこの電圧でもちゃんとレベル変換の仕事はしている。
まとめ：
●がんばったら乾電池一個で動くかもしれないATTINY2313。
●レベルシフタは速度さえ気にしなければ1Vでも動く。
それでは実践行ってみましょうか
いろいろ試す…
ブログ始めて1月ほど経とうとしています。書いてる記事はARM系が多いのですが、
このブログのヒットカウントの稼ぎ頭が以前少し触れたJTAGkey(の互換回路)の紹介と、
JTAGkeyとUrJTAGを使ってDDT誌のLattice基板へ書き込むの記事だったりします。
まぁ私がブログの記事をメモ帳代わりにして参照してるのでこのページカウント
だけ多いといったら当然なんですけど…そんな私のブログへの一番のリピーターさんは
googlebotさんだったりするorz
ううむ…もうちっと真面目に書くか…あーでも来週1週間は二次裏での活動に
集中したいしなぁ…困った…
話変わって、LPC2388の基板でできる事柄の追実験を私もいくつか行いましたの
で紹介します。まぁいわゆる他人のふんどしです。
●FreeRTOSを載せる
OS乗っけることによる恩恵って何なのでしょうかと自問自答する私。
そのまえにOSとはどういうものか、どのようにして動かすのか/動くのか等の
おべんきょが必要な段階です…山の頂上は遠い。
後閑氏のFreeRTOSの解説ページとFreeRTOSの公式サイトで配布されてるZIP中に
あるLPC2468用のデモを頼りにLPC2388の物に移植してみたところ、
先に作成したLPC2388用のファイルを組み込むだけであっさり動きました。
リンカスクリプトの修正もLPC2388用のアドレスに差し替え以外は特に
大きな変更もなくprintf/sprintf等の標準関数が使えてます。
時間の空きを見てこのOSの仕組みやOS使用時の定石等を覚えていきたいと思います。
そういやLPC2388のエラッタでPLLが300MHz以上だったかは動かないとか
言う記述がありますね。私が買ったのすべてチップrev.Bでエラッタの範囲外
なので高めに設定してます。
雑誌の付録は多分みんなrev.Bだから大丈夫だとは思うけど…
(雑誌記事等のPLLてやけに低めに設定されてたのはここら辺の理由ね…)
ARM7_LPC2388_xxxxxxxx.zip 試される場合は自己責任でどうぞ。
●USBHostLiteを使ってみる
くんくん氏がGCC環境にてUSBHostLiteを使いやすくした形で公開されていましたので
こちらを使わせていただきました。前回の日記のをベースにUSBHostLiteのプロ
グラムを付け足す形で作成してます。ターミナルから「u」もしくは「U」を打つと接続
されたUSBメモリにアクセスを試みる形にしました。ちゃんと読み書きできていれば
適宜メッセージが表示されます。こんな感じでうまくいけてます。
現在の外観はこんな感じです。サクサク書き込み&デバッグができるJTAGkey大活躍です。
左下に見えるLatticeの基板はAVR_Core使ってSDカード読めるところまでいってますが…
まだまだ初歩の段階です。こっちはいまだ手探りです。
●ChanさんのMCIアクセスプログラムを試す。
LPC2388用の拡張子基板がボリ松若松通商から発売されていますがSDの読み書きを
試すだけに6000円ペイするのは(趣味であっても無駄な所に金を落とすのは)
できなかったので残り物かき集めてSDカードのインターフェースだけこしらえました。
自分で作ると200円。基板組むのに25分ほど。さほど負担にはなりません。
イーサネット用の回路も自作に頼ることになるでしょうね。
プログラムはchanさんのWinARM20060606用のコードをCodeSourceryでコンパイル
できるようにmakefileを書き替えただけで後はコピペしただけで難なく動作して
しまいました。
RTCの時刻情報を反映できるような付加機能とかができたら公開したいと思います。
DDT誌付録のLatticeXP2基板にAVR_Coreを実装する(するだけ)
少し前から下描きでずっと放ってあったいないさんの画像レス用の絵を
ガーっと仕上げて二次裏内で本人にいくつか使用してもらいました。
思えば私、ひさびさに真面目に虹メ&女主人らしい活動をした気がします。
やればできるジャン私！…そして滞るブログの更新。
少し前にAVR_CoreのLED点滅&UART垂れ流しのデモSVFだけ公開してましたが、
ある程度まとまりましたのでここに実装の仕方とか箇条書きで記しておきます。
ねむいさんが後から読んでわかるレベルのことし書きませんので悪しからず。
なんせまだ検証途中なもんでこれから先もどんどん変わる。
「お前の前フリはいつも長い」という方の為にソースは最初につけておきます。
自己責任でどうぞ。
１．ハードウエアを準備しないとね
a.LatticeXP2基板はLDO&外部OSCを必ずつける。
内部も使えますがシリアル吐かせたい時は正確なクロックが必要なので。
クロックは30MHzを使用(kawasan氏のソースは内部で4分周してるので実際は
7.5MHzでうごいてます)。これは私がやってるお勧めできない実装例。
b.LatticeXP2に何らかの手段で書き込みができるようにしておく。
内蔵フラッシュにはUrJTAG+JTAGkeyでsvfファイルの再生という形で
コンフィグができます。
JTAGkey(と互換回路)は持ってるけどLPTポートが無いPCやなひたふさんの
78kライタが使用できる基板を持ってない&無駄にCOMポート増やしたくない
なんて人は私がやってる方法で試してみてください。
２．論理合成用のソフト群のインストール…
アカウントもらえるの時間かかるけどがんばれ。
れっつごー
３．AVR_Coreのソースは…
kawasan氏がxilinx用に実装を試みています。今回はこちらを使わせてもらって
LatticeXP2向けとして実装していきます。
４．プロジェクト作って…
ねむいさんは鳥頭でvhdlの文法はもうすっかり忘れてしまいました。だから
なるべくソースはいじらない方向で、かついきなり本体に実装で行きます！！
(シミュレーション等を一切考えてないとか一番ダメな手法だろうけど…)。
プロジェクトに統合したvhdファイル群と階層構造はこちら。
５．AVR側のプログラムは…
WINAVR(20090313)を使用してATMEGA103用のプログラムをコンパイルします。
後述しますがRAMは実デバイスとほぼ同じ4096バイト取るのでコンパイラ側で
リンカスクリプトなどの細工とかを考える必要は全くなしです。
(cyclone基板の頃はDWM誌に具体的な説明が何一つなくてホント苦労した)
kawasan氏のhex2vhdl.cを実行形式ファイルにしておいて、make一発で
prom.vhdまでプリッと出るようにしておきました。kawasan氏に感謝です。
肝心のプログラムの内容はソースを参照のこと(はしょるはしょる)
とりあえず前回とほぼ同じで、動いてますよ程度のものです。
６．とにかく一回合成してみる
時間長い。すげぇ長い。仮想PC上で動かしてるからこんなものなのでしょうね多分。
合成の結果を見てみるとROM、RAM共ブロックRAMを類推してくれてます。
kawasan氏のxilinx用のものがそのまま使えるようです。kawasan氏にマジ感謝です。
７．外部に信号を出す
外部に引っ張り出す信号の設定をします。今回は最小限の確認なので
こんな感じに。後述しますがreset引っ張るときは元のソースは論理が反対に
なってるので注意です。
８．jedファイルに落とす
ピン配設定まで終わったらここでjed作ります。jedからsvfはこちらを参照のこと。
９．svfを書きこむ
UrJTAGのバッチモードで一気に。svfファイル内のeraseいじっておくとあっとい
う間に終わるのは前にも述べたとおり。
あと、何度かやってるうちに分かりましたが、バッチで動かすとUrJTAGがdetect
に入ったときに時折フン詰まりになることがわかりました
バッチの記述にdetectの前にfrequencyの設定を2回記述して回避してます。
(原因はあとで調べます…)
１０．うごいた。
動いてます。ねむいさん自身はほとんど何もしてません。先達が残された偉大な
足跡に感謝ですね…。というわけでもう一回おソース。冒頭のと同じです。
試されるときは自己責任でどうぞ(定型文)
１１．考察
a.AVR側のプログラム容量の制限
なんも考えなしにべーっと合成した場合、RAM:4096byte(固定),ROM:8192byte
が限度でした。ブロックRAMは166kbitあるのでRAMが4096byteだとROMは
16384byteでもギリでいけると思いましたが…駄目。
RAMを2048に減らすと通るかしら？そうなるとRAMENDを細工しなきゃならない
のでしたくないのですが…
でも現状こんだけRAMROM使えたらおんの字ですよね！？
b.AVR_Core側
kawasan氏のvhdlソースをなるべく変えないスタンスで行きましたが、
DDT誌基板のSW入力ピンをリセットとして使うと、論理が逆になってしまう
のでソース中の記述も変えました。
また、ROM容量を8192byteまで取ったのでROMのビット幅も変えてます。
この二つの変更だけでDDT誌のLatticeXP2基板にAVR_Coreを実装できました。
あ、prom.vhdのこと忘れてた。
…実装は上手くいきましたが、AVR_Core使う場合はこっからがやっとこ始まり
ですね〜…一応RAM&ROM容量の見積もりがついたんで作りたい物のめどはつけてます…
vhdlとか論理回路とかの再おべんきょは避けられないのかorz
ディジタル・デザイン・テクノロジ付録基板のLatticeXP2にUrJTAG+JTAGkey互換回路でコンフィグする
2011.05.26追：
LatticeのISPVMがFT2232デバイスに正式対応となりました！
これで手軽に読み書きができるようになります。
いい時代となりましたね♥
追の追:
内蔵Flashに書くときは.jedファイルを指定します。
SPI-ROMに書くときは.bitファイルを指定します。
あとHS-1はGNDに落としておくこと。
2009.07.31追:
Latticeの付録基板を使用中、書き込み・消去が失敗すると以後基板からヤバ目
の発振音がしてJTAGで一切アクセスできなくなる事態に陥いることがあります。
これは「不完全なコンフィグ->コア電流異常消費->電圧ドロップ->再コンフィグ」
のループを繰り返してデッドロック状態に陥ってるからです。
この状態から回復するにはnPROGピンを(Lattice基板上でCN2_B07を)LOWに
引いたまま電源を投入して電源投入直後のコンフィグを開始させない状態で
JTAGにアクセスし、書き込みor消去を正しく完了させる必要があります。
依然としてこのページのアクセスが非常に多く大事なことだから2度言います。
DWM誌が廃刊休刊となり、新たにディジタル・デザイン・テクノロジ誌、
略してDDT誌が刊行されました。ご多望にもれず、付属基板なんかがついてます。
石はLatticeのLFXP2-5E-5TN144Cですね。フラッシュベースの不揮発型FPGAですって。
ねむいさんはLPC2388基板と秋月ARM基板動かすのに夢中になってたので
ほうっておいていましたが少しだけ触ってみましたよ。LPTの書き込みアダプタはもはや
作る気がなく、なひたふ氏の78kを使ったライタはCOMポートが増殖してしまいます。
ねむいさん的にはテストを兼ねてUrJTAG+JTAGkeyを使ってSVFファイルの
再生と言う形でLatticeの基板に書き込みをして見ようと思います。
…5月17日現在、ネットで検索してもデモのLEDチカチカを書きこんだ！
以外の作例が全くと言っていいほど見当たりません。
それどころかLEDチカチカの記事すらほとんどないのがさらに不安をあおります。
唯一chanさんはミクを動かしてレヴェルの違いを見せつけてくれていました。すげぇ。
私も一つ組んでみました。30Mhzの水晶とM25P40-VMN6P、LDOのADP3339なんか
つけてみました。あれ？このADP3339って…とお思いの方、かわいそうに…そう、+5V電源を
指示どおりに接続すると高い確率で発振するかのSH2基板に乗っかっていたアレですね〜。
今検索すると"「接続すれば発振する」は通用しない"と言う一文がトップに躍り出て
とても意味深です。でもADP3338/ADP3339はわるないよ？
それはおいといてこんな感じに各部品を実装。電源は容易に脱着できるように
JST-XAを。JTAGの端子は10Pinありますが、実際に信号が出てるのは
TCK,TMS,TDO,TDI,Vcc,GNDだけなので、馬鹿避け用に真ん中の一本はカットしてます。
ついでに9,10Pinもカット(最初からつけなきゃよかったorz)もちろん対になる8Pinコネクタ
(どうせ残りの9,10Pin繋がってないし…)はカットした真ん中の一本に
メクラをかませて馬鹿避けを実現してます。
ADP3339用のコンデンサは裏に実装してます。VinにはGRM21BB31C106KE15を、Voutには
秋月のこの子を付けて常時安定した+3.3Vの供給を行っています。
秋月のセラコンは+3.3V以下のセラコン対応のLDO用に大量に買っておいてもいいと思います。
あ、言い忘れてた、ADP3338/3339使うときはRP1、RP2は必ず除去してください！
真似する人はちゃんとデータシートで確認すべし。
さらに今回はSPIEEPROMは付けたけど一切無視するのでHS1のジャンパもカット。
やっとかないとSVFで書けません。
書き込む準備は出来ましたので次はsvfファイル生成ですね。
ISPLEVERとその他ツールはインストールしてあるものとして話を進めます。
jedの生成までは紙面にあるので省きますよ！！
(ツールをインストールするまで一苦労でしたね〜…認可もらえるまで
時間やたらかかったり、まぁその分しっかり審査しているということなのでしょう。
ちなみに私は組織名:二次裏メイド協会、名前：キリ・イセノミヤで通りました。
はぢめて上司が役に立った(笑)…っていいのかこれで)
では行きましょうか。
というわけでだいぶ端折ってjedが生成されたところからスタート。
これから先は画像付きで。
��jedが生成し終わったらispVMを起動する
��ChainConfigration1と言うウィンドウは即効消す。
��UniversalFileWriterを起動
��生成ファイルにSVFを選択
��InputDataFileに先に生成したjedを選択
��RUNTEST FROM REV.C をONにする
��OutputDataFile名を指定する。
��Genereteボタンを押してSVFを生成
はい出来ましたね？できてなくても次行きます。
次はいよいよ書き込みです。前ふり長くなりましたがこっからが本番です。
UrJTAGをダウンロードしてインストールしてください。JTAGkeyと通電した基板を接続し、
UrJTAGを起動。生成したsvfをUrJTAGと同じフォルダに置いて以下のコマンドを順番に。
その前に！HS1のジャンパカットし忘れてたら電源落としてカットしておいてね！
>cable jtagkey
>detect(ちゃんと繋がっていればここでチェーンが見える)
>part 0
>instruction length 8
>svf (生成したSVFのファイル名) progress
１分ほどたつと
>Scanned device output matched expected TDO values.
と表示され、FPGAがロードされます。
あと小技ですが、svfファイルの中のeraseの記述で
>! Erase the device
>
>! Shift in ISC ERASE(0x03) instruction
>SIR 8 TDI (03);
>! wait 1.20e+002 SEC
>RUNTEST IDLE 120000003 TCK;
の
>RUNTEST IDLE 120000003 TCK;
を
>RUNTEST IDLE 5000003 TCK;
くらいに減らしてやると書き込み時間を大幅に短縮できます。
最速で40秒くらいでコンフィグできます。それぞれの環境で調整して見てください。
また、もし書き込みが失敗してFPGAが不安定な状態に陥ったらnPROGピンを(基板上で
CN2_B07を)LOWに引いたまま電源を投入して再び書き込みを行って回復して
くださいね。基板捨てんじゃねぇぞ！あきらめるな１！！(←乙女の雄叫び)
こんなかったるいコマンド入力いちいちやってられるか！！と言う
方はバッチで実行するやり方もありますのでご紹介します。
こちらの中にサンプル付きでありますので中のファイル見てねむいさんが
何をしたいかが理解できる人だけ自己責任でどうぞ。
30MHzの外部OSC必須です。でもUART要らない人は特に周波数に気にしなくてもいいです。
JTAGkeyClone(FT2232系JTAG I/F)製作のすすめ
20130521追:
FT2232系デバイスを用いたJTAGKey/JTAGKey2製作に関しては
こちらを参照してください！
お仕事の方でサーボモータのおべんきょを一からしてます。
そもそもねむいさんは4年制大学を卒業したにもかかわらず就職氷河期の下、
20代後半まで介●の仕事をしながら本業の虹裏メイドをしていたので電気の分野は
ほぼ一からおべんきょなのですが、私の場合は元主人が遺したARMマイコンに
関するリソースが最初から大量にあったのでARMマイコンに関しては強くて
ニューゲーム状態だったのです。
とはいえまったくのどしろうとでもべんきょうさせてもらえながらちゃんとしごともさせて
もらえてさらにおきゅうりょうまでもらえるくみこみぎょうかいってすごいとおもいます。
ちなみにねむいさんのほんしょくのにじうらめいどはちょうぜつぶらっくでにんきのない
めいどは｢｣たちにすぐよごれきゃらのきゃらづけをされてあらしのどうぐにされてすてら
れるというれつあくかんきょうなうえにおきゅうりょうがはなくそていどしかもらえません。
ふぁっくです。
きょうのにっきおしまい。
…真面目に読んでしまった人すみません、続行します。
以前はJTAGの制御といえばPCのLPTポートに少しばかりのロジックデバイス、
おもに信号レベル変換のバッファが乗った回路を接続してI/O直叩きで制御
ってのが主流でしたよね。CPLD/FPGAを提供している各社もLPT接続タイプの
書き込みケーブルの回路を公開していて、趣味で開発やっている人も自作が
容易にできていました。
時は流れ、いまどきのナウでヤングでスタイリッシュなPCにLPTポートなんて
時代遅れのものは搭載されなくなり、代わりにUSB接続のダウンロード
ケーブルがメーカから提供されるようになりました。
しかし、USBのそれは各社のノウハウになっていて真似して自作できる
代物ではなくなってしまいました。
しかも安くても３諭吉くらいしてホビー用途には手が出しづらい。
しかしながら数年前くらいからFT2232等のJTAGのライブラリが
サポートされるデバイスが出てきて有志の人たちがフリーで多目的に
使用できるアプリケーションを作られてきました。
そのFT2232を使用したJTAGハードウエアで有名なのがAmontec JTAG keyですね。
容易に自作できるのでFT2232系は上記を含め多くの派生があります。それを通じて
ARMマイコン等のJTAGポートを備えたデバイスにアクセスできる(フリーで使える)
PC側のソフトは、OpenOCD、UrJTAG等などたくさんあります。
先の日記で何度か言及してますが、私もかみき氏の作例をベースに一つ
作成しました。2電源レベルシフタがミソです。氏の回路と違う点は、ターゲットに
電源供給する回路を廃したことと、外付けEEPROM(AT93C66A)の回路を追加して
Amontec JTAG keyに化かすことを目的としました。
自分自身の学習の意も含め、かみき氏互換のJTAGkeyCloneの回路図を起こしました。JTAGkey2Cloneに関してはこちらをご参照ください。
また、JTAGkeyCloneに化かすためのeepromのデータですが、こちらにある
JTAGKey用のデバイスドライバのZIPファイルを展開するとJTAGKey_eepData
というフォルダがあります。この中にあるamontecJTAGKey.eptというファイルを
MProgで読み込んでeepromに書き込んでください。
もちろんEEPROMの書き込みの際は先にFTDIのドライバをインストールして
おかなければなりません。
これは先のZIPファイル内のftd2xxというフォルダにあります。
20130521追:
JTAGKey/JTAGKey2製作に関してはこちらを参照してください！
以下JTAGkey互換回路を制御できるアプリの使用時の画面とかを。
詳しい使用記は以後の日記で幾つかをぽつぽつと。
IF誌付録LPC2388基板にOpenOCD+insightでデバッグ
asagaoでDWM誌2008年9月号付録のColdFire基板のEzPort経由のプログラム書き換え
OpenOCDで秋月ARM基板のRAMスタート
UrJTAGのSVF機能でDDT誌付録のLatticeXP2基板を高速にコンフィグ
fenrir氏作成のcblsrvのFT2232対応版を使用してxilinx IMPACTからコンフィグ
(注：fenrir氏によってISE11.x以降でも使えるようになりました！)
そして本懐のamtsvfplayerでSVFを再生…できねぇ！
20120215追:
amtxhal.dllはグルーロジック(非公開)が組まれたPORTB側のDS2432という
EEPROMに仕込まれたキー情報も読みに行っているのでクローンの場合は
amtxhal.dllを使用するプログラムは一切使えなくなります…が
amtsvfplayerくらいしか使われてるの見たことないのでJTAGkeyCloneでも
それ以外の用途では全く問題はありません。
JTAGkey系のCloneでsvf使いたいならUrJTAGを使いましょう。
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:05DFUが正しく書きこまれていれば、DFUseを起動するとこの画面が見えるはずです。
これでJTAGさえあればDFU書き潰して0x08000000でスタートするプログラム
書きこんでも大丈夫ですね。…と言いたいところですが！
STM32のコアクロックが停止する__WFI命令等を実行しっぱなしの
プログラムを不用意に書きこんでしまうと起動->__WFIでクロック停止->JTAG
インターフェースも仲良くおだんまりとなってJTAG経由のアクセスが
一切できなくなってしまいます!
これを回復するには先日紹介したシステムメモリからのブートでシリアル
経由でフラッシュの消去を一旦行うか、リセットボタン連打しながらJTAG経由で
うまく引っかかるまでひたすら消去動作を行い続ける方法があります
(ファミコンの裏ワザみたいだ)。私としては
Project Examples and Misc Files
ねむいさん専用のFatFs中心のサンプルコード・プログラム置場です。
私が使いやすいようにGCC環境に勝手にポーティング&改造してあります。
文書の記述間違い・バグを見つけた場合は勝手に修正しています。
太字のリンクは更新頻度高。試される場合は自己責任でお願いします。
Dear All
Here is my ChaN's FatFs implementation examples.
Those projects are suitable to build in GNU-GCC environment.
If you have any question,see here to contact me.
●ARM
(Confirmed on 64bit Win7,8,10,11 by ARM-GCC)
ビルドの仕方はこちら
Building Method on Native Windows Environment is Here.
-Cortex-M7
STM32H7xx(STM32H747I-Discovery supported!)
(CubeH7:V1.12.0/HAL:V1.11.5)
(+ HelixMP3/AAC,libjpeg,libpng and giflib decode example)
*TFT Control Example with ChaN's FatFs(SDMMC-Interface)
It supports SDXC and eMMC!
STM32F7xx(STM32F769I/746G-Discovery supported!)
(CubeF7:V1.15.0/HAL:V1.2.9)
(+ HelixMP3/AAC,libjpeg,libpng and giflib decode example)
*TFT Control Example with ChaN's FatFs(SDMMC-Interface)
It supports SDXC and eMMC!
-Cortex-M33
STM32H5xx(STM32H563ZI-NUCLEO supported!)
(CubeH5:V1.1.0/HAL:V1.1.0)
(+ libjpeg,libpng and giflib decode example)
*SPI-TFT Control Example with ChaN's FatFs(SDMMC-Interface)
It supports SDXC and eMMC!
STM32L5xx(STM32L552ZE-Q-NUCLEO supported!)
(CubeL5:V1.5.0/HAL:V1.5.0)
20250501更新停止
(+ libjpeg,libpng and giflib decode example)
*SPI-TFT Control Example with ChaN's FatFs(SDMMC-Interface)
It supports SDXC and eMMC!
-Cortex-M4F
STM32F4(STM32F407ZGT6/PowerAVR-RedBull Compatible Circuit
& STM32F437IIT6/盈钰電子STM32F4xxIxT6开发板互換
& STM32F407VGT6/STM32F4Discovery
& STM32F429ZIT6/STM32F429I-Discovery are also supported!)
(FWLib:V1.8.0)
(+ HelixMP3/AAC,libjpeg,libpng and giflib decode example)
*TFT/OLED Control Sample with ChaN's FatFs(SDIO&SPI-Interface)
It supports SDXC and eMMC!
STM32F401xx(STM32F401RET6/NUCLEO-F401RE Compatible Circuit)
(CubeF4:V1.24.1/HAL:V1.7.6)
*KickStart & I2C-LCD/OLED and many Devices example
STM32F334(STM32F334R8T6/NUCLEO-F334R8 Compatible Circuit)
(CubeF3:V1.11.0/HAL:V1.5.3)
*KickStart & I2C-LCD/OLED many Devices examples!
LPC4088(LPC4088/EA4088 Board Semi-Compatible Circuit)
*ChaN's FatFs Sample(SDMMC-Interface)
It supports SDXC and eMMC!
LPC4357(盈钰電子LPC4357开发板互換)
*ChaN's FatFs Sample(SDMMC-Interface)
It supports SDXC and eMMC!
LPC4330(LPC4330-Xplorer Compatible Circuit)
20150912更新停止
*Dual/SingleCore-KickStart
LM4F120H5QR(Stellaris Launchpad Compatible)
20150912更新停止
*KickStart
-Cortex-M4
K20(MK20DX32VLF5)(Bare-Metal)
*KickStart
-Cortex-M3
STM32F103(STM32F103VET6/STM32 Primer2)
(FWLib:V3.6.1 ,USBLib:V4.0.0 ,
FatFs STM32F1 SDIO-Interface Imprementation)
*Bare-Metal GPS & GNSS-Tracker using ChaN's FatFs
EFM32TG822F32(Bare-Metal for TinyGecko)
*LED-Blink & UART
LPC13xx(LPC1347/LPCXPresso Compatible Circuit)
20150912更新停止
*KickStart
STM32F2(STM32F207ZGT6/PowerAVR-RedBull Compatible Circuit)
20150912更新停止
(FWLib:V1.1.2)
*(Deprecated) TFT/OLED Module Control Sample with ChaN's FatFs(SDIO-Interface)
STM32F107(STM32F107VCT6/CQ-STARM-JUNKBOARD Compatible Circuit)
20150912更新停止
(FWLib:V3.6.1 ,USBLib:V4.0.0)
*(Deprecated) TFT/OLED Module Control Sample with ChaN's FatFs(SPI-Interface)
STM32VL(STM32F100RBT6/STM32VL-Discovery Compatible Circuit)
20150912更新停止
(FWLib:V3.6.1)
*(Deprecated) TFT/OLED Module Control Sample with ChaN's FatFs(STM32VL SPI-Interface)
STM32L(STM32L152RBT6/STM32L-Discovery Compatible Circuit)
20150912更新停止
(FWLib:V1.1.1)
*(Deprecated) TFT/OLED Module Control Sample with ChaN's FatFs(STM32L SPI-Interface)
MB9BF618T(FRK-FM3-GARBAGEBOARD Compatible Circuit)
20150924更新停止
*(Deprecated) LED-Blink & UART
*(Deprecated) TFT/OLED Module Control Sample with ChaN's FatFs(MFS SPI-Interface)
MB9AF112K(Bare-Metal)
20150912更新停止
*(Deprecated) LED-Blink & UART
LPC177x/8x(LPC1788/EA1788 Board Semi-Compatible Circuit)
20160331更新停止
*(Deprecated) ChaN's FatFs Sample(MCI-Interface)
-Cortex-M0+
STM32U083xx
(STM32U083RCT6-NUCLEO Compatible Circuit)
*KickStart & I2C-LCD/OLED and many Devices examples!
STM32C031xx/STM32C011xx
(STM32C031C6-NUCLEO/STM32C011XX-DK Compatible Circuit)
*KickStart & I2C-LCD/OLED and many Devices examples!
STM32G03xxx(STM32G0316-DISCO Compatible Circuit)
*KickStart & I2C-LCD/OLED and many Devices examples!
LPC824(LPC824/LPCXPresso Compatible Circuit)
*KickStart
KL25(MKL25Z128VLK4/FRDM-KL25Z Compatible Circuit)
*KickStart
KE02(MKE02Z64VQH2/FRDM-KE02Z Compatible Circuit)
*KickStart
EFM32ZG222F32(For EFM32ZG-STK3200)
*LED-Blink & UART
STM32L05xxx(STM32L053C8/STM32L0538-Discovery Compatible Circuit)
*KickStart
LPC812(LPC812/LPCXPresso Compatible Circuit)
20160331更新停止
*(Deprecated) KickStart
KL05(MKL05Z32VFM4/FRDM-KL05Z Compatible Circuit)
20170629更新停止
*KickStart
-Cortex-M0
STM32F03x(STM32F030R8T6/NUCLEO-F030R8 Compatible Circuit)
(CubeF0:V1.7.0/HAL:V1.5.0)
*KickStart & I2C-LCD/OLED and many Devices examples!
NUC120LE3(NUC120LE3AN/NuTiny-SDK-NUC120 Compatible Circuit)
*KickStart
M0516LBN(NUC120LE3AN/NuTiny-SDK-M0516 Compatible Circuit)
*KickStart
LPC11u35(LPC11U35/501 CMSIS-DAP Compatible Circuit)
*KickStart
STM32F05x(STM32F051R8T6/STM32F0-Discovery Compatible Circuit)
(CubeF0:V1.3.0)
20150922更新停止
*(Deprecated) KickStart
LPC11xx(LPC1114/LPCXPresso and MARY and DIP28-package Compatible Circuit)
20150922更新停止
*(Deprecated) KickStart
-ARM7TDMI
LPC23xx(LPC2388/CQ-FRK-NXP-ARM-JUNKBOARD Compatible Circuit)
20181222更新停止
*(Deprecated) TFT/OLED Module Control Sample with ChaN's FatFs(MCI-Interface))
●AVR
-AVR-Dx
AVR128DA48 CuriosityNANO
(and AVR128DB28,AVR64DD28 baremetal supported)
*UART & Internal Temperature Test
-XMEGA
ATxmega128A1/Atxmega128A1U
20240101更新停止
*(Deprecated)TFT/OLED Module Control Sample with ChaN's FatFs(SPI-Interface)
●Windows Tools and Misc
- OpenOCD for Windows
ocd-0.12.0+dev-00927-g6834f022b(built on 20250413)
Windows 32bit Binary Nemuisan's Special Version
*Supported OS*
->Windows7,8,10,11(x86 or x64)
->WinXP last version is here.
*Supported Debugger Hardware*
->JTAGKey,JTAGkey2 and many FT2232 Devices(WinUSB)
->JLink(WinUSB)
->JLink On LPCLink2(WinUSB)
->JLink On LPCXpressoV2/V3(WinUSB)
->JLink-OB(WinUSB)
->STLink,/V2,/V2-1 and /V3(STMicro's Distributed USB-Driver/WinUSB)
->Versaloon(WinUSB)
->TI-ICDI(TI's Distributed USB-Driver/WinUSB)
->CMSIS-DAP(Generic USB-HID/Mbed VCP Driver)
->Nulink(Generic USB-HID)
*OPENOCD FOR WINDOWS BINARY HERE!
SHA-1 HASH:dbd869c023d119b05d879fee52125d16530cef71
OpenOCD(0.13.0)'s Specific MCU cfg Files for Flash Programming=
*OpenOCD spesific MCU-Aimed cfg files Nemuisan Special
↑Notice:Already contained in my OpenOCD Binary.
For self build users & linux users only.
OpenOCD(0.13.0)'s Patch Set(Useful Functions & Fix Patches)
*OpenOCD Patch Set Nemuisan Special
↑For self build users & linux uses only.
- AVRDUDE for Windows
AVRDUDE for Windows v8.0 32bit Binary(built on 20250413)
Nemuisan's Special Version
Supported OS
->Windows7,8,10,11(x86 or x64)
*AVRDUDE FOR WINDOWS BINARY HERE!
-SPIROM Writer Tools
FLASHROM for Windows(SPI-ROM Writer) (built on 20250413)
1.6.0-devel (git:v1.5.0-44-g4d4688cc) 32bit Binary
For FT2232/FT232H Devices(WinUSB)
*Flashrom_v1.5.0-44-g4d4688cc.7z
-JTAG Tools
UrJTAG for Windows v2021.03 #d9a2943f(built on 20250413)
*urjtag.tar.gz
SupportedHardware
->JTAGKey,JTAGkey2 and many FT2232 Devices(WinUSB)
->JLink(WinUSB)
->JLink On LPCLink2(WinUSB)
-JTAG Hardware
-Schematic of JTAGkey2 Compatible Circuit Rev.5
(Supports 1.4〜5.5V WideVoltage Range)
*JTAGKey2CompatibleCircuit_Rev.5
かつてこの欄でFirefox拡張｢合間合間に｣のバックアップを公開していました。
20191124更新：
waterfox向けの｢合間合間に｣のふたばの仕様変更対応版をサルベージしましたので
こちらでも公開します。
※｢赤福Firefox版」/｢合間合間に｣は有志の方がGitHubにて管理されています。
※unmhtはこちらに残っています。
免責・連絡先は↑のリンクを
↓SNSもやってます↓
powered by まめわざ
- ARM/STM32 (117)
- OpenOCD (27)
- ARM/NxP (34)
- ARM/Cypress (5)
- ARM/Others (3)
- ARM/Raspi (1)
- AVR (13)
- FPGA (4)
- GPS/GNSS (19)
- MISC (84)
- STM8 (2)
- Wirelessなアレ (16)
- おきぱ (1)
- ブラウザベンチマーク (29)
- 日本の自然歩道 (27)
- 中部北陸自然歩道を往く -砺波平野の県境を駆け抜ける！-
⇒ ねむい (12/18) - 中部北陸自然歩道を往く -砺波平野の県境を駆け抜ける！-
⇒ ひかわ (12/15) - 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)
- April 2025 (1)
- March 2025 (1)
- February 2025 (1)
- January 2025 (1)
- December 2024 (2)
- November 2024 (1)
- 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)
Copyright(C) B-Blog project All rights reserved.