MMC flashing

[sbourdeauducq]

@gkasprow

I tried loading an old firmware of yours using OpenOCD. At first the result was encouraging and surprising, OpenOCD found the chip correctly without any obscure problems.

But when moving on to write the flash, I obtained the typical result of embedded systems (which is a reason one should think twice before putting a MCU on any board): the programmer crashed during flashing, the board is bricked, and most annoyingly the MMC no longer responds correctly to JTAG. Do you have an idea why the latter problem appeared? I saw that the MMC JTAG is also connected to the SCANSTA chip, could it be interfering?

OpenOCD log is:

Info : JTAG tap: lpc17xx.cpu tap/device found: 0x6af6902b (mfg: 0x015 (NXP (Philips)), part: 0xaf69, ver: 0x6)
Warn : JTAG tap: lpc17xx.cpu       UNEXPECTED: 0x6af6902b (mfg: 0x015 (NXP (Philips)), part: 0xaf69, ver: 0x6)
Error: JTAG tap: lpc17xx.cpu  expected 1 of 1: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
Error: Trying to use configured scan chain anyway...
Error: IR capture error at bit 4, saw 0x21 not 0x...3
Warn : Bypassing JTAG setup events due to errors
Error: Invalid ACK (6) in DAP response
Error: Invalid ACK (6) in DAP response

[sbourdeauducq]

Seems to be some electrical problem (EMI?) on the JTAG lines. The JTAG tool is generally flimsy and the later failures probably had nothing to do with my initial flashing attempt. I managed to reflash the board and it works again, despite some (reproducible) errors during verification:

Info : clock speed 100 kHz
Info : JTAG tap: lpc17xx.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
Info : lpc17xx.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: lpc17xx.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc
** Programming Started **
auto erase enabled
Warn : Verification will fail since checksum in image (0x00000000) to be written to flash is different from calculated vector checksum (0xeffec046).
Warn : To remove this warning modify build tools on developer PC to inject correct LPC vector checksum.
wrote 131072 bytes from file Downloads/lpc_1776_ethernet.axf in 25.443941s (5.031 KiB/s)
** Programming Finished **
** Verify Started **
Error: checksum mismatch - attempting binary compare
diff 0 address 0x0000001c. Was 0x46 instead of 0x00
diff 1 address 0x0000001d. Was 0xc0 instead of 0x00
diff 2 address 0x0000001e. Was 0xfe instead of 0x00
diff 3 address 0x0000001f. Was 0xef instead of 0x00
No more differences found.

[jordens]

@sbourdeauducq iirc there was also effort or at least planning of going openocd over at open-mmc.

[gkasprow]

@sbourdeauducq I use programmer from NXP and never had issues. SCANSTA is disconnected when programmer is inserted. Make sure that your programmer header shorts pins 3,5,9. Otherwise SCANSTA won't e deactivated, will block the port and cause such issues.

[gkasprow]

@sbourdeauducq the MMC can be upgraded by USB cable using Flashmagic or whatever that is able to talk with NXP bootloader. I tested it with Flashmagic and it works. The T24-2 and T23-2 need to be shorted to make it working.

[sbourdeauducq]

What is the purpose of the SCANSTA connection? Is it possible to flash the MMC over JTAG using the integrated FTDI chip through the SCANSTA? Is it what Flashmagic does?

[sbourdeauducq]

Seems that the four failing bytes are normal...

Warn : Verification will fail since checksum in image (0x00000000) to be written to flash is different from calculated vector checksum (0xeffec046).
Warn : To remove this warning modify build tools on developer PC to inject correct LPC vector checksum.

So, anyway my OpenOCD setup is somewhat working.

[sbourdeauducq]

@gkasprow can you post RGMII and MII MMC firmwares here?

[gkasprow]

@sbourdeauducq I connected SCANSTA JTAG to MMC JTAG to give option to talk from AMC connector or FTDI chip. So it is possible to talk to MMC, but SCANSTA must be switched to this mode. Flashmagic uses only UART to download the binary because MMC has its own bootloader.

