Foreword: the solution to this issue probably has to deal with something like OS flash modification procedures or the certificate, so expect to need to know about these things.

Here's the issue I'm experiencing with Axe. I'll start with a high-level description. Since at least Axe 1.2.1, I have experienced a very peculiar bug. On the few occasions when I've sent a new development version of Axe to my calculator, the very first compile would result in a seemingly random compilation error occurring almost instantly. This error would never occur again for the same version of Axe, as far as I can tell. I've tried replacing it with the old version of Axe and re-upgrading it, I've tried clearing RAM, and I've tried sending new "dummy" upgraded versions of Axe that have one small thing changed to make the application slightly different. None of these seem to replicate the bug. The bug also doesn't seem to ever occur in wabbitemu.

I'm fairly certain this is not a fluke. This exact scenario of me making a ton of changes and sending the new version of Axe to my calculator months after the last build was sent has happened at least three times so far; once with an older version (perhaps 1.2.1, or an early 1.2.2 build?), and twice with sending the most recent 1.2.2 to two of my calculators. I have one calcultor left still with Axe 1.2.1 on it. I predict that sending Axe 1.2.2 to this calculator will replicate the bug one more time, but I'm saving it to add more debugging tools as necessary to a build of Axe 1.2.2 to hopefully pin down this bug.

Now, for some lower-level details. The error occurs due to a failed B_CALL(_WriteAByteSafe), oddly on what I believe is the second call to that routine with the fresh version of Axe. The write is to the first page of the swap sector, which should have been erased by a B_CALL(_FindSwapSector) \ B_CALL(_EraseFlashPage). In the register dump that follows, the swap sector perhaps unusually starts on page $0C, but I don't think that's part of the issue. From what little I remember of the dump I got from my first calculator, which I didn't save, I believe everything was the same except the swap sector started on page $08.

Anyways, here are the known input and output register values from B_CALL(_WriteAByteSafe) that I got from the existing debug dumper in Axe 1.2.2 when the error occurred on the second of the two calculators I sent it to:

• INPUT: af=$0C80, bc=$4701, de=$4011, hl=$8686    (note: the value of b is not officially known, but that's what it ideally should  have been)
• OUTPUT: af=$1F08, bc=$0000, de=$4011, hl=$8478

If anyone already has any ideas as to what the problem is, or ideas of what to add to a debug version of Axe to hopefully replicate and better debug the issue on my third calculator or your calculator, I would appreciate them. If not and I can't solve the issue myself, I'll just write this off as a minor bug since it only happens once per Axe upgrade anyways.

Oh, perhaps I should have clarified that. It returns, but with nz, meaning that the write was unsuccessful.

EDIT: I just noticed, I don't see any logic in that code to clip de from $8011 to $4011, but the register values (and the fact that the code works the other 99.99999% of the time) mean that it must have that logic.

EDIT 2: I'm an idiot, Axe handles masking de to the range $4000-$7FFF itself.

EDIT 3: Issue solved! Basically TI sucks and one of their B_CALLs is buggy.

EDIT 4: Issue re-solved! Basically I suck and I was just derping out this whole time. I still have no idea what convinced past me to make the code relocation change that caused this bug in the first place...

Also, for future reference. bcall(_delVarArc) locks flash if a variable is in flash

And all OS errors lock flash as well.