K64F flash algorithm is unstable

[bremoran]

I'm not sure "unstable" is the right word. Maybe "unusable" would be more appropriate. I've now spent days attempting to debug my project, chasing a Heisenbug, only to discover that it has absolutely nothing to do with my code. Oh, goody.

Here's an example of the problem. A good flash:

(gdb) x/16hx 0x5950
0x5950 <udp_sendto_chksum+80>:  0xb25b  0x4618  0x3718  0x46bd  0xbd80  0xbf00  0xb580  0xb088
0x5960 <udp_sendto_if+4>:   0xaf04  0x60f8  0x60b9  0x607a  0x807b  0x887b  0x69ba  0x9200

A bad flash:

(gdb) x/16hx 0x5950
0x5950 <udp_sendto_chksum+80>:  0xb25b  0x4618  0x3718  0x46bd  0xbd80  0xbf00  0xb580  0xff88
0x5960 <udp_sendto_if+4>:   0xaf04  0x60f8  0x60b9  0x607a  0x807b  0x887b  0x69ba  0x9200

The relevant part is 0x595e:

(gdb) disassemble 0x595e,+4
Dump of assembler code from 0x595e to 0x5962:
=> 0x0000595e <udp_sendto_if+2>:            ; <UNDEFINED> instruction: 0xff88af04

This is... problematic. It's not even entire sections which are broken, just individual bytes which are erased, but not programmed.

I haven't been able to work out a pattern in which bytes fail to be written correctly.

[0xc0170]

Can you try to use flash algo which are published in mbed cmsis dap for k64f? In case they differ.

thanks for reporting, all flash algo should be tested. I had a problem to find a working version of flash algo which would erase section for one target.

[bremoran]

I have updated to the lastest pyOCD. Now, I have:

python ./test/gdb_server.py 
Welcome to the PyOCD GDB Server Beta Version 
INFO:root:new board id detected: 024002024C162E06B1EBD3BE
id => usbinfo | boardname
0 => MB MBED CM (0xd28, 0x204) [k64f]
INFO:root:DAP SWD MODE initialised
INFO:root:IDCODE: 0x2BA01477
INFO:root:K64F not in secure state
INFO:root:6 hardware breakpoints, 4 literal comparators
INFO:root:CPU core is Cortex-M4
INFO:root:FPU present
uncaught exception: __exit__
Traceback (most recent call last):
  File "./test/gdb_server.py", line 59, in <module>
    with board_selected as board:
AttributeError: __exit__

[c1728p9]

Can you try running 'setup.py install' again? I think it is still trying to use an older installed version. The newest version should have a line printing the number of data breakpoints, something like 'INFO:root:2 hardware watchpoints'. This is what my KL25 prints:

INFO:root:new board id detected: 020002032477B1A1D98B4C59
id => usbinfo | boardname
0 => MBED MBED CMSIS-DAP (0xd28, 0x204) [kl25z]
INFO:root:DAP SWD MODE initialised
INFO:root:IDCODE: 0xBC11477
INFO:root:KL25Z not in secure state
INFO:root:2 hardware breakpoints, 0 literal comparators
INFO:root:2 hardware watchpoints
INFO:root:CPU core is Cortex-M0+

[bremoran]

I have run setup.py install again, with no change. It's possible that I have a dependency of some sort trailing around. I will have to try removing and reinstalling pyOCD and its dependencies.

[c1728p9]

Hi @bremoran were you able to get this working? I have been using the K64F lately and haven't had any trouble flashing.

[bremoran]

I'll have to check my pyOCD version, but this is still a constant problem.

[bremoran]

Under the latest version of pyOCD, this bug seems to be fixed. However, the gdb load command now causes pyOCD to crash. I'll file a new ticket.

[bremoran]

This issue has just recurred. It seems more stable, but it still fails sometimes.

[c1728p9]

What kind of failure are you seeing? An exception when loading code, corrupt flash or something else? If it is an exception can you attach the call stack?

[bremoran]

I think it was corrupt flash, but it has now only occurred once in about 30 loads, so I'm not confident that it is not instability in some initialisation code.

[c1728p9]

Next time you see problems could you try dumping flash contents with something similar to the script below and then comparing to the original binary?

import pyOCD
from pyOCD.board import MbedBoard

filename = "dump.bin"
print "Dumping to file %s" % filename
with MbedBoard.chooseBoard(frequency = 10000000) as board:
    data = board.target.readBlockMemoryUnaligned8(0x0, 1024 * 1024)
    data = bytearray(data)
    with open(filename, "wb") as f:
        f.write(data)
    board.uninit()
    print("Dump finished")

[c1728p9]

If it works for your version of GDB, could you try the compare-sections command next time you see this? If the contents differ from what you loaded then you might want to dump with the above script and compare. If you see any pattern (or could send the differing binaries to me) I could take a look and try and fix whatever is going wrong.

[c1728p9]

Hi @bremoran , have you seen this issue occur lately?

[c1728p9]

Have you been able to recreate this issue @bremoran ?

[bremoran]

I did manage to reproduce, but I haven't seen in in a little while. I suggest closing. I will reopen if I hit it again.