Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
The ARM debug interface v5 doc states that TAR auto incrementalist is only guaranteed to work on the lower 10 bits of TAR. This is dealt with in code, by writing the TAR register every 1KB. However it assumes a 1KB alignment for address.
For example. On a cortex m0+ chip only the bottom 10 bits are supported. After that it appears to wrap back to the start of the 1KB region.
If we wrote 1KB to 0x200, The code would set TAR to 0x200, the first 512 bytes would be written as expected, then it would overflow / wrap / ... (this is implementation defined) and the second 512 bytes don't go where we expect them to go (on the cortex m0+ they get written to 0x000 - 0x1FF).
Instead the code should write up to the 1KB boundary and then change the TAR address.
I'm working on a patch for this now.
The TAR register can be auto incremented after every write or read from DRW. However this is only guaranteed to work for the lowest 10 bits of TAR. Above that it's implementation defined. On some targets it's just the 10 bits, meaning that something unknown <implementation defined> happens if you go over a !KB boundary. The previous code dealt with this, by rewriting the TAR register every 1KB. However that doesn't work if you don't start your writes 1KB aligned. For example, if you write 1KB starting at address 0x200, the first 512 bytes write OK, after that it's implementation defined. On my target it wrapped to 0 and wrote the last 512 bytes there. My fix re-writes the TAR register whenever you hit a 1KB boundary, regardless of start address.