[gkasprow]

@sbourdeauducq To switch PHY to MII mode, one must clear SPD 1 set SPD 0 clear DDR

The firmware I attach below sends PHY chip register contents once front panel button is hold for 1 second so you can verify if it succeed. MII firmware: lpc1776_ethernet_I2C_MII.zip

RMII firmware: lpc1776_ethernet_I2C_RMII.zip

I didn't test if it works because don't have MII FPGA MAC.

[sbourdeauducq]

Thanks. In those firmware images, did you fix the JTAG bug when RTM is not present?

[gkasprow]

@sbourdeauducq When you plug the MMC JTAG probe the Scansta is disabled at all. It is a quick fix done with wire and transistor. That's why it breaks the FPGA chain. So simply remove the JTAG probe.

[gkasprow]

Anyway, the idea of connecting MMC to the JTAG switch it controls was not the best one... It can literally cut the branch on which it sits. The TX_ER and MII_COL is not connected in MII mode

[sbourdeauducq]

It is a quick fix done with wire and transistor. That's why it breaks the FPGA chain. So simply remove the JTAG probe.

OK. That works.

[sbourdeauducq]

Flashed sayma2 and sayma3 with the new MII firmware.

[jbqubit]

@sbourdeauducq That's great news! Can this be added to artiq_flash?

[sbourdeauducq]

You need a non-board-specific JTAG cable etc. so rather not.

[jbqubit]

OK. Created an Issue to discuss part of this for Sayma 2.0 https://github.com/m-labs/sinara/issues/449.

[gkasprow]

you can do it via USB with some xmodem protocol

[jbqubit]

@gkasprow Is this the right adapter to go from the 14-pin JTAG to the mini 10-pin JTAG?

[gkasprow]

which one?

[jbqubit]

https://www.digikey.com/products/en?mpart=JLINK-RX-AD&v=622

[gkasprow]

I use LPC-Link 2 The pinout I use is standard among the ARM community so this should work.

[sbourdeauducq]

Correct MII firmware: https://github.com/m-labs/artiq/issues/854#issuecomment-353407812

[sbourdeauducq]

@gkasprow Can you post here RGMII firmware with all known MMC bugs fixed + Exar/Ethernet register dumps initiated from the serial console?

[sbourdeauducq]

By the way, Flashmagic works under wine, serial ports are simply configured with ln -s /dev/ttyUSB_sayma-1_2 ~/.wine/dosdevices/com1. Since this is a tool from 1992, the hex file it wants can be obtained with arm-none-eabi-objcopy -O ihex lpc1776_ethernet_I2C.axf lpc1776_ethernet_I2C.hex. The two open source replacements, lpcflash and MCUload, do not work.

[jbqubit]

Flashmagic works under wine

That's nifty that wine works for Flashmagic. But please also get a Windows 10 machine running in HK so you can use the same tools as WUT.

[gkasprow]

@sbourdeauducq Let me test it first. I will be back in the lab tomorrow morning.

[sbourdeauducq]

But please also get a Windows 10 machine running in HK so you can use the same tools as WUT.

What problem would that solve exactly?

[jbqubit]

@gkasprow said

you can do it via USB with some xmodem protocol

@sbourdeauducq Have you tried this approach? What are prospects for integrating it with artiq_flash?

[gkasprow]

it seems you can try this https://github.com/devio/lpcflash

[sbourdeauducq]

I tried it and nix (see my above comment: "The two open source replacements, lpcflash and MCUload, do not work").

[sbourdeauducq]

@jbqubit If you want MMC flashing in artiq_flash, I suppose we have to reimplement something like this lpcflash (lpcflash code quality isn't great; there isn't much we'd want to reuse there).

[jbqubit]

@sbourdeauducq Did you try xmodem?

[hartytp]

What’s the outcome of this? Can we close or is there anything else to do before v2.0?

[sbourdeauducq]

No. There are manual ways to flash, and no funding to automate it with artiq_flash.