C8051F530 erase by IDE: part 2

The next C2 packet is at 37ms. I've got a sneaking suspicion the IDE does this erase 2 or 3 different ways. Using the scope to capture this packet takes 2 or 3 tries. When it's in the sample window, it's dead centre every time. It never appears off-centre, it just is there or it isn't. The packet is WAa0WD80. This C2 register is read at 32ms, and returns the value 0x80. I'm completely in the dark. Again.

There's another short packet at 39ms: WAffWDe0, a write of e0 to C2 register ff, no clue still.

There's a large packet at 42ms:

WAb4WD06RA00RA01WAb4RD0dWAb4WD00RA00WAb4WD00RA00
WAb4WD01RA00RA01WAb4RD0dRA01WAb4RDff

This sequence is in AN127 - it's a read flash block command (0x06). This one reads 1 byte from 0x0000. By this stage I've flashed this device over and over, so of course, the byte is 0xff.

The last few packets I caught were at 43ms: WAffWDc0 (a write of c0 to C2 register ff, similar to 39ms). Another short packet at 47ms: WAa0RD80, similar to packets at 32ms and 37ms. A packet at 49ms is WAa0WD90, perhaps a response to the previous packet?

I have another packet captured at 50ms that is identical to that captured at 42ms. My sampling window for these captures is only 0.5ms long, so I have no idea whether both packets exist in the same erase traffic.

The last packet I captured is at 53ms:

WAb4WD09RA10RA11WAb4RD0dWAb4WDefRA10WAb4WD01RA11RA11
WAb4RD4a

I've broken the lines this way to compare with the (known) packet at 42ms. This is a 'command 0x09' to the FPI. It seems to take a 2 byte argument (the top line). It then reads FPDAT, and gets 0x4a. The read flash block command would read FPDAT for the FPI command status at this point. AN127 has all commands that read the FPI status and don't get a 0x0d response, abort.

That's the last packet I captured. The one useful attack may be that read command at 42ms. If I can fill memory with something other than ff, and capture that packet again, I'll know whether the erase has happened before that packet (it reads ff) or it happens after (it reads the fill byte).

I used a 0x55 fill byte. It took me 5 tries, but the packet I have reads:

WAb4WD06RA00RA01WAb4RD0dWAb4WD00RA00WAb4WD00RA00
WAb4WD01RA00RA01WAb4RD0dRA01WAb4RD55

Oh noes! It has read 0x55 from 0x0000, so this is before the reset! Well, that's a bit disappointing. But then, there wasn't anything that really looked like any of the reset commands from AN127.

To bed I think, this problem is for another day.