When reading back flash from a locked device, the lock boundaries to not appear correct (flash that should be accessible appears locked). What's going on?
This is caused by the way the debug adapter reads back flash memory values.
Let's assume that we have a device with flash from 0x0000 to 0x0FFF and the first two pages (0x0000 = 0x07FF) are locked. When dumping all of flash, we would expect to see 0's for 0x0000 - 0x07FF and valid data for 0x0800- 0x0FFF.
However, on read-back, we may find that 0x0000-0x806 are unreadable. This happens because the debug adapter reads flash in blocks, and if any byte in a block is locked, the entire reads fails. All bytes in the failed read are then assumed to be locked. In our example case, the adapter read addresses 0x07E6-0x0806 in one block, and when that read failed, the IDE assumed that all bytes in the block were locked.
The same thing can happen with high locked bytes. If the last page of flash is locked, it may appear that slightly more than a page is locked.
In most cases, the adapter will read page-aligned blocks, and this phenomenon will not be visible. However, the adapter will sometimes read across a lock boundary and this behavior will be seen.
This behavior has been confirmed on C8051F5xx devices and may be present for other devices as well.
Don't request reads that cross flash boundaries. Instead of dumping all flash at once dump the locked section, then dump the unlocked desperately. This will result in the actual boundary of locked flash showing up.