I was reading the topic about backing up your groups, when I just went, duh, I know what is happening. After a little abuse to my calculator's flash, I managed to pull my own ERR:VERSION. It's actually very simple if you know what you are doing.

Flash is made of sectors, each sector is 65,536 bytes long. Then each sector is split into 4 pages of 16,384 each. When you archive stuff, it is stuck where ever there is room while trying to be efficient. This means that data is allowed to run over one page onto the next, (not a sector boundary though). The only problem is that it is rather annoying to see if the data crosses a page boundary. Normally this is not a problem as TI checks to see if the data crosses the boundary. But if the 9 byte header which has to be processed byte by byte crosses a boundary, ERR:VERSION. This is TI's way of saying since the chance of this happening is only 3*9/65535 = .04%, we just won't bother with it.

Pretty soon I'll be looking to see how this can be patched, I'd imagine it's not too hard, but I'll see what I can do.

Here is the proof of concept screen shot.

Edit:
    Whoa, the problem is a lot worse than I thought, that was a completely blank group that it made. It has a flash header, but no data, just FF's.

Basically we are seeing Ti being very very undescriptive. Err: Version wouldn't make you guess that the header of a group was split over 2 Flash pages wouldn't it? Err: Flash or Err: Header or Err: Boundary would have been better. Secondly it indeed shows Ti being lazy about getting the header always in the right place, makes me wonder if data actually is at all neatly packed of any prm or app in flash rom. Would there be FF's between several apps? that would indicate that Ti is even more lazy then I initialy thought. Does make something as rudimentary as a garbage collector needed though.

What makes groups different than programs and the other variable types though?  Because I'm pretty sure those can have headers on the page boundary.

I have found one source of the problem. When the OS makes the group, it stores the start page and address in a temporary memory location. It then loads them in the OS specified page and address spot. The only problem is that the routine it calls to setup the group header, happens to also use the temporary memory location. So what happens is that the page gets first put by the main program, then increased by the header program, and finally the main program grabs it and raises it again! These ERR:VERSION groups actually start at the beginning of one page, and restart at the beginning of the next.

What worries me is that the best way to fix the problem was actually to NOP 15 bytes. Not only that, TI went through and optimized this section for 2.53. That means they looked at it, saw nothing wrong, and continued on.

But that's only half the problem! After I patched it up to make the groups, it can't read them. The group was definitely created successfully because GrpTool can read it. Plus it was readable after it got relocated on a garbage collect. TI just doesn't want us to use groups.

So, wait.
How did you trigger this error?

I GC'd to erase all memory. Then I filled the first flash page up until it only had 3 bytes left. (Flash isn't truly erased until GC it is just marked dirty). Then I made a group.

What makes groups different than programs and the other variable types though?  Because I'm pretty sure those can have headers on the page boundary.

What makes them different is that they have very specific code that creates and reads them! The ERR:VERSION groups function normally anywhere else, unless they corrupted the next page.

Now I'm off to find part two of this horrible group handling.

Edit:
   Found the second one, it only occurs if the group starts <4 bytes from the end of a page. TI almost did it right, they checked for page crosses, it's just that they assumed that it wouldn't change pages.

Edit 2:
   For those that want to jump the gun, I finished the patch for 2.53. Tomorrow I'll have to make one for 2.43, maybe the 83+ and SE too if I can find some roms. It won't run on anything but, 2.53. Don't run it if you know your batteries are low and especially don't pull a battery. I was even nice enough to make it so that it won't say ROM failed in the self test.

@Raylin: I don't use groups (There have been issues that turned me off of using them), but this does actually happen sometimes. It's poor programming on TI's part really.

This looks like another unofficial patch to fix TI's bugs... people, keep them going

Here is the fix for 2.43.

While we're on the topic of protecting groups, I also added in two more programs. For 2.43 and 2.53 respectively, these stop the OS from deleting all your groups during press to test. It has always bothered me that it disables all your programs, and then deletes all your groups.

As far as these patches go, they are all undo-able. When you run them, a menu pops up with a fix and unfix option.

Woah!  I missed it too.  It's wonderful to see you fixing the problems.  Thank you! +1 also!
Any chance of a 83+SE Patch?